みなさん、監視作ってますか？
システムを作ったら、そのシステムを監視していく必要がありますよね。どうやったら「いい監視」が作れるのでしょうか。「いい監視」とそうでない監視との違いとは、いったいなんでしょうか。 今の時代、「監視」ではなくて「可観測性」、 Observability (o11y) の時代になっていて、良いプラクティスや考え方が色々とあります。
この記事は、監視や o11y についての考え方を社内に共有するため書いたものを、社外共有用に調整し直したものです。新しい Observability の時代を、一緒に生きていきましょう。
監視を作ろう
あなたはシステムを作りました。そのシステムに「監視」をつけようと思ったとき、最初にすることはなんでしょうか？
まずは、システムを何らかのツールで監視するところから始めましょう。やらなきゃはじまらない。 Nagios, Cacti, Munin, Zabbix, Prometheus, Datadog, CloudWatch, Mackerel, … 世の中には監視ツールが溢れています。どんなものを使っても、おおむね CPU とメモリの使用量は見えることでしょう。
さて、ツールを設定して CPU ・メモリ使用量が取れたら、次はアラートを追加しましょう。 CPU 使用量が 5 分間以上 60% とか 80% とかになっていたら危なそうですね。メモリ使用量も似たような値になったら怖いかも。
アラートが設定できたら、これで監視の完成です！おめでとう！ tada!! 🎉
……本当にそうでしょうか？
そもそも監視ってなんのためにあったんだっけ？
困ったときは、目的に戻るのが鉄則です。監視の目的ってなんでしたっけ？
サービスが健康に生きていることを確認したい、システムが正しく稼働していることを知りたい、といったところでしょうか。
おっと、問題が起きたときに、あとから何が起きていたか調べたいということもありますよね。 CPU が精一杯だったのか、メモリのせいなのか、ソケットが埋まっていたのか、情報が溜まっていれば改善案もすぐに出せます。
さらには、長期的なトレンドを取っておいて、季節性のアクセス予測に使いたい、といったこともあります。たとえば、繁忙期のアクセスが普段の何倍になるかという情報は、サービスが成長した一年後でもまずまずの正確性のある参考情報となります。
……色々ありますね。どれを重視すれば良いのでしょうか？
Google 曰く
困った時は Google に聞いてみましょう。検索の方ではなく、 SRE の総本山としての Google です。 Google は、監視の目的について以下のように述べています。
- サービスの停止や低下の兆候を示す指標を提供する。
- サービスの停止や低下、バグ、不正行為を検出する。
- サービスの停止や低下、バグ、不正行為に対するデバッグをサポートする。
- キャパシティ プランニングとビジネス目的で長期的な傾向を把握する。
- 変更や追加機能による想定外の影響を明らかにする。
DevOps の能力 | Cloud アーキテクチャ センター | Google Cloud
先ほど挙げた例も含まれていますね。そう、監視の目的ってたくさんある。 ここに挙げられている用途は、以下の二つにまとめられます。
- 何かが起きる前に、問題の兆候を把握するためのもの
- 何かが起きたときにその原因を探るなど、あとから情報を見るもの
前者を Proactive monitoring、後者を Reactive monitoring と呼んでいます。
Proactive monitoring
Proactive 監視は、何かが起こる前に問題を認識するための監視です。
サービスの利用が段々高まっていて CPU 使用率の平均が今週に入って 60% を超えてきた、とか、デプロイ直後からメモリ使用量が倍になっている、とか。まだ障害には至っていないものを先に検知したいときに使いたい監視です。
どうやって実現するか、というと、一般的にはダッシュボードを構築することが推奨されています。直近で何が起きているか、これまでのトレンドがどうなっているか、といったことをひと目で確認することが目的です。こういったダッシュボードを作成して、メンテナンスしていくことが重要とされています。
（「早めのアラート」も、もちろん Proactive な Monitoring としては非常に有力な手段です。ただ、これは後述するのですが、多すぎるアラートは人間が疲弊するのであまりお勧めできません）
ダッシュボードを作る際は、以下の点が重要となります：
- 見たいグラフを厳選する
- グラフあたりの線の数を最小限にする
- 愛情持ってダッシュボードをメンテする
- 4 Golden SignalsGoogle - Site Reliability Engineering を参考にする
まず、グラフの数は7つ程度が推奨されています。これは、ダッシュボードは常に見える場所に置いておくことを想定しているからで、とにかく「ひと目でわかる」ことが重要になります。何かが起きたらすぐわかる、そういうグラフだけを厳選して並べます。
ダッシュボードは、インサイトを得るためのものです。インサイトを得られるか怪しいグラフは全て、ダッシュボードから消します。
線の数を減らすのも同じ理由です。たとえばメモリ使用量で考えると、できるだけ多くの情報を盛り込もうとついつい「全コンテナのメモリ使用量」を並べてグラフにしたくなりますが、それはあまり意味がありません。実際に大事になるのは、全コンテナのうち最大のメモリ使用量となっているものや中央値、そしてせいぜい最小くらいです。100本の線を見るより、3本の線を見る方が簡単だし、得られるインサイトは同じです。
そして、そうやって作ったダッシュボード。一度作れば完成というわけではありません。インサイトを得られないグラフが入っていないか、新しい機能が入ったことで見たいメトリクスが変わっていないか、常に気にかけていく必要があります。愛情を持ってメンテナンスしていく必要があります。
どういうメトリクスを見ると良いのか、という実例として、 Google が 4 Golden Signals Google - Site Reliability Engineeringというものを出しているので、まずはこれをとれるようにするのが良いです。
- Latency - リクエストにかかった時間
- Traffic - 通信量
- Errors - HTTP Status Code 5xx の割合
- Saturation - サービスの提供余裕（CPU/Memory/通信量など）
Web アプリケーションの基本的なメトリクスですが、サービスレベルでの健康状態を見ようとすると結局これらが一番欲しくなります。
……といった形で、 Proactive monitoring を組んでいきます。
ところで、このダッシュボードはあくまで「状況を把握または予測する」ことが目的でした。そのために、従来の「監視」であれば必要な要素をたくさん削ぎ落としています。
ここで削ぎ落とされた情報は不必要な情報だったでしょうか。例えば障害が起きたとき、コンテナ一つひとつのメモリ使用量の変化が取れてなかったら大変です。
でも大丈夫。それは Proactive monitoring の役割ではなく、 Reactive monitoring の役割だからです。
Reactive monitoring
Proactive monitoring では現在を把握し、未来を予測しました。一方の Reactive monitoring は、過去に何が起きたかを詳細に調べるためにあります。
Reactive monitoring の収集にあたっては、 Datadog の言葉がいい指針になるかと思います。
Collecting data is cheap, but not having it when you need it can be expensive, so you should instrument everything, and collect all the useful data you reasonably can. – datadog
データを集めることは容易だが、必要になったときにデータがないとどうしようもない。監視においては、現実的に可能な限りのデータを収集しておくべきだ。（やや意訳）
これは本当にその通りです。世の中には多数のメトリクスがあり、どの値が影響してくるかなんてその時になってみないとわかりません。
CPU やメモリ以外でも、こんなマイナーメトリクスがエラーの原因を表すことがあります：
- TIME_WAIT 状態のソケットの数
- 通信の数が多すぎるとポートを使い果たす場合あり
- open files
- プロセスあたり 1024 が最大なのでものによっては sysctl 必要
- forks
- Red Hat 系だとプロセス数 1024 が設定されてたり
現時点では必要性がわからなくても、とにかくデータは取っておいて、問題発生時に活かす。これが Reactive monitoring では大事なポイントです。
とはいえ、データの溜め込みにはそれなりの金銭コストがかかります。そのコストも含め、 “Reasonable” に取得できる一通りのデータを溜め込む、という表現が妥当と思っています。
Hello, Observability!!
これまで「監視」 (monitoring) の話をしてきましたが、実は昨今、監視の次の段階として Observability （o11y, 可観測性）という言葉が流行っています。 Observability とは何者なのでしょうか。
Observability （可観測性）の考え方
Google にはこのように書かれています：
DORA の調査では、これらの用語は次のように定義されています。
モニタリングは、チームがシステムの状態を監視して把握できるようにするツールや技術的なソリューションです。モニタリングでは、事前に定義した指標やログの収集を行います。
オブザーバビリティは、チームがシステムのデバッグを積極的に行えるようにするツールや技術的なソリューションです。オブザーバビリティでは、事前に定義されていないプロパティとパターンの調査を行います。
ちょっとよくわかりませんね。
従来の「監視」という言葉には、「ネットワーク機器の死活監視のため、5分ごとに ping や SNMP を叩く」という意図が数十年間にわたって染み付いていました。 CPU, Memory, ping など、基本的なメトリクスを取得している「インフラチーム」はサーバを守ります。その上でサービスを動かすアプリケーションチームで何が起ころうとインフラチームは関わりません。だってサーバが健康なら自分の職務は果たせているんだもの。監視ってそういうことだったんです。
ここに Datadog, New Relic, Prometheus のような「新しい監視」がやってきたとき、同じ「監視」という言葉で表すと容易にハレーションが起こってしまっていたのでした。そこで生み出された「新しい監視」に相当する言葉が可観測性、 Observability です。先ほど書いたような Proactive/Reactive な見方も Observability と言って差し支えないでしょう。
Monitoring と比べたとき、 Observability はより大きい範囲を責務にしています。 Monitoring があくまで「このメトリクスはどうなっているか」ベースだったものが、 Observability では「アプリケーションがどう動いているか」を知ることそのものが目的となっているのです。
より具体的には、 APM (Application Performance Monitoring) もエラートラッキングシステム（Sentry など） も Observability なんです、という話です。
これは、従来の Monitoring であればインフラチームが持っていたものを、 Observability であれば開発者も重要な役割を負っている、ということでもあります。 APM や Sentry に限らず、「アプリケーションが健康に動いているとはどういうことか？」という問いに真の意味で正しく答えられるのは、実際の開発者だけです。
システムで Queue を使用していれば、その Queue の長さ、待ち時間、エラー率なども取りたくなるでしょう。外部 API を叩いていたら、その API のレスポンス時間も見ておくといいかもしれません。またサーバで利用しているワーカーの利用率なども見たくなります。このあたりは SRE が一緒に探っていける点になりそうです。しかしそれでも、開発チーム内からしか出てこない要件というのは確実にありますし、それこそが本当に重要な要件です。
Observability は SRE だけでは完成せず、開発者が圧倒的に重要なのです。
E2E の重要性
実は、 Observability の時代に入って E2E (End-to-end) テストの重要性が見直されています。
昔の監視には Blackbox / Whitebox test という言葉がありました。システムを外側から叩いてその挙動を確認するのが Blackbox test 、システム内部のパラメータを直接見るのが Whitebox test です。 Blackbox test は Whitebox test と比較して、作る手間がかかるわりに得られる情報が少ないものと思われていました。今は完全に逆です。
E2E テストはユーザの体験そのものなので、サービスの品質をより正しく反映しているのです。
オライリー「入門監視」に、こんな逸話が載っています。
システム管理者としてのキャリアを始めた頃、私はリードエンジニアのところへ行きました。あるサーバの CPU 使用率が高いことを伝え、どうしたらよいか聞きました。彼の答えは私を驚かせるものでした。「そのサーバはやるべき処理はしてるんだろう？」そうだと私は答えました。「それなら、何も問題はないじゃないか」
CPU やメモリ使用量のようなプリミティブなメトリクスは、確かに重要です。しかし、もっと重要なのは、「サービスが支障なく提供されている」ことそのものです。これを測れるのが E2E テストであり、また latency のようなメトリクスです。
わかりやすい例で言うと、夜間バッチサーバの CPU 使用率が 100% に張り付いたところで誰も困らない、というものがあります。夜間バッチサーバは、夜中に DB からデータを取得し、そのデータを適切に整形してまた DB に戻す、といったことをします。その間は CPU はフル回転してくれた方が嬉しい。
夜間バッチの健康状態を測りたければ、「何件入ったか」「失敗率はどの程度か」「時間内に終わっているか」などを取得するでしょう。これも usage ベースの監視なので、 E2E の一種と表現できますね。
（もちろん、 CPU やメモリ使用率は非常に重要です。 CPU 100% なら現実的には処理は遅延しますし、メモリは 100% に至れば OOM killer が発動します。なのでこれらのメトリクスを見ることが無駄ということはありません）
SLI/SLO も、このように E2E で考えることが基本となりますね。より詳しくはLearn how to set SLOs -- SRE tips | Google Cloud Blogをどうぞ。
Observability 時代の監視では、システムが「動いている」こと、ユーザがサービスを「利用できている」ことを見ることが基本になります。そのためには E2E での監視が適しているのです。というお話でした。
Alerts の考え方の整理
さて、ここまでアラートの話はあえて避けてきました。監視はアラートがあってこそ人が認識できるようになるので重要ですね。これはどう考えたら良いのでしょう。
実は Observability において、 alert は非常に重要な役割を負っています。というのも、従来の Monitoring において、 alert は多くの人を苦しめてきたからです。
私の友人に、ストレージ管理者がいます。ストレージというのは、 PB 級のストレージデバイスのことです。 40 本の HDD が入るエンクロージャを何十台も並べる機器です。これが止まると、多くのお客様の基幹システムが停止し、甚大な被害が起こってしまいます。そのため、小さなエラーであってもエンジニアが対応する責任があります。サポート部隊は別にありますが、そのサポート部隊の実施内容をエンジニアとして確認したりする必要もあります。
彼はアラートを毎日、朝から晩まで受け続けていました。夜も受けます。土日も受けます。アラート番の週は酒も飲めません。映画も見に行けません。 HDD は壊れるものなので、日曜の午前3時にだって容赦なく電話はかかってきます。しかも、そんな時間に電話がかかってきても、ちょっと1分 PC を開いて「クローズお願いします」とだけ言う、そういうアラートも少なくありません。起き損です。
運用者はみんな、アラートが大嫌いです。 Rob Ewaschuk もその一人です。 Rob は元 Google 社員で、 Monitoring Distributed Systems というオライリー本の作者です。その彼が書いた Alerting に関する文書があります。そこに書かれている Alerting の哲学は、以下のようなものです：
Pages should be urgent, important, actionable, and real.
They should represent either ongoing or imminent problems with your service.
Err on the side of removing noisy alerts – over-monitoring is a harder problem to solve than under-monitoring.
You should almost always be able to classify the problem into one of: availability & basic functionality; latency; correctness (completeness, freshness and durability of data); and feature-specific problems.
Symptoms are a better way to capture more problems more comprehensively and robustly with less effort.
Include cause-based information in symptom-based pages or on dashboards, but avoid alerting directly on causes.
The further up your serving stack you go, the more distinct problems you catch in a single rule. But don't go so far you can't sufficiently distinguish what's going on.
If you want a quiet oncall rotation, it's imperative to have a system for dealing with things that need timely response, but are not imminently critical.
ざっくりまとめると、以下のようになります。
- アラートは、人間による対応が必須であるものに絞る
- 問題が起きているものだけをアラートする
- 事象ベースでアラートを鳴らし、そこから原因となるメトリクスを見る
一つ目の「アラートは、人間による対応が必須であるものに絞る」ですが、これは一言で非常に深いことを言っています。
- アラートは減らさなければならない。多いアラートは少ないアラートよりもはるかに御し難い
- アラートは人間が対応するものに限る。「アクションは不要だが見ておきたい」レベルのものを残しておくと、本当に重要なアラートを見逃す
- アラートは人間が対応できるものに限る。指をくわえて嵐が通り過ぎるのを待つだけのアラートなら出さない方が良い
- アラートを出す場合、チーム内の誰でも対応できるように手順や注意事項をまとめておくべきである。手順が固まったら自動化してアラート自体を消すのが良い
こういう哲学です。
アラートはつい増やしたくなってしまうのですが、立ち止まって「本当に必要なアラート、人間が対応しなければならない現象とはなんだろう」と考えてみることが大事です。 CPU 使用率より、レイテンシやエラー率など、 E2E での現象の方が実態を表していませんか？アラートすべきはそちらかもしれません。
まとめ
さて、まとめです。今回お伝えしたいことは以下の四点です。
- 監視においては、原始的な情報を取れるだけ取っておく
- 4 Golden Signals をスタート地点として、サービスのダッシュボードを構築する
- アプリケーションの何を見たいかは開発者こそが知っている
- アラートは「人間が対応するものだけ」に絞る
Observability を高めることは、プロダクトの品質を高めることそのものです。 Observability が高ければ問題の存在に早く気付け、先回りして対応できますし、実際に問題が発生した際も調査が早く完了し、顧客影響を最小限にすることができます。逆に言うとサービスが価値を生んでこそ Observability にも意味があるので、オーバーエンジニアリングにも注意が必要な部分でもあります。
そして、それ以上にお伝えしたいことは……↓
estie では、 Observability に詳しい SRE はもちろん、 Observability をジブンドリブンに高めていきたい SWE 、 E2E で SLO を定義していきたい PdM, 品質管理のために Observability を高めていきたい QA エンジニアなど、幅広く採用しています。ご興味ある方はぜひ一度、よければカジュアル面談にてお話ししましょう！
