[Observability Engineering [Book]](https://www.oreilly.com/library/view/observability-engineering/9781492076438/) ```cardlink url: https://www.oreilly.com/library/view/observability-engineering/9781492076438/ title: "Observability Engineering" description: "Observability is critical for building, changing, and understanding the software that powers complex modern systems. Teams that adopt observability are much better equipped to ship code swiftly and confidently, identify … - Selection from Observability Engineering [Book]" host: www.oreilly.com image: https://www.oreilly.com/library/cover/9781492076438/ ``` [O’Reilly Observability Engineering - Honeycomb](https://www.honeycomb.io/oreilly-observability-engineering/) ## メモ 従来のモニタリングは、事前に集計されたダッシュボードを用意する、かつ、事前に決めたしきい値に従いアラートするような、リアクティブな形態をとる。 つまり、カーディナリティ・ディメンションが低く、探索可能性が低い。 そこで、探索可能性を向上させるため、テレメトリーデータから高カーディナリティ、高ディメンションのコ ンテキストを一箇所に集め、調査者が簡単に切り刻んで拡大、縮小し、パンくずをたどって決定的な 答えを見つけられるようにする 用語定義が後方参照になっていることが多くて読みにくいけど、基本的に、従来のモニタリングが集計後のデータをみるので、問題を深く調べるためには集計前のデータに分解する必要があるよという話をずっとしていることがわかってきた。 後者の状態へ移行することをObservabilityを高めることだとみなすシンプルな考え方を提示しているのは興味深い イベントを基礎単位として整理されている。トレースはイベントをつなぐもの。メトリクスはイベントなりトレースを集計したもの、 従来のモニタリングが集計後のデータをみるので探索可能な範囲がせまいので、問題をより深く調べるには集計前のデータに分解して探索できるようにする必要があることを主張していると理解した。 ![[Monitoring VS Observability]] [Tweet / Twitter](https://twitter.com/yuuk1t/status/1627990705871396864) ## Authors Charity Majors is the cofounder and CTO at Honeycomb, and the coauthor of Database Reliability Engineering. Before that, she worked as a systems engineer and engineering manager for companies like Parse, Facebook, and Linden Lab. Liz Fong-Jones is a developer advocate and site reliability engineer (SRE) with more than 17 years of experience. She is an advocate at Honeycomb for the SRE and observability communities. George Miranda is a former systems engineer turned product marketer and GTM leader at Honeycomb. Previously, he spent more than 15 years building large-scale distributed systems in the finance and video game industries. ## Description [[Observability]]は、複雑な現代のシステムを強化するソフトウェアを構築、変更、理解するために不可欠です。観測可能性を採用したチームは、迅速かつ自信を持ってコードを出荷し、異常値や異常な動作を特定し、各ユーザーの経験を理解するための能力をはるかに向上させます。本書は、観測可能なシステムの価値を説明し、観測可能性駆動型開発を実践する方法を紹介する実用書です。 著者のCharity Majors、Liz Fong-Jones、HoneycombのGeorge Mirandaは、何が優れた観測性を構成するか説明し、現在行っていることを改善する方法を示し、メトリクス、モニタリング、ログ管理などのレガシーツールから移行するための実用上の注意事項を提供します。また、観測可能性が組織文化に与える影響（およびその逆）についても学びます。 ## Table of contents ### Foreword - To the contrary, observability is more a sociotechnical concept. ### Preface • What observability means in the context of software delivery and operations • How to build the fundamental components that help you achieve observability • The impact observability has on team dynamics • Considerations for observability at scale • Practical ways to build a culture of observability in your organization Who This Book Is For Why We Wrote This Book What You Will Learn 第Ⅰ部　オブザーバビリティへの道 1章　オブザーバビリティとは？ 1.1　オブザーバビリティの数学的定義 > 制御理論†2 では、オブザーバビリティとは、外部出力の知識からシステム†3 の内部状態をどれだけうまく推測できるかの尺度として定義されています。 1.2　オブザーバビリティのソフトウェアシステムへの適用 > 簡単に言うと、私たちが考えるソフトウェアシステムの「オブザーバビリティ」とは、システムがど のような状態になったとしても、それがどんなに斬新で奇妙なものであっても、どれだけ理解し説明で きるかを示す尺度です。 1.3　ソフトウェアにおけるオブザーバビリティについての誤解 1.4　なぜ今オブザーバビリティが重要なのか？ 1.4.1　これは本当にベストな方法なのでしょうか？ 1.4.2　なぜメトリクスとモニタリングでは不十分なのか？ > オブザーバビリティにおいて、高ディメンションかつ高カーディナリティのデータを比較することが、 複雑なシステムアーキテクチャに埋もれ、隠れた問題を発見するための重要な要素となります。 1.5　メトリクスを用いたデバッグとオブザーバビリティの比較 > コードがどのように実行されているかを理解することではなく、問題のあるコードがシステム内のどこに存在するかを見 つけることです。 1.5.1　カーディナリティの役割 1.5.2　ディメンションの役割 > カーディナリティがデータ内の値のユニークさを意味するのに対し、ディメンションはデータ内の キーの数を意味します。 > ユーザー、コード、システムの相互作用で発生するすべての事柄について、非常に詳細な情報を収 集する必要があります。高いディメンションを持つデータは、これらの交点がどのように展開されるか について、より豊かなコンテキストを提供します。 > 探索可能性とは、システムが陥った任意の状態に対しても、たとえそれが今 まで見たことがない状態だとしても、事前にそのような状態になることを予測することなく、繰り返し 調査して最終的に理解できるということを意味します。 1.7　オブザーバビリティは現代のシステムのためにある 1.8　まとめ 2章　オブザーバビリティとモニタリングにおけるデバッグ方法の違い 2.1　モニタリングデータのデバッグへの活用方法 2.1.1　ダッシュボードを使用する際のトラブルシューティング方法 2.1.2　直感によるトラブルシューティングの限界 2.1.3　従来のモニタリングは基本的にリアクティブである 2.2　オブザーバビリティがより良いデバッグを可能にする理由 2.3　まとめ 3章　オブザーバビリティを用いないスケーリングからの教訓 3.1　Parseの紹介 3.2　Parseでのスケーリング 3.3　現代のシステムへの進化 3.4　現代的な実践に向けた進化 3.5　Parseにおけるプラクティスの変革 3.6　まとめ 4章　オブザーバビリティとDevOps、SRE、クラウドネイティブとの関連性 4.1　クラウドネイティブ、DevOps、SREクイックリファレンス 4.2　オブザーバビリティ：デバッグの昔と今 4.3　オブザーバビリティがDevOpsとSREのプラクティスを強化する 4.4　まとめ 第Ⅱ部　オブザーバビリティの基礎 5章　構造化イベントはオブザーバビリティの構成要素である > イベントとは、本番環境のサービスへの影響を理解するために、ある特定のリクエストがそのサービスとやりとりしている間に発生したすべての記録です。 5.1　構造化イベントを使ってデバッグする 5.2　構成要素としてのメトリクスの限界 5.3　構成要素としての従来のログの限界 5.3.1　非構造化ログ 5.3.2　構造化ログ 5.4　デバッグに役立つイベントのプロパティ 5.5　まとめ 6章　イベントをトレースにつなぐ 6.1　分散トレースとその重要性 6.2　トレースの構成要素 6.3　トレースを地道に計装する 6.4　トレーススパンへのカスタムフィールドの追加 6.5　イベントをトレースにつなぐ 6.6　まとめ 7章　OpenTelemetryを使った計装 7.1　入門計装 7.2　オープンな計装標準 7.3　コードベースの例を用いた計装 7.3.1　自動計装から始める 7.3.2　カスタム計装を追加する 7.3.3　計装データをバックエンドシステムに送信する 7.4　まとめ 8章　オブザーバビリティを実現するためのイベント解析 8.1　既知の状態からのデバッグ 8.2　第一原理からのデバッグ 8.2.1　[[コア分析ループ]]の使用 8.2.2　コア分析ループの総当り部分の自動化 8.3　AIOpsの誤解を招く約束 8.4　まとめ 9章　オブザーバビリティとモニタリングの関係 9.1　モニタリングが適した場所 9.2　オブザーバビリティが適した場所 9.3　考察: システム vsソフトウェア 9.4　組織的なニーズを把握する 9.4.1　例外: 無視できないインフラストラクチャのモニタリング 9.4.2　実際の例 9.5　まとめ 第Ⅲ部　チームのためのオブザーバビリティ 10章　オブザーバビリティへの取り組みをチームへ適用する 10.1　コミュニティグループに参加する 10.2　最大の問題点から始める 10.3　作るより買う 10.4　計装を繰り返し完成させる 10.5　既存の努力を活用する機会を探す 10.6　最後のひと押しに備える 10.7　まとめ 11章　オブザーバビリティ駆動開発 11.1　テスト駆動開発 11.2　開発サイクルにおけるオブザーバビリティ 11.3　デバッグする場所を決定する 11.4　マイクロサービス時代のデバッグ 11.5　計装でオブザーバビリティを駆動する 11.6　オブザーバビリティをシフトレフトする 11.7　オブザーバビリティを活用してソフトウェアデリバリーを高速化する 11.8　まとめ 12章　サービスレベル目標の信頼性向上への活用 12.1　従来のモニタリング手法では危険なアラート疲れが発生する 12.2　しきい値アラートは既知の未知のみに対応している 12.3　ユーザー体験が道しるべ 12.4　サービスレベル目標とはなにか？ 12.4.1　SLOによる信頼性の高いアラート 12.4.2　SLOベースアラートに向けた文化の変化:ケーススタディ 12.5　まとめ 13章　SLOベースのアラートへの対応とデバッグ 13.1　エラーバジェットが枯渇するまえにアラートを出す 13.2　時間をスライディングウィンドウとして捉える 13.3　バーン予想アラート作成のための予測 13.3.1　エラーバジェットを使い果たすとどうなるか 13.4　オブザーバビリティデータ vs時系列データ: どちらをSLOに使用するか 13.5　まとめ 14章　オブザーバビリティとソフトウェアサプライチェーン 14.1　なぜSlackにはオブザーバビリティが必要なのか 14.2　計装：共有クライアントライブラリとディメンション 14.3　ケーススタディ：サプライチェーンの運用 14.3.1　ツールによるコンテキストの理解 14.3.2　アクション可能なアラートの組み込み 14.3.3　何が変わったのかを理解する 14.4　まとめ 第Ⅳ部　大規模なオブザーバビリティ 15章　投資収益性: 作るか、それとも買うか 15.1　オブザーバビリティのROIをどう分析するか 15.2　独自構築にかかる本当のコスト 15.2.1　「フリー」ソフトウェアの隠れたコスト 15.2.2　独自構築の利点 15.2.3　独自構築のリスク 15.3　ソフトウェアを買うときの本当のコスト 15.3.1　商用ソフトウェアの隠れた財務的コスト 15.3.2　商用ソフトウェアの隠れた非金銭的コスト 15.3.3　商用ソフトウェアを購入するメリット 15.3.4　商用ソフトウェアを購入するリスク 15.4　買うか作るかは二者択一ではない 15.5　まとめ 16章　効率的なデータストア 16.1　オブザーバビリティの機能要件 16.1.1　[[Time Series DataBase|時系列データベース]]はオブザーバビリティに欠ける [[TSDBのカーディナリティ爆発]] 16.1.2　その他のデータストアの可能性 16.1.3　データストレージ戦略 16.2　事例: HoneycombのRetrieverの導入事例 16.2.1　時間によるデータの分割 16.2.2　セグメント内の列ごとのデータ格納 16.2.3　クエリーのワークロードを実行する 16.2.4　トレースのクエリー 16.2.5　リアルタイムでデータをクエリーする 16.2.6　階層化でリーズナブルに 16.2.7　並列処理で高速化 16.2.8　高カーディナリティへの対応 16.2.9　スケーリング戦略と耐久性戦略 16.2.10　効率的なデータストアを自前で構築する際の注意点 16.3　まとめ 17章　安価で十分な精度にするためのサンプリング戦略 17.1　データ収集の精度を上げるためのサンプリング 17.2　サンプリング手法の使い分け 17.2.1　一定確率サンプリング 17.2.2　直近のリクエスト量に応じたサンプリング 17.2.3　イベントの内容（キー）に基づくサンプリング 17.2.4　過去データの手法とキーの手法を組み合わせる 17.2.5　動的サンプリングでのオプションの選択 17.2.6　いつトレースのサンプリングを判定するか 17.3　サンプリング戦略をコードに置き換える 17.3.1　ベースとなる例 17.3.2　固定割合サンプリング 17.3.3　サンプル割合を記録する 17.3.4　一貫したサンプリング 17.3.5　目標割合サンプリング 17.3.6　複数の静的サンプリング割合を持つ 17.3.7　キーと目標割合を組み合わせたサンプリング 17.3.8　任意数のキーに対応する動的サンプリング割合について 17.3.9　すべてをまとめる:キー、目標割合、ヘッドとテイルを全部つかってサンプリングする 17.4　まとめ 18章　パイプラインによるテレメトリー管理 18.1　テレメトリーパイプラインの属性 18.1.1　ルーティング 18.1.2　セキュリティとコンプライアンス 18.1.3　ワークロードの分離 18.1.4　データバッファリング 18.1.5　キャパシティ管理 18.1.6　データのフィルタリングと補強 18.1.7　データ変換 18.1.8　データの品質と一貫性を確保する 18.2　テレメトリーパイプラインの管理：解剖学 18.3　テレメトリーパイプラインの管理における課題 18.3.1　性能 18.3.2　正確性 18.3.3　可用性 18.3.4　信頼性 18.3.5　分離 18.3.6　データ鮮度 18.4　事例: Slackでのテレメトリー管理 18.4.1　メトリクスの集計 18.4.2　ログおよびトレースイベント 18.5　オープンソースの代替 18.6　テレメトリーパイプラインの管理：構築と購入の比較 18.7　まとめ 第Ⅴ部　オブザーバビリティの文化を拡大する 19章　オブザーバビリティのビジネス事例 19.1　変革をもたらすためのリアクティブなアプローチ 19.2　オブザーバビリティの投資対効果 19.3　変化を導入するためのプロアクティブなアプローチ 19.4　オブザーバビリティをプラクティスとして導入する 19.5　適切なツールを使う 19.5.1　計装 19.5.2　データの保持と分析 19.5.3　チームでツールを使い始める 19.6　オブザーバビリティが十分であることを確認する 19.7　まとめ 20章　オブザーバビリティの利害関係者と協力者 20.1　非エンジニアリング的なオブザーバビリティの必要性の認識 20.2　オブザーバビリティの協力者を作る実践 20.2.1　カスタマーサポートチーム 20.2.2　カスタマーサクセスチームと製品チーム 20.2.3　営業チームと役員 20.3　オブザーバビリティツールとビジネスインテリジェンスツールの使い分け 20.3.1　クエリー実行時間 20.3.2　精度 20.3.3　最新性 20.3.4　構造 20.3.5　時間枠 20.3.6　エフェメラリティ 20.4　オブザーバビリティとBIツールの併用による実践的な使い方 20.5　まとめ 21章　オブザーバビリティ成熟度モデル 21.1　成熟度モデルについてのノート 21.2　オブザーバビリティに成熟度モデルが必要な理由 21.3　オブザーバビリティ成熟度モデルについて 21.4　OMMで参照されるケイパビリティ 21.4.1　システム障害にレジリエンスで対応する 21.4.2　高品質なコードをデリバリーする 21.4.3　複雑さと技術的負債に立ち向かう 21.4.4　予測可能なケイデンスでリリースする 21.4.5　ユーザーのふるまいを理解する 21.5　あなたの組織でオブザーバビリティ成熟度モデルを使う 21.6　まとめ 22章　ここからどこへ 22.1　オブザーバビリティ、当時と今 22.2　追加の資料 22.3　オブザーバビリティの行方についての予測 訳者あとがき 索引