【要約】Pythonで簡単にOTelを使ってみる [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がログから特定の情報を抽出したい際、従来のテキストベースの出力では限界がある。ログ本文に値を埋め込む運用では、以下の問題に直面する。
- ・特定の条件（金額やユーザーID）による検索や集計が困難になる。
- ・大量のログから特定のイベントを追跡するコストが高い。
- ・ログが非構造化であるため、機械的な解析や可視化に適さない。
// Approach
既存のloggingコードを書き換えずに、OpenTelemetryの仕組みを導入するアプローチを採用する。具体的には以下のステップで構築を行う。
- ・
LoggingHandlerを用い、標準のlogger.info()等の出力をOTelへ転送する。 - ・
Resourceを定義し、service.nameによってログの出所を識別可能にする。 - ・
extra=引数を利用して、ログ本文とは別に構造化された属性（attributes）を付与する。 - ・
BatchLogRecordProcessorを採用し、ログをまとめて送信することで転送効率を高める。 - ・
OTLPプロトコルを用いて、ログをGrafana/Lokiへ転送する。
// Result
ログが構造化データとしてLokiに格納され、Grafana上で高度な分析が可能になる。これにより、運用担当者は以下の操作を容易に行える。
- ・
service_nameを用いたサービス単位のフィルタリング。 - ・
order.amountなどの属性値に基づいた、金額による絞り込みや集計。 - ・例外発生時に、
exception.stacktraceなどの属性を用いた詳細なエラー解析。
Senior Engineer Insight
> 既存のloggingコードを書き換えずにOTelへ移行できる点は、大規模システムへの導入において極めて現実的である。属性情報を
extra=で分離する設計は、検索性と運用性を劇的に向上させる。ただし、本記事の例ではtrace_idが欠落しており、分散トレーシングとの連携には追加実装が必要だ。また、バッチ送信時のforce_flush()漏れはログ欠損に直結するため、終了処理の厳格な管理が求められる。