Rustエンジニア必見！OpenTelemetryで実現するモダンな可観測性入門

Rust開発者がOpenTelemetryを導入し、アプリケーションの可観測性（Observability）を向上させるためのガイドです。トレース、メトリクス、ログの統合管理をRustのエコシステムでどう実現するか、その基本について解説します。

OpenTelemetryの仕様は、俺がこの業界にいる20年くらいの間、みんながずっと待ち望んでたものそのものだよ。ほぼすべての主要言語で実装されてて、機能もほぼ横並びの単一標準。昔のベンダー製フレームワークと比べたら、正直めちゃくちゃ使いやすい。4年前くらいに、RustのサービスでOpenTelemetryのメトリクスやトレースを標準的に使えるように自前でライブラリを書いたんだ。最近はOTLPロギング（技術的にはtracing eventsを使用）を追加して、ログと一緒にbaggageやコンテキスト、メタデータを送れるようにした。Rustのtracingクレートには"instrument"マクロがあるから、関数のオートインストルメンテーションもほぼ自動でできるし、コンテキストを抽出して関数内に伝播させられるから、その後のHTTPやgRPCのリクエストにトレースやスパンを繋げるのも楽勝。他にもいろいろやってて、Kafkaのメッセージにtrace-idを仕込んで、キュー待ちも含めたリクエストの全ライフタイムを追えるようにしたんだけど、これがマジで洞察に富んでいたよ。SigNozは後発だけど、OpenTelemetryをネイティブにサポートする競合やベンダーが増えるのはいいことだね。最初は大手ベンダーとも相談したんだけど、彼らはOpenTelemetryを受け入れるとは言いつつ、メトリクスを全部"カスタム"メトリクス扱いにして、自前のAPMプラグインとかいうやつを使うよりめちゃくちゃ高い料金を吹っかけてこようとしたんだ。選択肢は多ければ多いほどいい。OpenTelemetryは最高だし、Rustで使うのも基本的には素晴らしいよ。

ここで興味深いメタパターンは、問題に対するツールの整備が、問題そのものから5〜10年くらい遅れることがよくあるってことだね。運用の複雑さは現にあるし、現場の苦労も本物なんだけど、それが少数の大企業じゃなくて多くの小規模なアクターに分散してるから、構造化された解決策の市場ができるのが遅くなるんだ。でも、これは大抵行き止まりじゃなくてシグナルなんだよね。汎用的なツールじゃなくて、実際のワークフローに本当にフィットする最初のツールが、本物のレバレッジを持つってことだから。

本番でOTEL + Rustを他の言語と一緒に動かしてるけど、Rustの方が圧倒的に便利だし挙動が予測しやすい。他の言語のライブラリだと、よくログ周りにモンキーパッチを当てて対応する羽目になるけど、Rustならただ動く。（まあ、これ以外はね：https://github.com/tokio-rs/tracing/issues/2519 ）