Practical OpenTelemetry
- 属性をプロパゲートするためのBaggage APIが存在していた
- 各種プロバイダは otel.Meter() 等でグローバルなプロバイダを返せるけれど、グローバルを経由せずDI等で引き渡すほうがいいらしい、これは本当か?Java固有の話なのか?
- メーターとトレーサーにはWithSchemaURLオプションがあって、スキーマを定義できる
- 全体的に、カーディナリティが高い属性がノイズとなる話であってり、全体にほぼ影響がないスパンは無視するほうがいいと言ったり、正常なトレースはストレージの無駄になると言ったり、いかにノイズとなる要素を削減するのかについての記述がそこそこある印象
- トレースにはマーカーとして Event を追加できるらしい
- スパンはリンクできるので、なんらかのバックグラウンドジョブを実行して親はすぐに終了する場合、この2つをリンクしておくと追跡が容易になる
- スパンの名前は後から setName で変更できるので、ハンドラ側でURLの一部をプレースホルダーに変更するとカーディナリティが下がって見通しがよくなる
障害対応のテンプレートに入れるといいかも。
- オンコールのエンジニアがもっと早くアラートを受け取れなかったのはなぜですか?
- SLOはサービスの信頼性要件を正確に表していますか?
- 他のサービスへの影響はどうでしたか?そちらには通知されていましたか?
- リグレッションの原因は依存関係なのか、それとも単一のサービスに限定されていたのか、エンジニアはどのように識別しましたか?
- このインシデントをデバッグするために使用したシグナルは何ですか?
- 他の既存のシグナルから、同じ結論をより早く導く方法を見つけることはできるでしょうか?
- デバッグ体験を向上させるために、カスタム計装で不足しているものはありますか?