ダッシュボードは緑なのに、利用者からは「重い」と言われています。
運用の場でいちばん困るのが、この見えているのに分からないという状態でしょう。
グラフを足しても解決しないのは、足りないのが枚数ではなく問いの立て方だからです。
ここを整理する言葉が、監視を指すモニタリングと、可観測性と訳されるオブザーバビリティの二つになります。
監視は「決めたものを見る」仕組み
Google の SRE 本の Monitoring Distributed Systems の章は、監視を「システムに関するリアルタイムの定量データを集め、処理し、集約し、表示すること」と定義していました。
大事なのは、何を集めるかを先に決めているという前提のほうです。
同章は見方を二つに分けていました。
内部の指標やログを覗くホワイトボックスと、利用者から見える振る舞いだけを外から叩くブラックボックスです。
前者は「これから起きそうな障害」や、リトライで隠れている失敗を拾えます。
後者は「いま実際に起きている問題」を、利用者と同じ角度から捉えられます。
もう一つ、章の中で繰り返されているのが症状と原因の区別でした。
HTTP 500 を返しているのは症状で、データベースが接続を拒んでいるのが原因です。
多層のシステムでは「ある人の症状が、別の人にとっての原因」になるため、両方を並べて持つ必要がある、と整理されています。
オブザーバビリティは「後から問い直せる」性質
一方のオブザーバビリティは、道具の名前ではなく性質を指す言葉です。
OpenTelemetry の入門ドキュメントは「内部の作りを知らなくても、システムに問いを投げられることで、外側からシステムを理解できるようにするもの」と説明しています。
Observability Primer（OpenTelemetry）
同ドキュメントが強調しているのが unknown unknowns、つまり想定していなかった問題への対処です。
監視は「落ちたら知りたい項目」を事前に列挙しておく作業なので、列挙から漏れた事象には気づけません。
対してオブザーバビリティが十分なシステムでは、コードを足さずにあとから角度を変えて問い直せる状態が保たれています。
言い換えると、監視は答えを先に用意しておく設計で、オブザーバビリティは質問を後から作れる設計です。
三つの信号をどう使い分けるか
その「問い直せる状態」を支える材料が、テレメトリと呼ばれる信号です。
OpenTelemetry は主要な信号を次のように定義していました。
- メトリクス … 実行時に取得した測定値。件数や使用率のように、時間で集約される数値
- ログ … 出来事の記録。1件ごとの文脈を文字で残す
- トレース … リクエストがアプリの中をどう通ったかの経路
Signals（OpenTelemetry）
使い分けの順番は、だいたいメトリクスで気づき、トレースで場所を絞り、ログで中身を読むという流れに落ち着きます。
メトリクスは安く広く持てますが、1件の事情は分かりません。
ログは事情を残せる代わりに、量が増えると費用と検索性がつらくなります。
トレースはその中間で、どのサービスのどの区間で時間を食ったかを示してくれます。
なお同ドキュメントには、信号をまたいで文脈を運ぶ Baggage や、開発中の Profiles も並んでいました。
増やす前に決めること
信号を増やすほど分かる、とはならないところが悩ましい部分です。
SRE 本は「監視システムはシンプルさを意識して設計せよ」と書き、ルールは実際の障害をよく捉え、単純で予測可能で信頼できるものにするよう求めていました。
人を呼び出す通知は、緊急で、対処可能で、利用者に見えている事象に限るべきだとしています。
呼ばれた側が毎回きちんと切迫感を持てる程度に、通知が珍しい状態を保つ、という基準も示されています。
同章が挙げる四大シグナル（レイテンシ・トラフィック・エラー・サチュレーション）は、その「まず何を測るか」を絞るための出発点でした。
この4つはゴールデンシグナルと呼ばれ、それぞれの測り方と取りこぼしやすい点は別の記事で原典に沿って整理しました。
計測を足すと運用も増えるので、ダッシュボードとアラートの棚卸しを同時に回すほうが健全です。
最後に
監視とオブザーバビリティは、対立する道具ではなく先に決めた問いを見張る仕組みと、後から問いを作れる性質という関係でした。
材料になるのはメトリクス・ログ・トレースの三つで、気づく・絞る・読むの順に役割が分かれます。
そして信号の数を増やすことより、単純さと「通知が珍しい状態」を保つことのほうが先に来ます。
私は SRE 未経験なので、まずは手元の仕組みで三つの信号のどれが欠けているかを数えるところから始めるつもりです。
以上です。
コメントを残す