@hihihiroroのLog

ダラダラと。本ブログは、個人の意見であり、所属会社とは関係がありません。

「入門 OpenTelemetry」を読んだ

あまり大きくないシステムで、同期的に動く必要がないものを開発するときにLambda やCloud Run などを選ぶことが多くなった。
同期はしていないが、順番に動いているシステムが多いため連続してのログやメトリクスを見たいことが多い。そのため気になっていたので読んでみることにした。

目次は以下。

1章 最新のオブザーバビリティの現状
2章 なぜOpenTelemetry を使うのか
3章 OpenTelemetry 概要
4章 OpenTelemetry のアーキテクチャ
5章 アプリケーションの計装
6章 ライブラリの計装
7章 インフラストラクチャの観測
8章 テレメトリーパイプラインの設計
9章 オブザーバビリティの展開
付録A OpenTelemetry プロジェクト
付録B さらなる資料

テレメトリーとは、システムが何をしてるかを示すデータと説明されており、トレース・メトリクス・ログの3つのシグナルから構築されているとのこと。それぞれだけでは足りないことがあるため、3つとも集まっていることに意味がありそう。

  • トレース : よく定義されたスキーマにしたがったログ文の集合
    • 単一のトレースは、分散システムを介した単一のトランザクション
    • メトリクスなどの他のシグナルにに変換できる
  • メトリクス : インフラやアプリケーションの一定期間に集計されたもの
    • (開発者)コード内で重要かつ、セマンティクス的に意味のあるイベントを定義、それらのイベントがどのようにメトリクスシグナルに変換されるかを指定できるようにすべき
    • (運用担当者)メトリクスの時間または属性を集約(または再集約)することでコスト・データ量、解像度を制御できるべき
    • 変換は測定値の本質的な意味を変えてはならない
  • ログ : タイムスタンプ付きのテキストレコード
    • レガシーコード、メインフレーム、その他の記録システムなど、その他トレースできないサービスからシグナルを取り出す
    • マネージドデータベースやロードバランサーなどのインフラストラクチャリソースをアプリケーションイベントと関連づける
    • cronジョブやその他の反復的でオンデマンドな作業など、ユーザーのリクエストと結びつかないシステムの動作を理解する
    • メトリクスやトレースなどの、他のシグナルに加工する

これらを収集することでシステムが何をしているかを追うことができるようになる。どれかだけではきっと足りないのだろう。それぞれを取得して結びつけることができるようにしておきたいと思ったので、取り入れてみたい。

本書ではOpenTelemetryのアーキテクチャについての説明がデモコードといっしょに紹介されており、自分で試してみることもできるようになっていて少しだけでも理解を深めることが出来た。
また、アプリケーション、ライブラリ、インフラへの取り込みについても章をたてて紹介されている。サービスで障害が起きたときに最近ログだけでの調査が難しくなってきているので、このあたりはちゃんと組み込みをしていきたい。

最後の章では組織における実践の方法が紹介されていた。OpenTelemetryはデータを収集するだけではなく、システムや組織プロセスを理解し改善する価値についての話があり興味深かった。オブサーバビリティの3つの軸が紹介されており、取り入れるときの軸についてのトレードオフが説明されていた。ただ、これらはどちらかを選んだら終わりではなく、時間の経過とともに変わっていくというのも納得感があった。

まとめ

  • 概念から仕様が説明されているのでわかりやすかった
  • オブザーバビリティを始めるための一歩として取り入れてみたい
  • きっとまた嵌まるだろうから何度も戻ってこよう