Cloudflare Observability MCP: ゼロログ結果を証明する

からの空の応答Cloudflare可観測性MCPサーバーはワーカーが正常であるという証拠にはなりません。これは、1 つのクエリが行を返さなかったという証拠です。それを判定する前に、クエリが意図したものを使用したことを証明してください。Cloudflareアカウント、ワーカー、時間枠、ログ構成、フィールド セット、および同じスコープで既知のコントロール呼び出しを取得できること。 妥当なデフォルトは厳密です。フィルタリングされたゼロ行の結果を呼び出します。 healthy empty ワーカー ログと呼び出しログが有効な場合のみ、ヘッド サンプリング レートは 1 、ウィンドウは保持内にあり、フィールド検出は成功し、クエリは完了し、より広範なクエリで同じアカウント、ワーカー、およびウィンドウ内の既知の呼び出しが見つかります。受信が欠落している場合は、状態を不明のままにするか、特定の構成エラーをルーティングします。 これは重要です。MCP証拠層が不完全であっても交換は成功する可能性があります。プロトコルの結果は、「ツールは戻りましたか?」という質問に答えます。オペレーターは依然として、「このクエリは、この決定に必要なイベントをカバーしていますか?」と答える必要があります。 成功したMCPクエリは依然として証拠に失敗する可能性があります Cloudflareアプリケーション ログと分析をデバッグするための管理対象 Observability サーバーをリストします。現在Cloudflare MCPサーバーカタログリモート エンドポイントを提供し、新しい接続は Streamable HTTP を使用すると述べ、承認は次の方法で処理されると説明します。CloudflareOAuth。のワーカーオブザーバビリティ MCP リポジトリ3 つのツールを文書化します。 query worker observability ワーカーのログとメトリクスをクエリします。 observability keys メタデータ、ワーカー固有のフィールド、およびカスタム フィールドを検出します。 observability values 選択したフィールドに使用可能な値を検索します。 これらのツールは多くのインシデントを調査するには十分ですが、その成功範囲は対象範囲を証明するものではありません。リポジトリは、各リクエストがリクエストスコープの新しい承認とアカウントコンテキストを取得するとも述べています。したがって、前のリクエストで正しいアカウントが使用されたからといって、次のリクエストでも必ず正しいアカウントが使用されたとは考えないでください。クエリ受信ごとに非機密アカウント参照とワーカー参照を記録します。 説得力のある空の結果を得るには、いくつかの方法があります。 1. OAuth は完了しましたが、選択されたアカウントは運用アカウントではありません。 2. ワーカー名または環境フィルターは何も解決されません。 3. その展開ではワーカー ログが無効になっています。 4. 呼び出しログは明示的に無効になっています。 5. ヘッド サンプリングにより、見つかると予想されていた呼び出しが省略されました。 6. 要求されたウィンドウは、保持されているデータよりも古いです。 7. フィルターは、現在のスキーマに存在しないフィールドまたは値を使用します。 8. フィルタリングされた結果は完全に空です。 最後の状態のみが「一致するインシデントなし」をサポートし、その場合でも、制限されたスコープとウィンドウのみがサポートされます。リストを折りたたむと、 success オペレーターが必要とする正確な証拠を破棄します。 フィルターを解釈する前にデータセットを証明する インシデントのクエリからではなく、収集から開始します。Cloudflareさんの現在ワーカーログのドキュメントワーカーがワーカー ログに書き込むには可観測性が有効になっている必要があると述べています。また、別の文書も記載されています invocation logs = false 設定。したがって、監査で期待される呼び出しの証拠が意図的に存在しない場合でも、ワーカーは正常に実行できます。 サンプリングもまた、厳しい境界です。 head sampling rate からの範囲 0 に 1 ;で 0.01 、100 件のリクエストのうち 1 件のみがログに記録されます。サンプリングされたデータに対するゼロ行エラー クエリは、傾向推定には役立ちますが、1 つの既知のリクエストを決定的にクリアすることはできません。同じドキュメントには、アカウントが 1 日あたりのログ制限を超えた後、サービスが 1% のサンプルを適用できることが記載されています。意図した構成だけでなく、効果的なサンプリング ポリシーを記録します。 保持すると、古いウィンドウが認識できなくなります。文書化された最大値は、Workers Free の場合は 3 日間、Workers Payd の場合は 7 日間です。インシデントウィンドウが保持境界より前に終了した場合は、それを分類します window expired 。クエリを拡張したり言い換えたりしても、保存されなくなったデータは回復できません。 各調査には次の順序を使用します。 1. ピンスコープ。 承認されたアカウント、ワーカー、および環境の不透明で非秘密の参照をキャプチャします。 OAuth トークン、リクエスト URL、ログ本文、または顧客 ID をヘルスレシートに保存しないでください。 2. 収集を確認します。 デプロイされた環境でワーカー ログが有効になっていること、および呼び出しログが有効になっているかどうかを確認します。 3. カバレッジ制限を記録します。 有効なヘッド サンプリング レート、保持日数、要求された開始/終了タイムスタンプをキャプチャします。 4. フィルタリングの前に検出してください。 使用する observability keys 必須フィールドが存在することを確認してから、 observability values Worker または環境の値が存在することを確認します。これにより、スペルが間違っているフィールドや古いフィールドがきれいな結果のように見えなくなるのを防ぎます。 5. コントロール クエリを実行します。 同じアカウント、ワーカー、ウィンドウ内で発行された既知の呼び出しを 1 つ見つけるために十分に広範囲にクエリを実行します。相関関係が必要な場合は、ローカルに保持されているハッシュされたリクエスト マーカーを使用します。生のマーカーを監視レコードにアップロードしないでください。 6. インシデント フィルターを実行します。 コントロールが表示された後でのみ、ゼロ行エラー フィルターがインシデント フィルターの候補と見なされます。 healthy empty . コンパクトなレシートでは、ログの内容を保存せずに決定を保存できます。 アカウントとワーカーの参照は相関キーであり、秘密を保持する識別子ではありません。レシートには、プロンプト、ログ メッセージ、ヘッダー、リクエスト URL、ツール引数、および OAuth マテリアルが意図的に除外されています。 1 つの緑の結果をレンダリングするのではなく、9 つの州をルートします。 この記事に付随する検査可能なアーティファクトは、コンテンツのない 9 つのケースを再現しています。その優先順位ルールは意図的に保守的になっています。 州 証拠 オペレータのアクション needs auth リモートサーバーは許可されていません アカウント所有者にルーティングします。ワーカーに到達不能のラベルを付けないでください scope unresolved アカウントまたはワーカーの参照がありません 正確なアカウント、展開、環境を解決する collection disabled ワーカー ログまたは呼び出しログがオフになっている 収集と再デプロイを有効にするかどうかを決定する window expired ウィンドウは保持されるデータよりも古いものです 過去の評決を使用不可としてマークします query failed スキーマ検出、タイムスタンプ、またはクエリの実行が無効です 行数を解釈する前にクエリを修復する sampled unknown 以下の先頭サンプリングのあるゼロ行 1 欠勤を非決定的なものとして扱う coverage unknown 行がゼロで、既知のコントロール呼び出しがありません スコープ、フィルター、取り込み、または収集の遅延を調査する incident found フィルタリングされたクエリは 1 つ以上の一致する行を返します 返された証拠を調査する healthy empty ゼロフィルター処理された行に加え、完全なカバレッジと見つかったコントロール このフィルタ、スコープ、および時間ウィンドウのみをクリアします 分類子は、調査する前に前提条件をチェックします。 filteredRows 。この順序により、最も一般的なフォールス グリーン (ゼロが表示され、検索する有効なデータセットがあるかどうかを尋ねる前に停止する) が防止されます。 フィクスチャをローカルで実行します。 9 つの治験では各州で 1 つのケースが発生し、3 つのテストはすべて合格しました。 改ざん可能な部分は単純です。健全な空のフィクスチャを取り出し、コントロール レシートを削除します。その状態は次のようになります。 coverage unknown 。より低いサンプリングから 1 に 0.1 : になります sampled unknown 。フィルタリングされた 3 つの行を追加すると、次のようになります。 incident found 。行数は、証拠のパスが確立された後にのみ意味を持ちます。 検証された空のログ ウィンドウは依然としてエージェントの結果ではありません healthy empty 意図的に狭いです。選ばれたという意味ですCloudflareワーカー ログ フィルターは、覆われたウィンドウ内に一致する行を返しませんでした。これは、ワーカーが正しい応答を生成したこと、ダウンストリームの書き込みが 1 回コミットされたこと、スケジュールされたジョブが成果物を配信したこと、またはユーザーの広範なエージェント タスクが成功したことを意味するものではありません。 Cloudflareさんのワーカーの可観測性の概要ログ、トレース、メトリクス、分析、エクスポートされたテレメトリを分離します。各表面は異なる質問に答えます。クリーンなエラー フィルターでも、誤ったビジネス結果が共存する可能性があります。成功した呼び出しログは、欠落している宛先レコードと共存できます。既知の制御リクエストは、無関係なキュー コンシューマについては何も述べずに、クエリ カバレッジを証明できます。 インシデントにファイル ハッシュ、データベース バージョン、公開応答、キューの確認応答、または別の確定的な宛先チェックなどのユーザーに見える影響が含まれる場合は、ログ クエリの外部に結果の受信を追加します。影響が発生した可能性があるが、レシートが存在しない場合は、副作用境界で自動的に再試行しないでください。まず和解してください。 プライバシーの制限もあります。コントロールプローブは合成され、境界があり、ログに秘密を置くことなく簡単に識別できる必要があります。ヘルスレシートでは、リクエストボディではなく、ハッシュと状態を保持する必要があります。Cloudflareサイズが大きすぎるログは切り詰めることができるドキュメント。現在の行は、予期されるすべてのフィールドが生き残ったことを証明するものではありません。を検査します。 $cloudflare.truncated 診断がログの内容に依存する場合の境界。 のCloudflare可観測性MCPサーバーは進行中の作業として文書化されているため、ツールの名前と動作は変更される可能性があります。フィールド検出を再実行し、インシデント レポートで証拠の日付を特定し、古いツールの仮定を正常な結果ではなくクエリの失敗として扱います。 Sidewisp は現在プライベートプレビュー段階です。実稼働監視アダプターと回復システムは通常出荷されません。ここでの方法はローカルな動作パターンであり、次のことを主張するものではありません。Sidewisp現在接続しているのはCloudflareアカウント、ライブワーカーのクエリ、またはインシデントの修正。 有用なルールはさらに小さく、正確なデータセット、スコープ、ウィンドウ、および収集ポリシーが証拠を返すことができることが既知のイベントによって証明されるまで、「ゼロ行」を「正常」に昇格させないことです。それはMCPログだけが結果を証明しているかのように振る舞うことなく、監査可能な決定への対応を可能にします。