転送 · mcpd

11 個のエクスポーターではなく、出口は 1 つのプロトコル

mcpd は OTLP を受け取り、OTLP を送出できます。この 1 つの性質が、ベンダーごとのエクスポーターの集まりがすることの大半を肩代わりします。Langfuse、 Datadog、Honeycomb、Grafana をはじめ、名前を挙げる価値のある送信先はどれも HTTP 上の OTLP を受け付けます。したがって転送は 11 個ではなく 1 つの実装で済み、あるベンダーの SDK のリリースに遅れることもありません。

これは、mcpd の採用が取り消せるということでもあります。これまで使っていたものに向けて転送し、2 週間ほど両方を動かし、取り消せない移行に賭けるのではなく、目の前のデータを見て決めてください。

有効にする

ローカルに保存し、先へ複製する

mcpd serve --forward-endpoint https://otlp.example.com

パスは自動で付け足されるので、/v1/traces ではなくベースの URL を渡してください。資格情報が必要な送信先には、ヘッダーを足します。

認証ヘッダー付きで

mcpd serve \
  --forward-endpoint https://otlp.example.com \
  --forward-header 'Authorization: Bearer $TOKEN'

同じ設定は、設定ファイルの forward の下にもあります。そこでは batch_size と enabled も使えます。フラグはファイルより優先されるので、共有の ConfigMap を編集せずに、1 つのインスタンスだけ別の宛先へ向けられます。

{
  "forward": {
    "endpoint": "https://otlp.example.com",
    "headers": [["Authorization", "Bearer sk-..."]],
    "batch_size": 256,
    "enabled": true
  }
}

Ingest pipeline

Decode

OTLP or native, gzip or plain
Sample

Decided once, at the root
Redact

Before anything is written
Price

From the configured price book
Store

One transaction per batch

Redaction is stage three, not a cleanup job. A value that a rule matches never reaches storage at all.

ローカルへの保存が先に起きます

スパンは、何かが転送されるより先に mcpd 自身のストアへ書かれ、転送はその後、独立したタスクで走ります。ここから 2 つの帰結が出てきます。どちらも意図したものです。

遅い送信先が、そのスパンを生んだリクエストに自分のレイテンシを足すことはありません。あなたのエージェントが、他人のコレクターを待つことはありません。

落ちている送信先が、取り込みの拒否に化けることもありません。mcpd は動き続け、転送は独立したタスクで再試行されます。もう一方のやり方、つまり他社の障害であなたのテレメトリーがまったく残らなくなるやり方こそ、この設計が避けるためにある失敗です。

各バッチには 3 回の試行があります。429、5xx、または接続の失敗は 250 ms 後に再試行され、待ち時間は試行のたびに倍になります。秒で指定された Retry-After は、30 秒を上限としてこの待ち時間の代わりに使われます。それ以外の 4xx は最初の応答で確定します。そのバッチは、その送信先にとって不正な形のままだからです。デーモンが停止する途中なら、残りの試行をすぐに行います。最終的に拒否されたバッチや、最後の試行の後も未配送のバッチはログに記録され、そのスパンは mcpd_forward_dropped_spans_total に加算されます。これで、コピーのどれだけが欠けているかがわかります。

接続を受け付けたまま決して応答しない送信先も、デーモンのメモリを奪うことはできません。送信先を同時に待てるのは、取り込みリクエスト 64 件分のコピーまでです。それだけ待っている間は、新しいコピーはその場で破棄されて mcpd_forward_dropped_spans_total に数えられ、ローカルへの書き込みには影響しません。

永続的な送信キューはありません。バッチは再試行の間メモリ上で待ち、転送キューが満杯のときは新しいバッチが捨てられ、そのスパンは同じメトリクスに数えられます。永続的なキューは別の製品であり、黙ったまま何時間も遅れるキューは、目に見える欠落より悪いものです。配送の保証が必要なら、mcpd と送信先の間に本物のコレクターを置き、それが作られた目的の仕事をさせてください。

秘匿化は、出ていくものにも適用されます

転送は取り込みパイプラインの後で起きます。そのパイプラインは、何かが書かれる前にその場で秘匿化します。mcpd が隠すよう指示されたものは、次の区間にも届きません。ストレージは守るのに出口は守らないルールは、プライバシーの制御とは呼べません。

何が転送されるか

スパンです。ログ、メトリクス、スコア、フィードバック、観点ノートは mcpd に残ります。人が転送する先はトレーシングのバックエンドであり、それ以外は捨てるか、属性に押し込んで壊してしまうからです。

スパンはサービスごとにまとめられて resourceSpans になります。受け取り側が期待する形です。スパンごとに 1 つのリソースを置く形も規格上は正しいのですが、下流のすべてにまとめ直させることになります。

mcpd から mcpd への転送

両端が同じプロトコルを話すので、ローカルの mcpd から共有の mcpd へ転送できます。開発者は自分のマシンに、ペイロードを丸ごと持つ速いストアを持ち、チームのインスタンスは同じ実行を受け取って、到着時に自分の保持期間と自分の秘匿化ルールを適用します。

次に

既存の OpenTelemetry の構成を mcpd に向ける： OpenTelemetry。
スパンが保存され、送られる前に取り除かれるもの：秘匿化と保持期間。
すべてのフラグとファイル設定：設定。