Logpush Health ダッシュボードでは、Logpush ジョブのパフォーマンスと信頼性を把握できます。ログ配信の状態を監視し、問題を切り分け、設定した送信先へ送っているデータ量を確認できます。セキュリティ、コンプライアンス、オブザーバビリティに必要な重要なログデータが、想定どおり流れ続けているかを確認できます。
Logpush のヘルス通知 を設定すると、Logpush ジョブが無効になったときやエラーが発生したときにアラートを受け取れます。Logpush はログをバックフィルできないため、早期検知が重要です。一度破棄されたデータは、二度と戻りません。
ヘルス通知は Health ダッシュボードと併用でき、Logpush ジョブのパフォーマンスについてリアルタイムのアラートと過去の分析の両方を提供します。
- Cloudflare ダッシュボード で、アカウントまたはドメイン（ゾーン）レベルの Logpush ページに進みます。
- Health タブに進みます。
- 分析するジョブを選択します。
- 確認したい時間範囲を指定します。
- （任意） Jobs タブから、分析するジョブを探します。
- そのジョブの Job Health (24h) 列にカーソルを合わせ、View Health を選択します。
- Health タブに移動するので、分析したい時間範囲を選択できます。
- Health ダッシュボード は、Cloudflare ダッシュボード上で各 Logpush ジョブのヘルス指標を最大 30 日間 表示します。
- 生のヘルス指標は、GraphQL API の
logpushHealthAdaptiveGroupsデータセットでクエリできます。 - Cloudflare GraphQL Explorer ↗ でクエリを試したり確認したりできます。
Cloudflare が生成する 1 件のログエントリです。HTTP リクエスト、DNS クエリ、Access イベントなどがあります。
Cloudflare が 1 つのファイルまたはリクエストとして、まとめて送信先にアップロードするログのグループです。バッチはファイルとも呼ばれます。
ログのバッチを送信先にアップロードする 1 回の試行です。最初の試行が失敗すると、Cloudflare はアップロードが成功するか再試行上限に達するまで自動で再試行します。各アップロードの結果は、Successful、Retry attempts、Failed のいずれかです。
エラーやタイムアウトなしで、ログのバッチが送信先にアップロードされたことを示します。アップロードが成功すると、そのバッチは配信済みになり、以降の再試行は行われません。
初回失敗のあとに行われた追加のアップロード試行です。カウントには最初の失敗した試行も含まれます。バッチが正常に配信されるか、バッファされたデータが保持期間を超えるまで、再試行は続きます。
バッチに対するすべてのアップロード試行が成功しなかったことを示します。バッチが失敗すると、Cloudflare はそのログを送信先に届けられず、バッチ内のログはすべて破棄されます。これらのログは永久に失われます。
Logpush Health ダッシュボード は、ログ配信の監視とトラブルシューティングに役立つ 2 つの補完的なビューを提供します。Upload Health と Upload Reliability です。
各ビューは、ジョブ性能の異なる側面、つまり何が配信されたかと、どれだけ確実に配信されたかを示します。
Upload Health は、どれだけのデータが正常にアップロードされ、どこでアップロードが失敗したか、またはデータが破棄されたかを把握するのに役立ちます。このビューが答えるのは、「アップロードは成功しているか、ログは送信先に届いているか」です。
-
Batch Upload Success vs. Failure: 正常にアップロードされたバッチ数と、失敗したバッチ数を表示します。
- Successful Uploads — 正常にアップロードされたバッチの合計数です。
- Failed Uploads — 接続または送信先の問題でアップロードに失敗したバッチの合計数です。
-
Log Lines Uploaded: 送信先に正常にアップロードされたログ行の合計数を追跡します。
- Uploaded Log Lines — 正常に配信されたログ行の合計数です。
- Dropped Log Lines — すべての再試行のあとでも配信できなかったログ行の合計数です。
-
Data Volume: アップロードされたログデータの合計量（バイト）を、圧縮前と圧縮後の両方で示します。
- Uncompressed Data (raw) — 圧縮前のログデータの合計サイズです。
- Compressed Data (uploaded) — 圧縮後のログデータの合計サイズです。実際に送信されたバイト数を表します。
まずはここから、データ配信全体の健全性を確認します。
- アップロード成功率が高く、データ量が安定していれば、Logpush ジョブは健全です。
- 破棄、急増、失敗したアップロードがある場合は配信の問題が疑われます。原因を調べるには Upload Reliability に進みます。
Upload Reliability は、すべてのアップロード試行（再試行と失敗を含む）における信頼性、安定性、レイテンシに影響する要因を特定するのに役立ちます。このビューが答えるのは、「アップロードは安定して効率的か」です。
-
Uploaded Logs by Status Code: 成功、失敗、再試行されたバッチ数を、ステータスコード別に示します。
- Success Rate — 正常にアップロードされたバッチの割合です。
- Successful Uploads — 正常に完了したバッチの合計数です。
-
Upload Duration: 各バッチアップロードの完了にかかった平均時間を、ステータスコード別に示します。
- Destination Availability — Cloudflare が送信先に接続し、アップロードを完了できた頻度です。
- Average Upload Duration — ログが生成されたあと、アップロードにかかった平均時間です。
-
Retry Attempts: 失敗したアップロードのあとに行われた再試行回数を、ステータスコード別に表示します。
- Retry Attempts — 前回の失敗のあとに行われたアップロード試行の合計数です（最初の失敗した試行を含みます）。
信頼性の問題を切り分けるときに、このビューを使います。
- レイテンシが高い、再試行が多い、送信先の可用性が低い場合は、送信先エンドポイントまたはネットワークの不安定さが疑われます。
- Upload Health の指標と組み合わせて、配信の成功と、その裏にある信頼性の傾向を突き合わせます。
Logpush Health ダッシュボードは、Logpush ジョブの状態、信頼性、パフォーマンスを監視するのに役立ちます。このガイドで各チャートを解釈し、異常の根本原因を特定して、是正対応を取ってください。
| チャート名 | 症状 | 意味 | 考えられる原因 | 推奨アクション |
|---|---|---|---|---|
| Batch Upload Success vs Failure | アップロード失敗 | すべての再試行のあとでも、Cloudflare がバッチを配信できませんでした。これらのバッチは failed になり、含まれるログ行はすべて破棄されます。 | - 送信先エンドポイントが利用できない、または接続を拒否している（認証情報の期限切れ、ダウンタイム）。 - バッチサイズが大きい、またはネットワークレイテンシによりアップロードがタイムアウトしている。 - 送信先のスロットリングまたはレート制限。 |
- 送信先の認証情報とエンドポイントの健全性を確認します。 - Logpush ジョブ設定でバッチサイズを小さくします。 - 送信先が想定されるアップロードレートを処理できることを確認します。 - 失敗が続く場合は Cloudflare Support に連絡します。 |
| Log Lines Uploaded | 破棄されたログ行、または配信量の減少 | 想定より少ないログしか届いていません。失敗したアップロードや破棄されたバッチが原因であることが多いです。 | - 失敗したアップロードの急増。 - 送信先の取り込み上限、または部分的なアップロード。 |
- Log Lines Uploaded と Data Volume のチャートで落ち込みを比較します。 - 送信先で取り込みエラーやレート制限を確認します。 - 最近の Logpush ジョブ設定の変更を確認します。 |
| Data Volume (Compressed & Uncompressed) | データ量の想定外の低下 | 配信されたデータ量が想定より少なく、圧縮の非効率や破棄されたバッチが疑われます。 | - 失敗したアップロード、または不完全な配信。 - サイズまたはクォータ制限により、送信先がアップロードを拒否している。 |
- 圧縮設定とバッチサイズを確認します。 - 送信先のストレージ容量を確認します。 - 失敗したアップロードや再試行の急増がないか確認します。 |
| Uploaded Logs by Status Code | 再試行または失敗ステータスコードが多い | 最初の試行では失敗するが、再試行で成功しています。 | - 送信先の一時的なダウンタイムまたはスロットリング。 - Cloudflare と送信先のあいだのネットワーク不安定。 |
- ステータスコード別の再試行と失敗の分布を確認します。 - 相関を見るために Destination Availability と比較します。 - バッチサイズを小さくします。 |
| Retry Attempts | 再試行が頻繁 | アップロードが繰り返し失敗し、何度も再試行されています。 | - 送信先の不安定さ、または一時的なエラー。 - 高いレイテンシ、または送信先からの確認の遅れ。 |
- 送信先の稼働状況と取り込みレートを確認します。 - 送信先がリクエストをスロットリングしていないことを確認します。 - ときどきの再試行は想定内です。持続的な急増は調査が必要です。 |
| Avg. Upload Duration | アップロード時間が長い | アップロードに想定以上の時間がかかっており、レイテンシまたは過大なバッチが疑われます。 | - 大きなバッチ、または非圧縮のペイロード。 - ネットワークまたはリージョンのレイテンシ。 - 送信先の処理遅延。 |
- Avg. Upload Duration の傾向を確認します。 - アップロードを速くするためにバッチサイズを小さくします。 - 送信先のスループットとレート制限の設定を確認します。 |
| Destination Availability | 可用性が低い、または不安定 | Cloudflare が送信先に安定して接続できません。 | - 送信先のダウンタイム、DNS エラー、または認証の問題。 - ファイアウォールまたはネットワーク制限が Cloudflare をブロックしている。 |
- Destination Availability の落ち込みを確認します。 - 送信先の認証情報とエンドポイントの稼働を確認します。 - 許可リストやネットワークアクセス設定を確認します。 |
Cloudflare が送信先から HTTP ステータスコードを受け取れない場合（接続が完了しない、リクエストが中断されるなど）、その配信試行は HTTP ステータスではなく、Cloudflare が生成したエラーコードとして記録されます。これらのコードは Health ダッシュボード と、GraphQL データセット logpushHealthAdaptiveGroups に表示されます。
| コード | 名前 | 意味 |
|---|---|---|
1101 |
ConnectionError |
Cloudflare が送信先に接続しているあいだに、タイムアウト以外のネットワークエラーが発生しました（TCP リセットや接続拒否など）。 |
1102 |
ConnectionTimeout |
Cloudflare が 接続タイムアウト 以内に、送信先への TCP 接続を開けませんでした。ファイアウォール、ネットワーク経路、到達不能なホストが典型的な原因です。 |
1103 |
InternalLogpushError |
Cloudflare がアップロード処理中に内部エラーに遭遇しました。このコードが繰り返し出る場合は、Cloudflare Support に連絡 してください。 |
1104 |
ConfigError |
ジョブ設定が無効です。送信先 URL、認証情報、アクセス権限を確認し、validate エンドポイント で設定をテストしてください。 |
1105 |
DNSError |
Cloudflare が送信先のホスト名を解決できませんでした。送信先エンドポイントの DNS レコードを確認してください。 |
1106 |
Timeout |
リクエストが停止したか、HTTP クライアント全体のタイムアウト を超えました。送信先が接続は受け付けるが本文の読み取りを止める場合や、TLS ハンドシェイクに時間がかかりすぎる場合によく起きます。 |
1107 |
RequestError |
ステータスコードが返る前に HTTP リクエストが失敗し、その失敗はタイムアウトに分類されません。送信先がリクエスト途中で HTTP/2 接続を閉じたことがよくあります。 |
1108 |
TransferError |
Cloudflare がリクエスト本文の転送中にエラーに遭遇しました。通常はアップロード中に接続がリセットされた場合です。 |
1201 |
FlushMaxLag |
バッファされたデータが配信前に保持期間を超えたため、Cloudflare がバッチを破棄しました。このコードは持続的な配信失敗を示します。送信先と、同じ時間帯の先行コードを調査してください。 |
Cloudflare は、アップロード経路の複数の層でタイムアウトを適用します。各層を理解すると、送信先のエラーコード を解釈し、送信先エンドポイントを調整しやすくなります。
| タイムアウト | デフォルト | 適用対象 | 関連するエラーコード |
|---|---|---|---|
| TCP 接続（dial） | 5 秒 | HTTP を使うすべての送信先 | 1102 ConnectionTimeout |
| TLS ハンドシェイク | 5 秒 | すべての HTTPS 送信先 | 1106 Timeout |
| 無進捗ウォッチドッグ | 10 秒 | 共有の Cloudflare HTTP トランスポートを使う送信先（HTTP エンドポイント、Cloudflare R2、Splunk、Datadog、New Relic、CrowdStrike、Cloudflare Pipelines） | 1106 Timeout |
| アイドル接続の再利用 | 10 秒 | 持続的な HTTP 接続 | エラーとしては表面化しません。必要に応じて接続を閉じて開き直します。 |
| HTTP クライアント全体のタイムアウト | 2 分 | HTTP エンドポイント系のみ: https://、Datadog、New Relic、CrowdStrike、Cloudflare Pipelines |
1106 Timeout |
| HTTP/2 のアイドル読み取りと ping | アイドル 10 秒、ping タイムアウト 15 秒 | HTTP/2 接続 | 1107 RequestError |
| HTTP/2 の書き込み停止 | 10 秒 | HTTP/2 接続 | 1106 Timeout または 1107 RequestError |
- エンドポイントは、各
POSTをエンドツーエンドで 2 分以内に受け付け、チャンク間の間隔が 10 秒を超えないようにリクエスト本文を流し続けてください。 - ロードバランサーや WAF で接続を終端している場合は、アイドル接続と読み取りのタイムアウトが、タイムアウト表の値より短くないことを確認してください。受信側で厳しすぎる設定にすると、Cloudflare 側で
1106または1107エラーとして現れやすいです。 - HTTP/2 を使う場合は、サーバーが
PINGフレームに 15 秒以内に応答することを確認してください。
Amazon S3、Google Cloud Storage、Microsoft Azure の送信先は、共有の Cloudflare HTTP トランスポートを使いません。独自のタイムアウトを設定するクライアントライブラリを使うため、タイムアウト表の値はどれも適用されません。そのため、個々のアップロードは失敗するまで 2 分を超えて続くことがあります。
Logpush は、一時的な送信先の問題を自動再試行で扱えるように設計されています。送信先が一時的に利用できない場合、Cloudflare は対象バッチをバッファし、再試行します。
再試行は、決まった回数で止まりません。代わりに、アップロードが成功してバッチが配信済みになるか、バッファされたデータが内部の保持期間を超えるまで、Cloudflare はバッチを再試行し続けます。データが期限切れになると、バッチは破棄され（1201 FlushMaxLag として記録）、含まれていたログ行は永久に失われます。
24 時間 バッチが 1 件も正常に配信されない場合、Cloudflare は送信先が恒久的に利用できないと判断し、ジョブを無効にします。送信先の問題が解消したら、Cloudflare ダッシュボード ↗ からジョブを再有効化できます。ジョブが無効だったあいだに生成されたログを、Cloudflare はバックフィルできません。
送信先が遅いがアップロードは受け付けている場合、Logpush は追いつくために並列アップロード数を自動で増やします。送信先が回復し、遅延が通常に戻ると、同時実行数は再び下がります。