9.2 オブザーバビリティとテレメトリ

概要と動機

テレメトリとは、システムが自らの挙動について発するデータです。稼働中のソフトウェアから集められる、メトリクス、ログ、トレース、イベント。監視は、そのテレメトリから、すでに尋ねるべきと知っていた問いに答えます。ディスクは満杯か。エラー率は閾値を超えているか。サービスは稼働しているか。オブザーバビリティはより広いものです。新しいコードを出荷せずに、外側からシステムの内部状態について新しい問いを立てる能力で、予期しなかった挙動を理解できるようにします。システムが分散、マイクロサービス、イベント駆動アーキテクチャへと育つにつれ、最も痛手となる失敗は誰も予見しなかったものであり、オブザーバビリティがそれをデバッグできるようにします。監視は、何かがおかしいと教えてくれます。オブザーバビリティは、なぜかを見つける助けになります。

大きなチームにとって、この区別は決定的です。モノリスは、一台のマシンのログを読むことで理解できたかもしれません。現代のプラットフォームは、数百のサービス、多くのチーム、複数のリージョン、サードパーティの依存関係にまたがり、一つのユーザーのリクエストが数十のコンポーネントに触れうるものです。誰一人としてシステム全体を頭に保てません。共有された高品質のテレメトリは、あらゆるエンジニアが境界をまたいでリクエストを追い、サービスにわたって症状を突き合わせ、誰も完全には所有しないシステムについて推論できるようにする結合組織になります。それがなければ、インシデントは長引き、チーム間で非難が飛び交い、根本原因は隠れたままです。

企業と政府のシステムは、コンプライアンス、監査可能性、公的な説明責任で賭け金を引き上げます。規制当局は、誰がいつ何にアクセスしたかの証拠を求めるかもしれません。セキュリティチームは、侵入を検知するためにテレメトリを必要とします。市民向けのサービスは、公表されたパフォーマンスの約束を満たしていることを示さなければなりません。良いオブザーバビリティは、これらすべてに同時に仕えます。エンジニアリングの道具であり、セキュリティの統制であり、説明責任の仕組みでもある。オープンな計装に標準化することは、単一ベンダーの独自エージェントへのロックインを避け、システムが何十年も続き、調達サイクルを生き延びなければならないとき、これは非常に重要です。

関連項目: 9.1章(サイト信頼性エンジニアリングとSLO)、9.3章(インシデント管理)、3.3章(分散システム)。

主要原則

未知の問いのために計装する。 予測した失敗を超えて、新しい失敗を調査できるようにテレメトリを設計します。
三本柱、一つの物語。 メトリクス、ログ、トレースは補完的な見方で、サイロ化ではなく相関づけられたとき、その価値は倍増します。
すべてを構造化する。 一貫したフィールドを備えた、構造化され機械で解析可能なテレメトリは、人間にしか読めない自由文に勝ります。
共有の識別子で相関づける。 あらゆる所に伝播されたトレースIDとリクエストIDが、サービスをまたぐ単一の出来事をつなぎ合わせます。
原因ではなく症状でアラートする。 ユーザーから見える問題に人間を呼び出し、根本の原因はダッシュボードと調査に浮かび上がらせます。
すべてのページングは対処可能でなければならない。 人間の行動を要さないアラートは、信頼を侵食して疲労を起こす雑音です。
高いカーディナリティは機能である。 ユーザー、リクエスト、リージョン、バージョンで切り分ける能力が、本番でのデバッグを可能にします。
計装を自分で所有する。 オープンでベンダー中立のテレメトリに標準化し、データを制御してバックエンドを切り替えられるようにします。

推奨事項

三本柱とその先に築く

メトリクスは数値の時系列で、保存が安く、ダッシュボード、傾向、アラートの閾値に理想的です。ログは、イベントの離散的でタイムスタンプ付きの記録で、詳細が豊かで、フォレンジックな調査に不可欠です。トレースは、一つのリクエストがサービスを通って動くのを追い、分散した呼び出しグラフ全体のレイテンシと依存関係を示します。これらを超えて、イベント(デプロイのような意味のある状態変化)、プロファイル(コードがCPUとメモリをどこで使うか)、実際のクライアント体験のリアルユーザーモニタリングを検討します。単一の柱だけでは十分ではありません。目標は、調査の間にそれらの間を流れるように移ることです。

OpenTelemetryと構造化ログに標準化する

メトリクス、ログ、トレースを生成し収集するための、ベンダー中立の標準としてOpenTelemetryを採用します。それは計装を分析のバックエンドから切り離すので、数百のサービスを再計装せずにベンダーを変えられます。その性質は、長寿命の企業と政府のシステムに決定的です。ログを、タイムスタンプ、重大度、サービス、識別子の一貫したフィールド名を持つ構造化された記録(たとえばJSON)として出力します。エッジからすべての下流の呼び出しを通じて、トレースあるいは相関IDを伝播し、あらゆるログ行とメトリクスのエグザンプラに含めて、三本柱が自動的に連結するようにします。

対処可能性と低い雑音のためにアラートを設計する

アラートの哲学が、オンコールが持続可能かを決めます。主に、SLO(サービスレベル目標)のバーンレートとして表現された、ユーザーが感じる症状でアラートします。エラーバジェット(その目標からの許容される不足分)を、突破するほど速く燃やしているときに、早い検知と誤報のバランスをとるマルチウィンドウのバーンレートのアラートを使って、ページングします。ページングは、直ちに人間の行動を要する問題のために取っておき、それ以外はすべてチケットやダッシュボードに回します。行動を要さずに発火するアラートは、容赦なく刈り込んでください。アラート疲れは、本物のインシデントを見逃す主な原因であり、オンコールの燃え尽きの原因だからです。すべてのアラートは、ランブックにリンクすべきです。

ダッシュボードとSLO監視でヘルスをモデル化する

ダッシュボードは、持っているすべての指標の壁ではなく、明確なヘルスのモデルを軸に築きます。良い出発点の枠組みは、「四つのゴールデンシグナル」、レイテンシ、トラフィック、エラー、飽和です。SLOの状況と残りのエラーバジェットを一目で示すサービスレベルのダッシュボードと、システム全体とユーザーの旅のヘルスをモデル化する、より高い水準のダッシュボードを作ります。すべてを示すダッシュボードは何も伝えないので、意図して選り抜いてください。対応者がシグナルから文脈、行動へと素早く動けるよう、アラートとランブックの近くに置きます。

高いカーディナリティで本番でのデバッグを可能にする

最も難しい本番の問題は、狭い一部に当たります。一人の顧客、一つのリージョン、一つのAPIバージョン、一つのデバイスの種類。それらを調査するには、高カーディナリティのテレメトリが必要です。ユーザーIDやリクエストIDのように多くの異なる値を持つフィールドで、グループ化と絞り込みをする能力です。レコードごとに多くの次元を運ぶ、幅広く豊かに属性づけられたイベントは、後から任意の問いを立てられるようにします。外れ値を切り分けるのに十分なカーディナリティとサンプリングの忠実度を保ち、メトリクスの急上昇が代表的な遅いリクエストへ直接導くよう、エグザンプラにリンクされたトレースを好みます。

コスト、保持、サンプリングを管理する

テレメトリの量はシステムとともに育ち、大きな出費になりえます。データの種別ごとに保持の方針を設定します。高解像度のデータは短く、集計は長く保ちます。トレースには、エラーと遅いリクエストを保つ方向に偏った、賢いサンプリングを適用し、日常の成功のすべてに払わずに、興味深い裾を保持します。管理されないオブザーバビリティのコストは、観察するインフラストラクチャに匹敵しうるので、テレメトリの支出を定期的にレビューします。

トレードオフ: 長所と短所

決定	長所	短所
高カーディナリティのイベント	強力なデバッグ、何でも尋ねられる	高いストレージとクエリのコスト
積極的なサンプリング	低いコスト、少ない雑音	まれな出来事を見逃しうる
症状ベースのアラート	より少なく対処可能なページング	うまく機能するには良いSLOが必要
OpenTelemetryの標準	ベンダー中立、可搬	移行の労力、成熟途上のツール
長いログの保持	より良いフォレンジックと監査	ストレージコスト、プライバシーの露出

オブザーバビリティの決定は、忠実度とコストの緊張に帰着します。すべてを完全な解像度で捉えることは、完璧な後知恵を与えますが、規模では法外に高価です。積極的に削れば、お金は節約できますが、停止を説明したはずの唯一の記録を捨てるかもしれません。サンプリングと保持の層は、成熟したチームがこの線を歩く方法で、日常のデータを間引きながらエラーと外れ値を保ちます。アラートのトレードオフは、感度と雑音の間にあります。多すぎるアラートは疲労と見逃されたインシデントを引き起こし、少なすぎると問題が膿みます。症状ベースでSLO駆動のアラートはこの多くを解決しますが、意味のあるSLOがある場合に限ります。

チームで議論すべき問い

レガシーのサービスをOpenTelemetryに移す計画は何で、移行の間に二つの計装スタックに払うのをどう避けますか。 ベンダー中立の計装は、数百のサービスを再計装せずにバックエンドを切り替えられるようにする性質で、単一のベンダー契約より長生きする、長寿命の企業と政府のシステムにとって最も重要です。移行は、良い意図が停滞する所です。半分しか計装されていない資産群は、リクエストが新しいサービスから古いものに渡るまさにその所に隙間を残し、エンド・ツー・エンドのトレースを壊します。議論に目録を持ち込んでください。どのサービスが独自エージェントのデータを出し、どれがOpenTelemetryを出し、どこで境界でトレースの文脈が落ちるか。組織図ではなく本物のリクエストの経路に従った順序を決め、二つのコレクターを動かす期間に予算を付けてください。答えが、本当にテレメトリを所有するのか、一つのベンダーのエージェントに縛られたままかを決めます。
最後にすべてのアラートの対処可能性を監査したのはいつで、先月のページングのうち人間の行動を要さなかったものはいくつありましたか。 アラート疲れは、本物のインシデントを見逃す主な原因とオンコールの燃え尽きなので、行動を要さないページングは無害な雑音ではなく、頼りにする対応を積極的に侵食します。証拠を持ち込んでください。先月のページングを取り出し、それぞれを対処済みか無視かに印を付け、いくつがランブックに対応したかを数える。多くのサービスにまたがる大きなチームでは、あるチームのうるさいアラートが、全員の共有のオンコールを鈍感にします。すべてのページングがランブックにリンクされ、SLOのバーンレートに結びつくという標準を設定し、残りは容赦なく削除してください。この監査の結果は、ページングの量を直接削り、どのサービスが、アラートの背後に意味のあるSLOを持たないかを教えてくれるはずです。
トレースのサンプリング戦略は何で、それがエラーと遅い裾を保つと、どれだけ確信していますか。 テレメトリの量はシステムとともに育ち、管理されないオブザーバビリティのコストは観察するインフラストラクチャに匹敵しうるので、サンプリングはするでしょうが、問いは賢くサンプリングするかどうかです。カーディナリティを削ったり盲目的にサンプリングしたりすることは、一人の顧客、一つのリージョン、一つのAPIバージョンに当たる狭い問題をデバッグするのに必要なまさにその記録を取り除きます。現在の保持の層とサンプリングのルールを持ち込んでください。エラーと遅いリクエストを保つ方向に偏らせているか、メトリクスの急上昇が代表的な遅いリクエストにつながるよう、エグザンプラにリンクされたトレースを使っているか。監査されプライバシーに縛られるシステムでは、デバッグのために個人データを溜め込まないよう、保持をデータ最小化のルールと突き合わせてください。答えが、テレメトリの予算をどこに使うか、次の難しい停止が説明可能か謎かを決めます。
SLOのうち、本物のユーザーの旅へのコミットメントはどれで、所有するチームの外では誰も信じない代理の指標はどれですか。 症状ベースのアラートは、症状がユーザーが実際に感じることに対応する場合にだけ機能するので、CPUの閾値や作り上げた可用性の目標に配線されたアラートは、重要でないかもしれない問題で人を呼び出し、重要な問題には沈黙したままです。大きな組織では、SLOは、独立したチームが、すべてのインシデントの間に深刻度を蒸し返さずにオンコールのローテーションを共有できるようにする契約でもあります。現在のSLOカタログ、各目標が守るべきユーザーの旅、先四半期の違反と、顧客が実際に苦情を言ったかを持ち込んでください。企業と政府の設定では、最も目に見えるSLOを、サービスが課される公表されたパフォーマンスの約束に結びつけてください。エンジニアを呼び出す同じバーンレートのシグナルが、規制当局や監督機関に示す証拠にもなります。議論は代理の指標を退役させ、非エンジニアがユーザーへの約束と認める、短い目標の一覧を残すべきです。
テレメトリのデータガバナンスを誰が所有し、個人データがオブザーバビリティのバックエンドに着く前に編集されていると証明できますか。 高カーディナリティのイベントと長いログの保持は、まさにデバッグを可能にする機能であり、まさにオブザーバビリティのストアを、ユーザーの個人データの管理されないコピーに変える機能でもあります。相反する引力は本物です。エンジニアはより豊かな属性とより長い保持を望み、プライバシーと法務はデータ最小化と短い寿命を望みます。どのフィールドが個人あるいは機微なデータを運ぶか、パイプラインのどこで編集あるいはトークン化が起こるか、データの種別ごとの保持の層を示す、データフローの地図を持ち込んでください。規制対象と公共のシステムでは、説明責任のある所有者を名指しし、保持を、運用する適法な根拠とデータ最小化のルールに対応づけ、テレメトリ自体へのアクセスが記録され制御されていることを監査人に示せるよう備えてください。答えが、オブザーバビリティのプラットフォームが資産か、発見されるのを待つ常設の侵害かを決めます。
インシデントが複数のチームのサービスにまたがるとき、テレメトリは一人の対応者がリクエストを端から端まで追えるようにしますか。それとも、あらゆる所有の境界で足跡が途切れますか。相関づけられ、IDが伝播されたテレメトリの約束のすべては、一人のエンジニアが、誰も完全には所有しないシステムについて推論できることで、その約束は、トレースの文脈が落ちる、あるいは二つのチームが互換性のない識別子とツールを使う、まさにその境界で崩れます。オブザーバビリティのツールを選ぶ際のチームごとの自律への引力を、停止の間、あらゆる引き継ぎが行き止まりになる断片化した資産群の共有のコストと量ってください。最近のチームをまたぐインシデントのタイムラインを持ち込み、対応者が糸を失った所に印を付け、どのサービスが共通の相関IDを伝播し、どれがしないかの目録を加えてください。多くのベンダーと長寿命のシステムから組み立てられた大きな企業あるいは政府のプラットフォームでは、数十年にわたって再調達するコンポーネントも、同じリクエストで相互運用しなければならないので、何を中央で義務づけるか、共有のトレース文脈の標準と共通のID体系と、何をチームに任せるかを決めてください。答えが、次の複数チームのインシデントが、調整された調査か、責任の押し付け合いかを教えてくれます。

セクター別の視点

スタートアップ。 少数のサービスと余った手がないなら、初日からOpenTelemetryで計装し、一つのリクエストIDを端から端まで運ぶ構造化JSONログを出荷してください。その小さな投資が、「アプリが遅い」を読めるトレースに変え、後で再計装せずに無料枠から有料のバックエンドへ移る自由を保ちます。測定できる体験を持つユーザーができるまで、手の込んだダッシュボードとSLOの仕組みは飛ばします。

小規模事業者。 オブザーバビリティの専門家はおらず予算も厳しいので、自前のスタックを組み立てるのではなく、計装、ストレージ、ダッシュボードが束ねられたマネージドなバックエンドに頼ってください。ここでは築くか買うかの判断が、ほぼ常に買うに傾きます。乏しい注意は、テレメトリのパイプラインを動かすより、サービスが落ちたと教える二つか三つのゴールデンシグナルのアラートに使うほうがよいのです。テレメトリのコストが、観察するインフラストラクチャを静かに追い越せないよう、保持の厳しい上限を設定します。

大企業。 仕事は、多くのチームにわたるガバナンスです。共有のOpenTelemetryの標準、共通の相関IDの体系、選り抜かれたSLOのダッシュボードにより、一人の対応者が数十のサービスをまたいでリクエストを追えます。テレメトリを、保持の層とサンプリングの方針を伴うコストセンターとして管理し、共有のオンコールを持続可能に保つためアラートをSLOのバーンレートに標準化し、あるチームの疲労が全員を鈍感にしないよう、うるさいアラートを中央で刈り込みます。計装の層を、単一のバックエンド契約より長生きする、ベンダー中立のインフラストラクチャとして扱います。

政府。 調達規則、透明性、公的な説明責任が設計を形づくります。数十年動くことを期待されるシステムが、独自エージェントに人質にされることなく、異なるベンダーによる再調達を生き延びられるよう、オープンな計装に標準化し、その可搬性を契約で要求します。構造化された監査ログを使って、誰がどの記録にいつアクセスしたかを示し、個人データはテレメトリのストアに届く前に編集あるいはトークン化し、保持をデータ最小化の法と突き合わせます。市民向けサービスのSLOダッシュボードを公開し、エンジニアが見る同じシグナルが、あなたが課されるコミットメントの可視の証拠になるようにします。

事例

スタートアップ。 4人のスタートアップは、モバイルのバックエンドを出荷し、再現できない漠然とした「アプリが遅い」という苦情を受け続けます。チームは少数のサービスにOpenTelemetryを加え、アプリからすべてのホップを通じて運ばれるリクエストIDを伴う構造化JSONログに切り替えます。次の遅いという報告は数分で解決します。一つのトレースが、特定のクエリのもとで、ordersテーブルにデータベースのインデックスが欠けていることを示したのです。早くからオープンな計装を選んだので、後に何も再計装せずに、無料枠から有料のバックエンドへ移ります。

大企業。 大きなeコマースのプラットフォームは、すべてのサービスをOpenTelemetryで計装し、顧客のブラウザから、チェックアウト、決済、在庫、配送を通じてトレースIDを伝播します。コンバージョンが落ちると、オンコールのエンジニアはSLOのバーンレートのアラートから始め、チェックアウトのダッシュボードのゴールデンシグナルを開き、一つのリージョンでの高いレイテンシを見つけ、エグザンプラのトレースを追って、単一のサービスの遅いデータベース呼び出しに至ります。高カーディナリティの属性が、問題が一つの商品カテゴリに限られることを示し、数時間ではなく数分で的を絞った修正に導きます。

政府。 国の医療サービスは、厳格な監査とプライバシーの規則のもとで、患者記録のプラットフォームを動かします。構造化ログは、誰がどの記録にいつアクセスしたかを捉え、セキュリティ監視とコンプライアンス報告の両方に供給し、個人を特定できるフィールドはテレメトリで編集あるいはトークン化されます。公開のSLOダッシュボードは、市民向けの予約システムの可用性とレイテンシを示します。オープンな計装に標準化することで、機関は、数十年動き、その生涯の間に異なるベンダーによって再調達されることを期待されるシステムで、独自のロックインを避けます。

ビジネスケース: 動機、ROI、TCO

オブザーバビリティの主な見返りは、インシデントを検知して解決するのにかかる時間の劇的な低下です。停止が高くつくサービスでは、平均解決時間を数時間から数分に削ることは、一度の大きなインシデントでツールのコストを何倍も取り戻します。オブザーバビリティはまた、推測し、バグを再現し、どのチームが悪いかを議論するのに費やしたはずのエンジニアリングの時間を節約し、チームが自信をもって出荷できるフィードバックのループを短くします。セキュリティとコンプライアンスの価値も本物です。同じテレメトリが、侵入検知と監査の証拠を支えます。

総所有コストには、計装の労力、テレメトリのストレージとクエリのコスト、雑音から信号を選り抜く規律が含まれます。これらのコストは目に見えて繰り返されるので、リーダーシップは投資不足に誘惑されます。採用しないコストはより大きいが見えにくい。長引く停止、診断されないパフォーマンスの問題、遅れて、あるいは決して見つからないセキュリティインシデント、何もできないアラートで燃え尽きるエンジニア。具体的なインシデントのデータで論拠を示してください。最近の停止の解決時間と事業への影響を示し、より良いテレメトリが届ける削減を予測します。オブザーバビリティを、純粋なコストセンターではなく、デリバリーも速める保険として枠づけることが、議論に勝ちます。

アンチパターンと落とし穴

すべてにアラートする。 あらゆる異常にページングすることは、対応者にアラートを無視するよう訓練し、本物のインシデントがすり抜けること。
原因ベースのページング。 ユーザーの症状ではなく内部の原因でアラートすることは、オンコールを雑音で溢れさせ、新しい失敗を見逃すこと。
構造化されていないログ。 クエリも相関づけもできない自由文のログは、インシデントの間に遅い手作業のgrepを強いること。
サイロ化した三本柱。 共有のIDがなく、切り離されたツールにあるメトリクス、ログ、トレースは、出来事を端から端まで追うのを妨げること。
ダッシュボードの乱立。 選り抜かれていない数百のダッシュボードは、システムが健全かをどれが示すのか、誰も知らないことを意味すること。
カーディナリティの崩壊。 コストを節約するために高カーディナリティのフィールドを取り除くと、狭い問題をデバッグするのに必要なまさにそのデータを取り除くこと。
ベンダーロックイン。 あらゆる所の独自エージェントは、バックエンドの切り替えを法外に高価にし、データを人質に取ること。

成熟度モデル

レベル1: 開始。 オブザーバビリティはその場しのぎで反応的です。基本的な稼働チェックと構造化されていないログが個々のマシンにあり、デバッグはサーバーにログインしてgrepすることを意味し、共有のテレメトリはありません。アラートはうるさく、原因ベースで、しばしば無視されるので、本物のインシデントはシグナルではなくユーザーの苦情を通じて表面化します。

レベル2: 発展。 基本的な実践が現れますが、チームごとに異なります。一部のサービスはメトリクスとログを中央の場所に送り、少数のダッシュボードと閾値のアラートがありますが、ログは半構造化にすぎず、トレースは欠けているか部分的です。サービスにわたる相関は手作業で、エンジニアがリクエストを端から端まで追えるかは、たまたまどのチームが関わるかに依存します。

レベル3: 標準化。 計装は文書化され、組織全体で徹底されます。伝播されるトレースあるいは相関IDを伴うサービス全体のOpenTelemetry、一貫したフィールド名の構造化ログ、分散トレーシング、選り抜かれたゴールデンシグナルのダッシュボード、SLOベースの症状アラートが、すべてのチームが従う標準です。すべてのページングがランブックにリンクされSLOに結びつき、オンコールは燃え尽きの源ではなく持続可能です。

レベル4: 管理。 オブザーバビリティの資産群自体が、ベースラインに対して測定され制御されます。サービスにわたる計装のカバレッジとトレース文脈の伝播率、対処されたページングと無視されたページングの割合、平均検知時間と解決時間、SLOの達成とエラーバジェットのバーン、予算に対するサービスごとのテレメトリのコストを追跡します。隙間とアラートの雑音は、明示的な目標に向けてデータで押し下げられ、エラーと遅い裾の記録が生き残るようサンプリングの忠実度が検証され、カバレッジと保持についての実行か中止かの決定は、意見ではなく証拠に基づきます。

レベル5: オーケストレーション。 オブザーバビリティは、継続的に改善され、組織全体に統合されています。高カーディナリティでイベントの豊かなテレメトリが、どんな切り口の臨機応変な調査も可能にし、アラートは最小限の雑音でSLOのバーンレートに駆動され、サンプリングと保持はコストとリスクの変化に適応します。テレメトリは、容量計画、セキュリティ検知、プロダクトの決定に日常的に供給され、プラットフォームは、システム、脅威の状況、規制の義務が移るにつれて、自らのシグナル、予算、カバレッジを再調整します。

議論のためのアイデア

最も重要なサービスで、テレメトリの忠実度とコストの正しいバランスはどこにありますか。
何がページング、チケット、ダッシュボードの項目だけに値するかを、どう決めますか。
コードベースもリリースサイクルも共有しないチームにわたって、相関IDを伝播する戦略は何ですか。
プライバシーとデータ最小化の要件を満たしながら、高カーディナリティのデバッグ力をどう保ちますか。
オブザーバビリティのツールは中央で義務づけるべきですか。それともチームごとに選ぶべきですか。そしてどちらの場合も結果は何ですか。
テレメトリが完全で改ざんが明らかだと、監査人にどう示しますか。

要点

監視は既知の問題を検知し、オブザーバビリティは新しいコードを出荷せずに未知の問題を調査できるようにします。
メトリクス、ログ、トレースは、サイロ化ではなく、共有の識別子を通じて相関づけられたとき最も価値があります。
長いシステムの寿命にわたってベンダー中立で可搬であるために、OpenTelemetryと構造化ログに標準化します。
SLOのバーンレートを通じてユーザーに見える症状でアラートし、すべてのページングを対処可能にし、雑音を容赦なく刈り込みます。
すべての指標を示すのではなく、ゴールデンシグナルのような明確なヘルスのモデルを軸にダッシュボードを選り抜きます。
高カーディナリティでイベントの豊かなテレメトリが、狭い本番の問題のデバッグを可能にします。

参考文献とさらなる読み物

Charity Majors, Liz Fong-Jones, George Miranda, Observability Engineering: Achieving Production Excellence
Cindy Sridharan, Distributed Systems Observability
Betsy Beyer et al., Site Reliability Engineering (chapters on monitoring and alerting)
Brendan Gregg, Systems Performance: Enterprise and the Cloud
OpenTelemetry project, specification and documentation (Cloud Native Computing Foundation)
Google, The Four Golden Signals (Site Reliability Engineering, monitoring chapter)