観測の共通語彙と製品境界

対象本文

第11章のOpenTelemetry semantic conventions、FaaS、messaging、生成AIのtrace/metric/log、各cloudへのexport境界を補います。

収集方法

2026年7月10日にOpenTelemetry Semantic Conventions 1.43.0と、AWS、Google Cloud、Microsoft Azure、Cloudflareの公式観測資料を確認しました。SDKが送れること、backendが保存・検索できること、semantic conventionがstableであることを別々に記録しています。

現在の答え

OpenTelemetryは、trace、metric、logを送るprotocolだけでなく、attribute名、span名、metric単位、意味を揃えるsemantic conventionsを提供します。1.43.0にはFaaS、messaging、database、cloud provider等があり、生成AIの規約は独立repositoryへ移されています。

共通化できるものprovider差が残るもの
instrumentationOTel API/SDK、context propagation、semantic attributesmanaged runtimeが自動で付けるfield、runtime extension
transportOTLP、collector、vendor exporternetwork path、authentication、batching、sampling制約
backendtrace/metric/logの保存とqueryindex、retention、cost、cross-signal correlation、alert syntax
serverless platforminvocation、cold start、duration、error等platform event名、billing metric、concurrency、log delivery
agent/genAImodel、operation、token usage、tool/agent span等convention stability、provider response field、prompt/content capture

四社ともOpenTelemetryを受け入れる方向へ進んでいますが、同じ採用ではありません。AWSはADOT/collectorとCloudWatch/X-Ray、GoogleはOpenTelemetry instrumentationからCloud Trace/Monitoring/Logging、MicrosoftはAzure Monitor OpenTelemetry DistroとApplication Insights、CloudflareはWorkers tracingとOTLP exportをそれぞれのruntime境界へ結びます。

共通語彙を使っても、run_idrelease_id、tenant、model/prompt/tool版、approval、side effect ID、quality resultは本書のapplication contractとして追加する必要があります。逆にprompt、response、retrieved document、tool argumentを既定で全文記録してはいけません。OpenTelemetryの生成AI規約も、contentが機微情報を含み得ることを前提にopt-inとredactionを設計します。

観測の互換性は、同じdashboardがそのまま動くことではありません。元のtelemetryに意味のある共通attributeが残り、別backendで同じ問いを再構成できることです。sampling、aggregation、retentionで失われたdataはexporterを替えても戻りません。

一次資料

既知の未知

変更履歴