【要約】SDK も Collector も使わずに OTLP を手組みして送る [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
ログパイプライン等の開発において、SDKが通信の詳細を隠蔽することが、プロトコルの理解を妨げる課題となっている。具体的には以下の問題がある。
- ・SDKがバッチ化やシリアライズを自動化するため、ネットワーク上のOTLP構造がブラックボックス化する。
- ・「他所のログを預かってOTLPに変換する」立場では、SDKが隠蔽しているProtobufのエンベロープ構築を自前で行う必要がある。
- ・通信内容が正しく構築されているか、低レイヤーの視点で検証する手段が不足している。
// Approach
SDKやProtobufライブラリに頼らず、Python標準ライブラリのみでLogRecordをバイト列へ変換する最小構成を実装する。以下のステップで検証を行う。
1.opentelemetry-proto v1.0.0の定義に基づき、field numberとwire typeを特定する。
2.varint、fixed64、length-delimitedといったProtobufのwire formatを自前で実装する。
3.構築したペイロードを、OTLP/HTTP（application/x-protobuf）とOTLP/gRPC（HTTP/2 framing）の両形式で送信する。
4.OpenTelemetry Collectorを用いて、手組みしたバイト列が正しくデコードされるかを確認する。
// Result
手組みしたペイロードが、公式のOpenTelemetry Collectorによって正しくデコードされることを確認した。得られた成果は以下の通りである。
- ・OTLPが「データ（Protobuf）」と「運び方（HTTP/gRPC）」を明確に分離している設計思想を実証した。
- ・proto3の仕様である「デフォルト値の省略」が、バイト列の削減に寄与する仕組みを定量的に示した。
- ・gRPCにおける5バイトのフレーム構造と、HTTPにおけるペイロードの差異を明確に分離して理解できた。
Senior Engineer Insight
> SDKがブラックボックス化しやすいプロトコルの「境界」を可視化した良記事だ。大規模システムにおいて、通信の不整合をデバッグする際、この低レイヤーの視点は不可欠である。特に、データ構造とトランスポートが分離されている設計は、将来的な拡張性や異なる通信環境への適応力を担保する上で極めて重要だ。実用的な実装には再送制御や接続管理が必要だが、プロトコルの設計思想を理解する教材として非常に価値が高い。