Logs & Observability

traceparentパーサーとW3C Trace Context検証ツール

traceparentヘッダーを貼り付けると、version・trace-id・parent-id・flagsをフィールドごとに解析します。複数ヘッダーの一括検証やテスト用ヘッダーの生成にも切り替え可能です。

traceparentパーサー

traceparentヘッダー

解析と生成はすべてブラウザ内で完結します。アップロードやトレーシングバックエンドへの送信は一切ありません。

結果

traceparentヘッダーを貼り付けるか、例を読み込んでください。

traceparentヘッダーは「-」で区切られた4つのフィールドだけの単純な文字列に見えますが、あるサービスのログでtrace-idがすべて0になっていたり、途中のプロキシが仕様で明確に禁止されているversion値に書き換えてしまうことがあります。このtraceparentパーサーはW3C Trace Contextの実際の文法に沿って各フィールドを検証するため、「見慣れないだけで正しい」のか「そもそも壊れている」のかを見分けられます。

サービス間でトレースが途切れて原因がヘッダー自体にあるか確認したいとき、手動でヘッダー伝播を実装していてテスト用のヘッダーが欲しいとき、ログに並んだ大量のtraceparent値を1つずつ目で確認する代わりにまとめて検証したいとき——そんな場面で使うツールです。

このtraceparentパーサーを使う理由

すでに正しいヘッダーをきれいに表示するためではなく、本物のヘッダー不具合を突き止めるために作られています。

全フィールドを色分けして解析

このtraceparentパーサーはヘッダーをversion・trace-id・parent-id・trace-flagsに分解し、それぞれを別の色で表示します。flagsバイトはサンプリングの有無や予約ビットの意図しない立ち上がりまで平易な言葉で説明します。

traceparentヘッダーを4つの色分けフィールド(version、trace-id、parent-id、trace-flags)に分解した図

仕様が明確に禁止する3パターンを確実に検出

version ff、trace-idがすべて0、parent-idがすべて0——これらは形式上は16進数として成立していますが、W3C Trace Contextで明確に禁止されています。このtraceparentパーサーは長さと文字種だけでなく、この3パターンを名指しで検出します。

仕様が禁止する3パターン(version ff、trace-idがすべて0、parent-idがすべて0)を示した図

ざっと見ただけでは気づけないチェック内容

本番ログからヘッダーを貼り付ける前に知っておきたい3つのこと。

01

ヘッダーを1件貼り付けるか、境界値の例を読み込む

入力が止まってから300ms後に自動的に解析されます——自動解析をオフにしない限りボタン操作は不要です。3つの例ボタンは適当に選んだものではなく、有効な例・version ffの例・trace-idがすべて0の例という、仕様が名指しする3つの境界ケースを読み込みます。

  • Ctrl/Cmd+Enterでディバウンスを飛ばして即座に解析できます
02

tracestateを追加するか、一括検証モードに切り替える

すべてのヘッダーがtracestateを持つわけではないため、tracestate入力欄は初期状態で折りたたまれています。オンにするとvendor=valueの各ペアを仕様の32件上限・256文字上限に照らして検証します。1件ではなくログ全体を確認したい場合は一括検証モードに切り替え、1行に1件ずつ貼り付けてください。

  • 一括検証モードはあえて手動実行にしています——貼り付け途中に1文字ごと再実行されると邪魔になるためです
03

フィールドごとの結果を確認し、コピーまたはエクスポートする

version 00のヘッダーは完全に検証されます。それより大きいversionはフィールドは解析されますが、末尾の追加データはそのまま表示されるだけで解釈はされません。入力を編集した瞬間にコピーとダウンロードは無効化されるため、古い結果を誤ってエクスポートすることはありません。

  • 生成モードに切り替えると、テストリクエスト用に仕様に準拠した新しいtraceparentを作成できます

パーサーとジェネレーターが実際にしていること

ハイフンの位置だけを見る正規表現ではなく、W3C Trace Contextに沿った本物の検証です。

4フィールドの完全な分解

version・trace-id・parent-id・trace-flagsをそれぞれ個別に解析してラベル付けし、サンプリングビットの平易な解説も表示します。

仕様に忠実な厳格な検証

version ff、trace-idがすべて0、parent-idがすべて0、フィールド長の誤り、大文字の16進数——これらは緩い正規表現なら見逃しがちなケースです。

行単位の要約付き一括検証

ログ抜粋のtraceparent値をまとめて貼り付けると、有効・無効・空行の件数と、不正な行ごとにどのフィールドが原因かがわかります。

tracestateの構造チェック

key=valueメンバーを仕様のkey文字種、tenant@vendor形式、256文字のvalue上限、32件のメンバー上限、keyの重複禁止に照らして検証します。

仕様に準拠したテスト用ヘッダー生成

暗号学的に安全な乱数でtrace-idとparent-idを非ゼロで生成し、version 00のtraceparentを作成します。無効なプレースホルダー値でテストしてしまう心配がありません。

このツールが検証すること、あえてしないこと

「検証成功」を「トレーシングが正常」と思い込む前に読んでください。

有効なヘッダーはトレースの実在を証明しない
このツールは文字列をW3C Trace Contextの文法に照らして検証するだけです。Jaeger、Datadog、Honeycombなどのバックエンドには一切接続しないため、「有効」は「形式が正しい」ことだけを意味し、「実際に記録された」ことは意味しません。
対応するのはW3C Trace Contextのみ
ZipkinのB3ヘッダー、Google CloudのX-Cloud-Trace-Context、Sentryのsentry-traceはフィールド数や区切り文字が異なります。このパーサーはこれらの形式を読み取ったり変換したりしません。
不正な入力は報告するだけで、勝手に修正しません
31文字のtrace-idにゼロを補ったり、検証前に大文字の16進数を小文字に変換したりはしません。どちらもトレース伝播を実際に壊す典型的なミスなので、隠さずに表示します。
一括入力の上限は500行
すべての処理はブラウザタブ内で完結するため、非常に大きなログの貼り付けは端末の利用可能メモリに制約されます。より大きなログは500行以下に分割してください。

traceparentパーサーに関するよくある質問

W3C Trace Contextヘッダーをデバッグする中で実際に出てくる疑問です。

trace-flagsのサンプリングフラグ(01)は何を意味しますか?

trace-flagsは16進数2桁で表される1バイトで、ビット0がサンプリングフラグです。01は呼び出し元がこのトレースをトレーシングバックエンドに記録することを推奨している状態、00は推奨していない状態を示します。あくまで呼び出しチェーンに沿って伝わる推奨値であり、実際にどこかのシステムがトレースを記録した保証ではありません。

trace-idとspan-idの違いは何ですか?

trace-idは分散トレース全体を一意に識別するIDで、リクエストが通過するすべてのサービスで共通です。span-id(W3C仕様ではparent-id)はチェーン内の1つの処理単位を識別するIDで、サービスを経由するたびに新しい値になりますが、同じtrace-idを共有します。

traceparentとtracestateの違いは何ですか?

traceparentはversion・trace-id・parent-id・trace-flagsという4つの必須フィールドを運び、W3Cに準拠するすべてのシステムがこれを理解できる必要があります。tracestateは任意項目で、各トレーシングベンダー独自のkey=valueデータを、他のシステムに理解を要求せずに付加できます。

traceparentのversionがffだと、なぜ無効なのですか?

W3C Trace Context仕様はffを将来のバージョン番号と混同しないよう予約しており、ヘッダーの他の部分がどれだけ正しい形式でも明確に禁止されています。このツールは単なる16進数2桁としてではなく、version ffの問題として名指しで検出します。

trace-idがすべて0だと、なぜ無効なのですか?

すべて0のtrace-idは何も識別できないため、仕様で明確に禁止されています。「32個の0」は16進数の形式チェックだけを見れば通過してしまいますが、それでも無効です。parent-id(span-id)がすべて0の場合も同様に無効です。

不正なW3C Trace Contextヘッダーはどう修正すればよいですか?

まずこのツールで解析し、どのフィールドが原因かを正確に確認してください。実際の不具合の多くは、プロキシやログ基盤がヘッダーを途中で切り詰めたり、大文字の16進数を混入させたり、実際に生成したIDの代わりにすべて0のようなテンプレート値をそのまま転送してしまったりすることが原因です。

このパーサーが誤って判定したヘッダーを見つけましたか?

今すぐtraceparentパーサーを使う

traceparentヘッダーを解析したり、複数まとめて検証したり、テスト用の新しいヘッダーを生成したり——すべてブラウザ内で完結し、アップロードは一切ありません。

サービス間でトレースが途切れたときのために、ブックマークしておいてください。

HeyUtilsの開発・運用ツールカテゴリーの1つです。