【要約】OpenTelemetryで始める分散トレーシング [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
マイクロサービス化に伴い、単一のリクエストが複数のサービスを跨ぐため、障害発生時の原因特定が困難になっている。従来の監視では「何が起きたか」は検知できても「なぜ起きたか」の追跡が難しく、また監視ツールごとに独自のSDKを導入する必要があるため、ベンダーロックインや計装コストの増大が課題となっていた。
// Approach
OpenTelemetryを導入し、計装を標準化することでベンダー中立性を確保する。具体的には、Pythonの自動計装機能を用いてアプリケーションコードへの変更を回避し、OTLPプロトコルでデータを送信する。中継役としてOpenTelemetry Collectorを配置し、データのバッチ化や加工、バックエンドへの転送を分離して管理する構成をとる。
// Result
Kubernetes上で、App APIからBackend APIへのリクエストが、コード修正なしでトレースとして記録されることを確認した。これにより、サービス間の親子関係（Span）やTrace IDの伝搬がJaeger UI上で可視化される。また、Collectorの設定変更のみで、送信先バックエンドを容易に切り替えられる柔軟な構成を実現した。
Senior Engineer Insight
> 本構成の肝は、Collectorを介在させることでアプリケーションの責務を「データの生成」に限定し、「データの加工・転送」をインフラ層へ切り離した点にある。これは大規模環境におけるスケーラビリティと運用柔軟性の観点から極めて正しい設計だ。自動計装は導入障壁を劇的に下げるが、複雑なビジネスロジックの深部まで追跡するには、結局は手動計装によるカスタムSpanの追加が必要になる。現場投入時は、Collectorのメモリ管理と、サンプリング戦略によるデータ量の制御をセットで検討すべきである。