メインコンテンツまでスキップ
Sumo Logic Japanese

HTTP ソースのトラブルシューティング

HTTP ソースのデータ受信の問題について調べます。

データを送信しないクライアント

特定の HTTP ソースがデータを受信しているかどうかを確認するには、Sumo の Live Tail を使用します。詳細については、「Live Tail」を参照してください。ソースがデータを受信していない場合は、次のような問題が考えられます。

  • サポートされていない形式でエンコードされたログ データ、またはサポートされていない方式で圧縮されているログ データを送信している。HTTP ソースには UTF-8 データのみを使用できます。サポートされている圧縮方式は gzip と deflate です。
  • HTTP リクエストの形式が正しくない。詳細については、「HTTP ソースへのデータのアップロード」を参照してください。

タイムスタンプの問題

HTTP ソースがデータを受信していることを確認したが、検索結果にそのデータが表示されない場合は、データのタイムスタンプが、検索の時間範囲内にない可能性があります。これは、Sumo でタイムスタンプが正しくパースされていない可能性があることを示しています。 

この問題は、[Use Receipt Time (受信時間の使用)] オプションを使用して、そのソースからのデータを検索することで確認できます。このオプションを使用して検索を実行すると、結果には任意のタイムスタンプのログ データが含まれ、受信時刻の逆順に並べられます。このため、タイムスタンプと受信時刻の違いを確認して、誤ったタイムスタンプを生成している可能性のあるソースを特定できます。詳細については、「受信時間の使用」を参照してください。

取り込んだデータのタイムスタンプが予期したものではないと判断した場合は、「タイムスタンプ、タイム ゾーン、時間範囲、および日付フォーマット」を参照して、タイムスタンプの形式が Sumo で自動的にパース可能であることを確認します。データのタイムスタンプのフォーマットが Sumo で認識できない場合は、そのソースにカスタム タイムスタンプ フォーマットを指定できます。

HTTP ステータス コードの確認

ソースにアップロードされたデータの一部が取得されていないと思われる場合は、そのソースに送信されたリクエストの HTTP ステータス コードを確認してください。各リクエストは、データが Sumo によって正常に受信されたことを示すステータス コード (200) になる必要があります。ステータス コードが 200 以外の場合、HTTP ソースに問題があることを示している可能性があります。主なステータス コードは以下のとおりです。

ステータス コード 説明
200 HTTP リクエスは正常に受信され処理されました。
401 HTTP リクエストは、見つからないか無効な URL トークンのために拒否されました。
408 HTTP リクエストは受け入れられましたが、処理がタイムアウトしました。詳細については、「リクエストのタイムアウト」を参照してください。
429 HTTP リクエストは、クォータ ベースのスロットリングのために拒否されました。詳細については、「スロットリング」を参照してください。
503 HTTP リクエストは、サーバの (複数の) 問題のために拒否されました。コレクタのステータスについては、Sumo Web アプリケーションの [Status (ステータス)] ページ ([Manage (管理)] > [Collection (コレクション)] > [Status (ステータス)]) を確認してください。
504 HTTP リクエストは、サーバの問題のために拒否されました。コレクタのステータスについては、Sumo Web アプリケーションの [Status (ステータス)] ページ ([Manage (管理)] > [Collection (コレクション)] > [Status (ステータス)]) を確認してください。

スロットリング

次のような 429 レスポンス コードは、アカウントのコレクタがあなたのアカウントのバースト レートを超える複合レートでデータを送信していることを示します。

STATUS 429 You have temporarily exceeded your Sumo Logic quota. (ステータス 429 一時的に Sumo Logic のクォータを超えました。)Please try again at a later time (後からもう一度やり直してください)

これが発生すると、一時的にデータがアカウント単位でスロットリングされます。データの取得レートがバースト レートの制限を下回ると、HTTP ソースでのデータの受信が再開されます。

以下のページは、スロットリング インシデントのトラブルシューティングの参考になります。

  • 取り込みの管理の管理 — 以下については、このページを参照してください。

    • Sumo でのアカウントの取得率の計算方法と、スロットリングを開始するタイミングの決定方法。

    • 過剰取得に占めるコレクタの割合の確認方法。

    • スロットリングが発生したときにアラートがどのように発生するか。

  • アカウントのページ — 現在および過去の請求期間における取得率については、このページを参照してください。

リクエストのタイムアウト

HTTP ソースへのリクエストは、30 秒以内に完了しないとタイム アウトになります。この場合、タイムアウト前に送信されたデータがすべて正常に取得されるとは限りません。厳密な制限はありませんが、POST から HTTP ソースへの圧縮前のデータ ペイロードは 100K から 1MB にすることをお勧めします。

HTTP ソースへのアップロードがタイムアウトした場合は、HTTP 408 エラーが発生します。今後の問題を回避するには、アップロードするサイズを小さくしてください。

Heroku 出力バッファ オーバーフロー エラー

ログを Sumo HTTP ソースに送信するために Heroku HTTPS ドレインを使用すると、Heroku L10 エラーによってリクエストのタイムアウトが通知され、その結果、ログが削除されることがあります。

2013-04-17T19:04:46+00:00 d.1234-drain-identifier-567 heroku logplex - - Error L10 (output buffer overflow): 500 messages dropped since 2013-04-17T19:04:46+00:00.

これが発生する可能性があるのは、Heroku アプリケーション エンジンがタイムアウトになり、再試行が行われて、バッファオーバーフローが発生したときです。Sumo ELB には非アクティブのタイムアウトがあります。セッションが 30 秒間非アクティブの場合、セッションが閉じられます。

この問題を確認するには、Sumo で次のクエリを実行できます。

“Error L10 (output buffer overflow)" | parse ": * messages dropped" as num_dropped | sum(num_dropped) _collector,_source | sort by _sum

出力バッファ オーバーフロー エラーがある場合、クエリは次のように出力を返します。

# _collector _source _count
1 アルファ版製品 source-alpha 21
2 ベータ版製品 source-beta 69
3 デルタ版製品 source-delta 30,180
4 source-omega source-omega 25
5 ガンマ版製品 source-gamma 21

問題を解決するには、Heroku サポートにその問題を連絡し、クエリ結果を提供してください。

見つからないか、サポートされていない Content-Type ヘッダー

HTTP ソースにメトリクスを送信するときに、Content-Type ヘッダーを指定していない場合やサポートされていない値に設定した場合には、データ ペイロードがメトリクスではなくログ データとして取得されます。詳細については、「HTTP ソースへのメトリクスのアップロード」を参照してください。

  • この記事は役に立ちましたか?