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

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

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

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

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

タイムスタンプの問題

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

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

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

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

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

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

スロットリング

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

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

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

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

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

    • アカウントの取得率の計算方法とスロットリング方法。

    • 過剰取得に占める Collector の割合の確認方法。

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

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

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

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

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

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

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

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