オープンソースの可観測性

第7章. 可観測性の今後の動向

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

この原稿を書いている時点で、OpenTelemetryは急速に進んでいる目標だ。2025年以降の主な取り組みのひとつに、セマンティック規約（フェーズ1）とスキーマ（フェーズ2）の開発を支援するRustベースのプラットフォーム、OTel Weaverのさらなる開発がある。将来の段階では、開発者はシステムを拡張するためにWebAssembly（Wasm）プラグインを追加する計画も立てている。

Go SDKの自己観測性と、Goランタイムメトリクス、ログAPI、otelhttpを含む多くの機能の安定化は、2025年にOTel Goプロジェクトから提供される予定である（Yahn 2025）。また、eBPFを使用したGo自動計測の最近のベータリリースがあり、手動でコードを修正したりバイナリを再構築したりすることなく、Goアプリケーションからトレースを収集できるようになった（Yahn and Dame 2025）。

プラットフォーム・エンジニアリング・チームの経験を強化する

遠隔計測の最終的なコンシューマは、SRE、DevOps エンジニア、そしてプラットフォーム・エンジニアである。一日の終わりには、可観測性ソリューションが彼らの仕事をより速く、より簡単に、より成功に導くかどうかが問われなければならない。そして、彼らの経験を通じて、企業はシステムの信頼性、可用性、スケーラビリティ、パフォーマンス、そして何よりも演算子のコスト効率が向上していることを実感しているのだろうか。

可観測性ソリューションは、チームの認知的負荷をどの程度増大させるだろうか？それは、彼らの日々のルーチンワークと、重要な問題管理という緊急の活動時間の両方に、自然かつシームレスに適合しているだろうか？

よくアーキテクトされた可観測性スタックは、それ自体が邪魔になるようなものであってはならない。むしろ、可能な限り目立たないことが理想である。洞察そのものに最も焦点を当てるべきである。そのメトリックは何を意味するのか？このしきい値を超えるとどうなるのか？この公称条件に対する例外をどのようにプレイブックに書くべきか？

SRE は、可観測性ソリューションそのものが問題であるかどうかを、どのレイヤにおいても心配する必要はない。例えば、壊れたり信頼できない遠隔測定パイプラインや、思ったようにカスタマイズできない気難しいダッシュボードなどだ。危機に瀕している時、心配しなければならないのは、可観測性プラットフォーム自体のお守りである。通常の日常でさえ、プラットフォームが広告通りに動くようにすることだけが苦労の半分であるかのように感じたくはないだろう。

そのためには、可観測性ソリューション自体に可観測性のベストプラクティスを再帰的に適用する必要がある-Quis custodiet ipsos custodes?(大雑把に訳すと「誰が監視員を監視するのか？」)に相当する。自社の可観測性システムを計測し、それ自体が自社のオペレーションの非効率性や可観測性ギャップの原因になっていないことを確認する必要がある。

かつては、可観測性のために構築されたシステムやツールは、ビジネス・オペレーションには全く適していなかった。現在では、オペレーションと可観測性アナリティクスを同じツールセット上に統合することができれば（そして、or演算子は継続的にそれが可能であること、またそれを望んでいることを実証している）、オペレーションの複雑さとコストを最小限に抑えることができる。しかし、これはまだ常に可能というわけではない。実運用で使用しているデータベースが、可観測性プラットフォームに最適な場合もあれば、そうでない場合もある。願わくば、本書が、現在の技術エコシステムとチームのニーズに合わせて、独自の可観測性スタックを構築する方法のガイドを提供できたことを願っている。 ...