これまで見てきたモニタリング環境の多くは、運用チームが運用チームのために作ったものでした。実際にバグを書き、それを直す羽目になる開発者は後回し。これは順序が逆です。モニタリングはプロダクトであり、そのユーザーは開発者です。開発者に使われていないなら、カバレッジがどれだけ立派に見えても意味がありません。
これを間違えたときのコストは、探すまでもなく目に入ってきます。見えない問題を再現しようとして何時間も溶かす開発者。アラートではなく怒ったユーザーから知らされる本番障害。コンテキストのないアラートの洪水と、その結果すべてが無視される状況。被害が出たあとに「何が起きたのか」の解明から始まるインシデント対応。デリバリーが遅くなるだけではありません。目隠しでデバッグさせられて楽しい人はいないので、士気そのものが削られていきます。
「良いモニタリング」の条件#
3本柱と呼ばれるメトリクス・ログ・トレースは、もはや前提条件です。メトリクスは何かがおかしいと教えてくれて（CPU、メモリ、リクエストレート、レイテンシパーセンタイル）、ログは何が起きたかを語り、トレースはどこで始まったかを示す。良い環境とツールの寄せ集めを分けるのは、この3つがつながっているかどうかです。アラートからログへ、ログからトレースへ、頭を切り替えたりタイムスタンプをコピペしたりせずに移動できること。
ダッシュボードは、作った人ではなく見る人のために作るべきです。つまり、技術メトリクスの隣にビジネスメトリクスがあり、健全性がひと目で分かり、概要から詳細へドリルダウンでき、直近のデプロイや設定変更といったコンテキストが同じ画面にあること。「自分のサービスは大丈夫か？」に答えるために、開発者がモニタリングの専門家になる必要はないはずです。
一番崩れやすいのがアラートです。閾値はベースラインと異常検出から導くべきで、2022年に誰かが勘で決めた数字のままにしてはいけません。問題はそれを担当するチームにルーティングし、関連するアラートは50件バラバラに鳴らさずグループ化する。そしてすべてのアラートは「何が壊れたのか」に答え、少なくとも「どこから見ればいいか」を示唆すること。最後に、ループは速く。問題の発生から開発者が知るまでは秒単位であるべきで、そのためにはリアルタイムのメトリクス、検索可能なストリーミングログ、サービス境界をまたぐトレーシング、リリースと障害を突き合わせるためのデプロイマーカーが必要です。
地味な下準備をやる#
ツール選定の前に、デバッグ中の開発者に張り付いてみてください。繰り返し出てくる質問、今のプロセスのどこが痛いのか、プロダクトの成功を本当に表すメトリクスは何か。それが分かったら、参入障壁を下げます。計装を簡単にするライブラリとSDK、よくあるケースのテンプレート、セルフサービスのダッシュボード、そして「使い方」だけでなく「なぜ大事か」を説明するドキュメントです。
モニタリング自体も進化するシステムとして扱いましょう。設定はすべてInfrastructure as Codeに、アラート定義とダッシュボードはバージョン管理に、モニタリングルールには自動テストを。マルチリージョンやマルチクラウドも、追い込まれる前に計画しておくべきです。
スタックの具体像#
ツール名は移り変わりますが、現代的なスタックの形はだいたい安定しています。
- メトリクス：時系列データベース（Prometheus、InfluxDB、TimescaleDB）、APMツール、そしてビジネスロジックから出すカスタムメトリクス。
- ログ：集中管理された集約基盤（ELK Stack、Splunk、Loki）、クエリ可能にするための構造化ログの標準、コストと有用性のバランスを取る保持ポリシー。
- トレース：計装はOpenTelemetry、可視化はJaeger、Zipkin、Honeycombあたり、量が増えてきたらサンプリング戦略。
- 合成監視：複数リージョンからの死活監視、スクリプト化したユーザージャーニー、APIヘルスチェック。
- リアルユーザーモニタリング（RUM）：フロントエンドのパフォーマンス、ユーザー体験のメトリクス、本番トラフィックからのエラー追跡。合成カナリアは、ホテルのWi-Fiにつないだ3年前のAndroid端末を使ってはくれませんから。
AWSの小規模チームならCloudWatchから#
AWS上の小さなチームにとって、実際に役立つものへの最短経路はCloudWatchです。EC2、Lambda、RDS、ECSは設定ゼロでレポートしてくるので、計装を書かずにインフラの可視性が手に入ります。従量課金で、小規模なら月額10〜50ドル程度、固定のプラットフォーム料金なし。メトリクス、ログ、トレース（X-Ray経由）、アラームが1か所に揃い、意味のあるアラートとダッシュボードは数時間で作れます。
使い倒すためのポイント：
- CloudWatch Logs Insightsは、多くの人がElasticsearchを立てて実現していることを代替できます。
fields @timestamp, @message | filter @message like /ERROR/ | stats count() by bin(5m)のようなクエリ1行で「エラーは増えているか？」に答えられます。 - 複合アラームでノイズを抑える。エラー率が高く「かつ」応答時間が劣化したときに発報し、条件ごとに個別には鳴らさない。
- ダッシュボードはビジネスと技術のメトリクスを混ぜてこそ価値が出ます。オフィスのテレビに映すか、Slackにリンクを貼っておきましょう。
- 本当の価値はカスタムメトリクスにあります。エージェントかSDKで、サインアップ、決済、機能の利用状況をインフラの数字の隣に置く。
- CloudWatch Syntheticsでクリティカルパスをなぞるカナリアをスケジュール実行すれば、チェックアウトの故障をユーザーより先に知れます。
- X-Rayなら最小限のセットアップで分散トレーシングが手に入り、CloudWatch連携で高レベルのメトリクスからリクエスト単位のトレースまでつながります。
いずれ卒業のときは来ます。エンジニアがおよそ50人を超えたとき、マルチクラウドになったとき、機械学習ベースの本格的な異常検出が欲しくなったとき、あるいはダッシュボードのカスタマイズやアラートロジックがUIの限界に突き当たったときです。
エンタープライズ規模ならDataDog#
複数環境で数百のサービスを動かす規模になると、DataDogが事実上の標準で、その評価はおおむね妥当です。AWS、Azure、GCP、オンプレ、コンテナ、サーバーレス、データベース、サードパーティサービス、フロントエンドまで、すべてをひとつのビューで監視できます。Watchdogが機械学習で異常を検知し、根本原因の候補まで提示してくれるのも重要です。数千のサービスを人間が見張ることはできないので。もう半分の価値はコラボレーションの層にあります。チーム別のダッシュボード、ロールベースのアクセス制御、共有の調査ノートブック、PagerDutyやOpsgenieとの連携。アラートも必要なだけ深く作り込めます。ブール論理の複数条件アラート、閾値超過を先回りする予測アラート、トラフィックパターンに適応する異常検出、メンテナンスウィンドウ。APMはコードレベルのプロファイリング、トレースに紐づくセキュリティ監視、サービス別のコスト帰属、自動生成のサービスマップまで届きます。
大きな組織への展開には、しっかりした計画が要ります。導入は段階的に。重要なサービスから始め、チーム・環境・事業部門でタグ付けして整理します。標準は早めに決めること。メトリクスとタグの命名規則、サービスタイプ別のダッシュボードテンプレート、アラートの重要度とエスカレーションパス、階層別のSLO定義。既存ツールとは全部つなぎます。デプロイマーカーのためのCI/CD、インシデント管理、SlackやTeams、ITSMのチケット発行。教育にも投資が必要です。社内ドキュメント、チームごとの推進役（チャンピオン）、APMとプロファイリングのワークショップ。そして請求額は意図を持って管理すること。エンタープライズなら年間2万〜10万ドル超になるので、価値の低いノイズメトリクスをフィルタし、大量トラフィックのサービスはトレースをサンプリングし、機能の利用状況を監査し、コスト配分のためのタグ付けを徹底します。
うまく回れば見返りは大きい。相関機能によるインシデント解決の高速化、ユーザーが気づく前の問題検知、運用チームの順番待ちをせずセルフサービスで動ける開発者、そしてインフラの適正サイズ化につながるリソースの可視性。これだけでライセンス代の元が取れることもあります。
契約前に見積もっておきたい代替案は、New Relic（機能は近く、大量トレーシングなら安いことも）、Dynatrace（AIOpsが強く、大手金融で定番）、Splunk（セキュリティ部門がすでに使っているならログ分析は無敵）、Grafana Cloud（Prometheus/Loki勢の自然な選択肢）です。
ハイブリッドで満足している組織もたくさんあります。AWSネイティブのサービスは自動でCloudWatchにレポートさせ、アプリケーションとAWS外はDataDogでカバーし、CloudWatchのメトリクスをDataDogに取り込んで単一ビューを保つ。コストと機能のバランスが取れた、揉めない構成です。
もう半分は文化#
習慣が伴わなければツールは機能しません。計装は本番コードとして扱うこと。コードレビューの対象にし、カスタムメトリクスにはテストを書き、モニタリングに関する判断はアーキテクチャ議論の中で文書化する。インシデントはモニタリングへのフィードバックとして扱うこと。非難なしのポストモーテムを行い、毎回「どんなモニタリングがあればもっと早く気づけたか？」と問い、実際にダッシュボードとアラートを更新する。そして四半期ごとの棚卸し。使われていないダッシュボードとアラートを消し、システムの変化に合わせて閾値を調整し、アラートがまだ正しく鳴ることを検証し、ドキュメントを正直な状態に保ちます。
落とし穴は予測可能で、私はどれも実際に見てきました。連携する少数のツールではなく、ピカピカの新ツールを片っ端から導入してしまう。ベースラインもトレンドもないグラフで、数字の良し悪しが誰にも分からない。技術的には見事なのに、誰もトレーニングされていないせいで使われないシステム。ユーザーにとって重要だからではなく、好奇心で集められたメトリクス。そしてモニタリング自体の冗長性の欠如。目が一番必要な瞬間に、目が見えなくなります。
モニタリングの立て直しを始めるなら、私ならこの順番でやります。現状のギャップと痛点を棚卸しする。ユーザー体験を軸にSLOとSLIを定義する。最重要のユーザージャーニーから計装する。分散トレーシングを入れる（マイクロサービスの世界ではデバッグ面の効果が一番大きい）。すべてのアラートをランブックにリンクする。そして効果を測る。MTTR、デプロイ頻度、それから開発者が実際に「楽になった」と言うかどうか。
最後のひとつが本当のテストです。良いDevOpsの仕事はシステムを動かし続けるだけではなく、開発チームを速く、落ち着いて働けるようにします。開発者が自発的に開くモニタリングは、それができている一番分かりやすい証拠です。