Cloudflare Observabilityに関する8つの重要な更新

本日、ログ、トレース、分析、アラート、ダッシュボード、エクスポートを 単一のオブザバビリティプラットフォームにまとめ、よりシンプルで予測しやすい料金体制を採用した8つの重要な更新をリリースしました。

今回のリリース内容：

• Cloudflare全体のログを調査するための統合された場所
• Cloudflareのエッジからオリジンまでのエンドツーエンド追跡
• Cloudflareデータのクエリ用統一SQL API
• Cloudflareでデータを受信する際のオブザバビリティデータの料金体制モデル
• オブザバビリティデータに関するカスタムアラート
• ドメインのすべての分析を1箇所で、30日間のデータ保持
• オブザバビリティデータから作成されるカスタムダッシュボード
• Logpushでデータをエクスポート -- セルフサービスプランで利用可能に

Cloudflareのすべてのデータを網羅する単一のオブザバビリティプラットフォーム

問題を把握するには、多くの場合、複数のCloudflare製品のデータが必要になります。5xx応答の急増は、Worker、オリジン、またはCloudflareがグローバルまたはリージョン全体でオリジンに接続できないことが原因で発生する可能性があります。しかし、今日その調査を行うには、各シグナルがどの製品に属しているか、またどのようにクエリを実行すればよいかを知る必要があります。

プラットフォーム全体の機能であるべきObservability：つまり、アプリケーションが実際どのように動作しているかを反映し、問題を解決するために必要な完全なコンテキストを提供できなければなりません。数ヶ月以内には、さらに多くのCloudflareの製品、データセット、ワークフローがこの共有オブザバビリティプラットフォームに組み込まれ、より一貫した料金体制、製品体験、機能が実現されます。これら8つの更新は、より統合されたObservabilityプラットフォームに向けた最初のステップです。

1. すべてのログを一元的に調査する

 新しくなったログホームで、 Workers Observability （Workersアプリケーションと接続されたリソースをデバッグするためのもの）と Log Explorer （セキュリティログを検索するためのもの）が統合されました。HTTPイベント、ファイアウォールイベント、Workers、Containers、R2、AI Gatewayなどのログデータセットから選択できるようになり、それぞれに同じ調査ツールと機能を使用することができます。

リクエストの遅延の増加から始めて、それをホスト名またはデータセンターでグループ化し、影響を受けているパスに結果を絞り込み、Ray IDによって個別のリクエストを調査します。調査で他のCloudflare製品が関連していると判明した場合は、ログを離れることなくデータセットを切り替えることができます。複数のデータセット間でのクエリに対応する機能が近日中にリリースされ、1つのクエリで製品間に関連付けられたイベントをつなぎ合わせることが可能になります。

生のSQLまたは組み込みのフィルターを使ってログにクエリを投げ、特定のイベントに絞り込むことができます。自然言語を使用してビジュアライゼーションを作成し、検出された異常を容易に調査して理解します。

2. 当社のプラットフォーム全体でリクエストをトレース — オープンベータ版で利用可能に

 Cloudflare Tracesのオープンベータ版をリリースし、サポートされているセキュリティルール、Transformations、キャッシュ決定、ルーティング、Workers、送信元処理などのリクエストレベルの可視化を提供します。トラフィックが当社のプラットフォーム内をどのように移動したかを確認し、Cloudflareをどのように構成したか、またこれがリクエストの処理時間、ルーティングの決定、その他にどのように影響するかを関連付けることができます。

ベースラインサンプリング率を設定して継続的な可視性を実現し、その後 トレースルールを使用して調査中に特定のトラフィックを高いレートでキャプチャします。ターゲットのホスト名、パス、IPアドレス、またはヘッダー、 Ray IDでの検索、その結果のスパンはCloudflareダッシュボードで直接検査します。

​OpenTelemetry を介してトレースをエクスポートできるほか、​W3Cトレースコンテキスト伝播 を使用して着信トレースコンテキストを受け入れ、オリジンにコンテキストを渡すことができます。Cloudflare Tracingについての詳細は ブログ記事全文をご確認いただくか、エージェントに以下のコマンドを入力して開始してください。

3. 1つの統一されたSQL APIを使用して、エージェントにオブザバビリティデータのクエリを実行する

エージェントも、オブザバビリティデータから情報を整理し、問題を調査し、シグナルを関連付け、修正を確認する一貫した手段を必要とします。Cloudflareのテレメトリ全体にクエリを実行できる 統一SQL API（ベータ版）の提供を開始しました。Workersログ、コンテナセキュリティイベント、HTTPリクエストログ、分析データを個別に統合するのではなく、ユーザーやエージェントは1つのSQLダイヤレクト、認証モデル、APIを使用してクエリを実行できるようになります。

エージェントは、新しい Cloudflare CLI（cf）を使用してコマンドラインからクエリを見つけて実行し、 Cloudflare Observability MCPサーバーに接続してログ、トレース、分析を調査できます。 データセットのスキーマ、フィールド、クエリの例を利用すれば、人間やエージェントの両方がクエリを作成できます。

さらに、ネイティブバインディングを使って、SQLインターフェースをWorkersで直接利用できるようにしました。今後は、Workerで Analytics Engine データをクエリして、お客様の利用状況を測定したり、課金ワークフローを構築したり、お客様向けの分析ダッシュボードを作成したり、ヘルスオフレポートを生成したり、個別のAPIクライアントを構成せずにインシデント調査を自動化したりすることができます。

4. インジェストおよびストレージされたすべてのログとトレースに関する新しい料金体制

Cloudflareに収集・保存されるすべてのログとトレースにおいて、単一の統合されたObservabilityサブスクリプションと料金体制へ移行します。2026年12月1日より、この料金体制モデルはすべてのプランに適用されます（すべてのEnterprise顧客に対して更新時に適用）。これには、Workers、Containers、AI Gatewayを含む既存のDeveloper Platformログと、すべてのトレーシングデータが対象となります。

ログとトレースのサイズは劇的に異なる可能性があるため、この新しいモデルはイベントベースのカウントではなく、取り込みと保存したデータ量に基づいて課金されます。この料金体制の調整は、そのようになります。料金体制に関する詳細については、 ドキュメント をご覧ください。

5. オブザバビリティデータでカスタムアラートを構成 - ベータ版

通知機能（現在は「アラート」と呼ばれています）が大幅にアップグレードされました。これにより、HTTPリクエストログ、Workersイベント、Workers Analytics Engineデータセット、アナリティクスデータセット、トレース、セキュリティイベントなど、新しい統一SQL APIでサポートされているものであれば、あらゆるものに対してカスタムアラートを直接定義できるようになります。

ダッシュボードでデータセットを選択するか、カスタムSQLを使用して条件を定義してください。次に、しきい値、異常、またはSLOを選択し、評価ウィンドウを設定して、アラートの送信先を選択します。たとえば、オリジン5xxレスポンスが5分間しきい値を超えたとき、コンテナで障害が繰り返されたとき、デプロイ後にWorkerのエラーが増加したとき、またはトレース遅延が予想される制限を超えたときにアラート通知できます。 

インシデント管理ツール、チャットプラットフォーム、ウェブフックなど、チームがすでに使用しているツールに直接アラートを送信することができます。 ウェブフックはすべてのプランでご利用いただけますので、アラートをカスタムサービスやエージェントにルーティングして直ちに調査を開始することができます。開始するには、 ドキュメントを確認するか、エージェントに次のコマンドを入力してください。

6. ドメイン分析を1ヶ所で表示 - 30日間の保持が可能に

これまで、ドメインで何が起こっているかを把握するには、Cloudflareのさまざまな製品から指標をつなぎ合わせる必要がありました。トラフィック、パフォーマンス、セキュリティ、キャッシュ、オリジン、DNSデータをまとめて、それらの相関関係を可視化します。遅延が増加した場合、それが特定のCloudflareデータセンター、ホスト名、あるいはオリジンに関連しているかどうかを素早く確認することができます。

さらに、 すべてのプランにおいて30日間のドメイン分析が利用できるようになりました。1か月分の履歴があれば、問題が発生した後の調査、今日のデータと過去の数週間の同曜日の比較、1回限りのスパイクと長期的な傾向の違いを確認することができます。

7. カスタムダッシュボードの構築

あらかじめ構築されたダッシュボードは一般的な使用例をカバーしていますが、アプリケーションでは、Cloudflareのいくつかの部分が使用されることもよくあります。 カスタムダッシュボードを使用して、Cloudflare全体の分析、Workersプラットフォームからのログとトレース、セキュリティイベントを一元管理できます。リクエストボリューム、エラー、遅延、ストレージ、ブロックされたトラフィックを追跡し、そのダッシュボードをチームと共有できます。調査のたびにクエリを再構築する代わりに、アプリケーションにとって重要なシグナルを監視する場所を1つ用意できます。

8. Logpushがすべてのセルフサービスプランで利用可能に

これまではEnterprise限定だったLogpushが、すべてのセルフサービスプランで利用可能になりました。これにより、すべてのCloudflareログを、既にお使いのツールやターゲットにエクスポートできます。フィルターの適用、編集、イベントのエンリッチメント、または配信前のアウトプットの成形が必要な場合、 Transformationsが一般提供されました。独立したETLパイプラインを操作することなく、あらゆるSQLのTransformationを適用できます。

LogpushおよびTransformations向けに、 従量課金制を導入します。各サービスの毎月の無料枠と追加利用のシンプルな料金体制：

ドキュメントにアクセスして、Logpushの利用を開始し、完全な料金体制の詳細をご確認ください。

今後の展開：

• オブザーバビリティデータの保持期間を延長：ロギングデータとトレースデータの保持期間が最大1年間に延長されます。これにより、繰り返される問題の調査、過去の挙動の比較、長期的なトレンドの分析が容易になります。
• WorkersにおけるOpenTelemetry APIのサポート：今後もOpenTelemetry APIの構築を続け、既存のスパイクに属性を追加したり、トレースコンテキストを取得したりできるようにしていきます。
• より容易なOpenTelemetryでメトリクスのエクスポート：CloudflareのメトリクスをOpenTelemetry互換の宛先に送信し、残りのスタックからテレメトリとともに分析できます。
• 新しい料金体制は2026年12月1日に発効します：Cloudflareでオブザバビリティデータをインジェストまたはストレージしている場合、統合料金体制がご利用になられる量に適用されます。変更は事前にお知らせいたします。

調査の準備は整いましたか？

Cloudflareがブラックボックスのようだという声を耳にします。これらの更新は、何が起こっているかを明らかにし、基礎となるデータにアクセスできるようにし、アクションを起こすために必要な文脈を提供するための第一歩にすぎません。エージェントがソフトウェアの作成から運用の方向へ移行するにつれて、その透明性はさらに重要になります。エージェントは、何が起こったかをクエリで特定し、エラー箇所を特定し、修正を検証できる場合にのみ、変更と結果のループをクローズすることができます。

 OpenTelemetry、 W3C Trace Context、およびSQLを中心とした構築により、お客様とそのエージェントにそのコンテキストへの標準的でポータブルなインターフェースを提供することをお約束します。詳細は Observabilityドキュメントホームでご確認いただけます。