Workerの速度が低下したり、エラーが発生し始めた場合、根本原因を特定するために何時間もかけてログ分析と試行錯誤のデバッグを必要とするべきではありません。アプリケーションのリクエストフローの各ステップで何が起こっているかを明確に可視化する必要があります。これは、Workersを使っている開発者から大量に寄せられているフィードバックであり、本日、Cloudflare Workersのトレースのオープンベータを発表できることを嬉しく思います。次のことが可能になります。
Workersプラットフォーム上のアプリケーションに自動インスツルメンテーションを導入: 手動セットアップ、複雑なインスツルメンテーション、コード変更は不要です。設定不要で機能します。
Cloudflareダッシュボードでトレースを調査・調査:トレースは処理され、Workers Observabilityダッシュボードで既存ログと共に利用できます。
ログとトレースをOpenTelemetry互換プロバイダーにエクスポート: OpenTelemetryトレース(および相関ログ)を、選択した可観測性プロバイダーに送信します。
2024年、当社はクラウドプラットフォームで最高のファーストパーティ可観測性を構築することに着手しました。Workerのパフォーマンスに関するより優れたインサイトを提供するために、新しいメトリクスダッシュボードをリリースしました。Workers Logsは、Workersのログを自動的に取り込み保存するため、あらゆるディメンションにわたるデータを調査するためのクエリビルダー、そしてリアルタイムでログをストリーミングするためのリアルタイムログをリリースしました。高度なフィルタリング機能によるものです。今日から、自動トレースを有効にすることで、Workersアプリケーションをさらに深く理解できるようになります!
WorkersがOpenTelemetryに準拠したスニペットをトレースして出力し、Workerが実行するすべての操作に関する詳細なメタデータとタイミング情報を表示します。パフォーマンスのボトルネックを特定し、エラーを解決し、WorkerがWorkersプラットフォーム上の他のサービスとどのように相互作用しているかを理解するのに役立ちます。次のような質問に回答できるようになりました:
Tracingは、さまざまな操作を通じた各呼び出しの行程を可視化するものです。各操作はスポークとしてキャプチャされ、何が起こったか、どれだけの時間がかかったかを示す時間帯のセグメントです。子スパンは、親スペルの中にネストされ、サブ操作や依存関係を表示し、呼び出しの実行フローを階層的なビューで表示します。各範囲には、デバッグやフィルタリングイベントの詳細を提供するコンテキストメタデータや属性を含めることができます。
以前は、アプリケーションのインストゥルメントには、OpenTelemetry仕様、複数のOTelライブラリ、およびそれらの相互関係を理解する必要がありました。実装は面倒で、アプリケーションのロジックを難読化するインストルメンテーションコードでコードベースが肥大化しました。
トレースの設定には通常、サードパーティのSDKとの統合、すべてのデータベース呼び出しとAPI呼び出しをインストルメンテーションコードでラップし、単一のトレースを見る前に複雑な設定ファイルをデバッグするための時間がかかりました。この実装オーバーヘッドにより、観測可能性が後付けされがちで、問題が発生した時に本番環境で完全な可視性が得られません。
Workers Tracingが魔法をよく使うのは、完全自動化です。セットアップもコード変更も、時間を浪費することもありません。WorkersのすべてのI/O操作を自動的に計測するというアプローチをとりました。Workersのランタイムであるworkerdとの深い統合により、Workersのすべての呼び出しを通じてデータフローの全範囲を把握できるようにしたのです。
アプリケーションロジックに集中している。計測はCloudflareが担当します。
本日対象となる業務は次のとおりです:
バインディングコール:様々なWorkerバインディングとの相互作用。KVの読み込みと書き込み、R2オブジェクトストレージ操作、Durable Objectの呼び出し、その他多くのバインディング呼び出しが自動的にトレースされます。これにより、Workerが他のサービスをどのように使用しているかを完全に可視化できます。
フェッチコール:すべてのアウトバウンドHTTPリクエストは自動的に計測され、タイミング、ステータスコード、リクエストのメタデータを取得します。これにより、アプリケーションのパフォーマンスに影響を与えている外部依存関係を迅速に特定できます。
ハンドラーコール: フェッチハンドラー、スケジュールされたハンドラー、キューハンドラーなど、外部入力を受信して処理できるWorkerのメソッド。これにより、Workerがどのように呼び出されているかのパフォーマンスを可視化できます。
当社の自動インストルメンテーションは、各操作をスプリットとして捕捉します。たとえば、R2バインディングコール(getまたはput操作など)によって生成されるスパンには、操作タイプ、エラー(該当する場合)、オブジェクトキー、および期間など、利用可能な属性が自動的に含まれます。これらの詳細な属性は、すべての詳細を手動でログに記録することなく、アプリケーションに関する正確な質問に答えるために必要なコンテキストを提供します。
今後も、範囲により詳細な属性を追加し、複数のWorkersや外部サービス全体で呼び出しを追跡する機能を追加していく予定です。当社のドキュメントには、測定対象範囲とその属性の完全なリストが含まれています。
Cloudflareのダッシュボードで、特定のWorkerアプリ内のトレースを簡単に表示でき、アプリのパフォーマンスを即座に可視化することができます。ご希望の時間枠内のすべてのトレースイベントのリストと、各呼び出しの期間や使用可能な属性を含む各呼び出しのトレースを視覚化することができます。また、アカウント上のすべてのWorkersからクエリーを実行すると、複数のアプリで発生している問題を特定することができます。
Workersアプリケーションでトレースの表示を開始するには、以下の設定を行います:
OpenTelemetry互換プロバイダーにトレースをエクスポート
しかし、一部の開発チームが、すでに使用しているツール内で他のテレメトリデータと共存する必要があるWorkersがあることを認識しています。そこで今回、トレースエクスポートも追加し、お客様のチームが既存の可観測性スタックでデータを送信、可視化、クエリできるようにします!本日より、Honeycomb、Grafana、Sentry などのプロバイダー、または利用可能なエンドポイントを持つその他の OpenTelemetry プロトコル(OTLP)プロバイダーに直接トレースをエクスポートできるようになりました。
また、同じトレースIDを共有するOTLP形式のログのエクスポートもサポートしており、サードパーティのプラットフォームがログエントリーと対応するトレースを自動的に関連付けることができます。これにより、スプリットと関連するログメッセージ間を簡単に移動できます。
選択した宛先にイベントを送信するには、まず、CloudflareダッシュボードでOTLPエンドポイントの送信先を設定します。すべての宛先について、カスタム名を指定し、APIキーやアプリ設定を含めたカスタムヘッダーを設定することができます。
宛先を設定したら(例:Honeycomb-tracing )にアクセスし、wrangler.jsonc で以下を設定し、デプロイします:
これは、ご希望のテレメトリーデータをご希望の場所で取得するためのワークフローとツールを提供するWorkersの始まりに過ぎません。ダッシュボードでのネイティブトレースと、他のタイプのテレメトリのサードパーティへのエクスポートのサポートを改善しています。今後数か月以内に、以下を発表します。
より多くのスパンと属性のサポート: Workersプラットフォームのあらゆる部分に、さらに自動トレースを追加しています。最初の目的は、リクエスト内のすべての操作の期間を可視化することですが、詳細な属性を追加することもしたいと考えています。不足している点についてのフィードバックは、ここで非常に貴重です。
トレースコンテキストの伝達:分散型アプリケーションを構築する場合、トレースがすべてのサービス(Cloudflare外のサービスも含む)に接続していることを確認し、自動的に範囲をリンクしてエンドツーエンドの完全な可視性を実現することが重要です。たとえば、Workersからのトレースは、親サービスからネストすることができ、その逆も同様です。完全に実装すると、自動トレースコンテキストの伝達はW3C基準に準拠し、既存のツールとサービスとの互換性を確保します。
カスタム範囲と属性のサポート:自動インストルメンテーションにより、Workersプラットフォーム内で何が起こっているかを可視化できますが、お客様独自のアプリケーションロジックも可視化する必要があることを私たちは知っています。そのため、お客様にも独自の範囲を手動で追加できるようにします。
メトリクスのエクスポート機能:現在、Workersダッシュボード内でメトリクス、ログ、トレースを監視・表示できるようになりました。インフラストラクチャメトリクス(リクエスト量、エラー率、実行時間など)とカスタムアプリケーションメトリクスの両方を、お好みの可観測性プロバイダーにエクスポートできるようになったことは、最後にお伝えしたいと思います。
現在、ベータ版の開始にあたって、Cloudflareダッシュボードでトレースを表示することも、サードパーティプロバイダーにトレースをエクスポートすることも無料です。2026年1月15日に、トレースとログイベントには以下の料金が請求されます:
CloudflareダッシュボードでWorkersのトレースを表示する
Cloudflareダッシュボードでトレースを表示するには、Workers Freeおよび有料プランを以下の価格設定で表示できます。
|
Workers 無料 |
Workers 有料 |
| 含まれるボリューム |
1日あたり20万件のイベント |
2,000万イベント/月 |
| 追加イベント |
無回答 |
100万ログあたり0.60ドル |
| 保管 |
3日 |
7日 |
トレースとログのエクスポート
サードパーティのOTLP互換先にトレースをエクスポートするには、Workers有料サブスクリプションが必要です。価格設定は、以下の含むスパンまたはログイベントに基づいています:
|
Workers 無料 |
Workers 有料 |
| イベント |
使用不可 |
1,000万件/月 |
| 追加イベント |
100万件のバッチイベントにつき0.05ドル |
Workersアプリケーションのトレースを始めませんか?
ドキュメントをご覧ください:セットアップの方法、現在の制限、今後の詳細についてご確認ください。
GitHubディスカッションにご参加ください:お客様のフィードバックは、自動インストルメンテーション、ダッシュボードの追跡、OpenTelemetryのエクスポートフローに関するベータ期間中、非常に貴重なものになります。GitHubディスカッションに移動して問題を提起したり、機能リクエストを送信したりして、私たちにご連絡ください!