先日、XでO'Reillyの書籍を全巻そろえたという本屋の投稿を見かけた。その週末、早速足を運んだ。
本当にO'Reillyの本がズラッと並んていた。さっと眺めるつもりで『入門 OpenTelemetry』を手に取ったが、気づけばその場で最後まで読んでいた。
OpenTelemetryという名前はよく聞くが、これまで自分の中では「ログやメトリクスを集めるための新しい仕組み」くらいの理解だった。本書を読んで、OpenTelemetryは単に計測用ライブラリを入れる話ではなく、複雑になったシステムをどう理解し、運用していくかという話なのだと感じた。
印象に残ったのは、テレメトリーという言葉そのものの歴史だった。遠隔地の情報を電線に載せて伝えるための考え方から始まり、今では分散システムの状態を知るためのデータ全般を指す。言葉としては意外なほど古い。一方で、現代のクラウドネイティブなシステムでは、サービス数も依存関係も増え、テレメトリーを扱う難しさは昔とは比べものにならない。
これまでは、各システムや各ベンダーが独自の形式でログ、トレース、メトリクスを集めてきた。個別には見えていても、システムをまたいで原因を追うとなると途端に難しくなる。OpenTelemetryは、こうした計測データを共通の規格で扱い、特定のクラウドや監視サービスに縛られずに横断的な観測を可能にする。ログ、トレース、メトリクスはそれぞれ単体でも役に立つ。ただ、三つを同じ文脈で結びつけたときに見えるものがある。メトリクスで異常を見つけ、トレースで影響したリクエストやサービス間の流れを追い、ログでその時点の詳細を確認する。どれか一つだけでは判断できないことでも、相関できれば原因に近づける。OpenTelemetryが既存のログ形式をすべて矯正する仕組みではない点も良い。レガシーなシステムまで含めて、すべてを一度に同じ形へ作り変えるのは現実的ではない。Collectorを間に置き、既存のさまざまな形式のデータを受け取り、必要に応じて変換・加工して収集基盤へ送る。既存資産を捨てずに、少しずつ観測の基盤をそろえられる。
本書の中で特に刺さったのは、「フィルタリングは安易、サンプリングは危険」という言葉だった。ある一点だけを見れば意味がなさそうなデータでも、別のログやトレースと紐づいた瞬間に価値を持つことがある。コストやデータ量を理由に何を残し、何を捨てるかを決める前に、まず何を知りたいのか、障害が起きたときにどんな問いへ答えたいのかを考える必要がある。OpenTelemetryを導入すること自体が目的ではない。システムで何が起きているかを知り、問題を早く見つけ、適切に判断できる状態をつくることが目的だ。本書はそのために必要な考え方から、計装、Collector、パイプライン設計、組織への展開までを一通り扱っている。OpenTelemetryを触ったことがない人にも、すでに運用していて設計を見直したい人にも、最初に読む一冊としてよい本だった。