開発者のためのモニタリング（監視）がやるべきことは、突き詰めればひとつです。何かが壊れたらすぐに知らせ、何がどこで壊れたのかをその場で見せること。そのためには、メトリクス・ログ・トレースが互いにリンクされていて、アラートが調べ始める場所を指し示し、ダッシュボードが言われなくても開かれるものになっている必要があります。監視ツール選びはその次の話で、AWSなら小さなチームはCloudWatchで十分、規模が大きくなればDatadogが値段に見合ってきます。
「手元では動く」と「本番で動く」の間にはギャップがあって、モニタリングはそれを埋めるためにあるはずです。ところが大抵は埋まりません。開発者が障害時に手を伸ばすツールとしてではなく、運用チーム向けのツールとして作られてしまうからです。
最近フリーランスとしてDevOpsやインフラの仕事を始めたのですが、新しい現場に入ってまず見るもののひとつがモニタリングの構成です。READMEよりよほどチームの実態が分かります。そして失敗パターンはほぼ毎回同じです。ツールは揃っているのに、開発者の実際の仕事の流れとつながっていない。本番ログが見られれば5分で片付くバグに誰かが3時間溶かす。障害はアラートではなくサポートチケットで発覚する。あるいは逆に、1日200件のアラートのほとんどがノイズで、全員がすべてを無視するようになり、インシデントのたびに最初の30分を「直す」のではなく「何が壊れたのか」の特定に費やす、という具合です。
この記事は一般論です。2つのプロダクトで私がいま実際に使っているツールは、別の記事にまとめました。
メトリクス・ログ・トレースはつながってこそ#
メトリクスは「何かがおかしい」ことを教えてくれます（エラー率の急上昇、レイテンシの跳ね上がり）。ログは「何が起きたか」（スタックトレース、リクエストペイロード、エラーメッセージ）。トレースは「どこで起きたか」（どのサービス、どのエンドポイント、どのDBコール）。ここまでは常識です。重要なのは、この3つがリンクされているかどうか。アラートが鳴ったら、メトリクスから該当ログ、そしてトレースへとクリックだけでたどれるべきです。開発者が3つのツールを行き来してタイムスタンプを手作業で突き合わせているなら、個々のツールがどれだけ立派でも、その構成は失敗しています。
ダッシュボードにも同じテストが使えます。CPU、メモリ、ディスクI/Oはキャパシティプランニングには大事ですが、500エラーのデバッグには役立ちません。開発者が自発的に開くダッシュボードには、技術メトリクスの隣にビジネスメトリクス（エラー率の横に毎時サインアップ数）、タイムラインに重ねた直近のデプロイ、直近1時間のエラートップ5（ログへのリンク付き）、そして平均値ではなくレイテンシのパーセンタイル（p50、p95、p99）が並んでいます。誰にも自発的に開かれないダッシュボードは、存在価値を証明できていません。
アラートも同じ発想です。すべてのアラートは「何が壊れたのか」「どこから調べればいいのか」の2つに答えるべきです。
ダメなアラート：「web-server-3のCPUが高い」
良いアラート：「14:32以降、/api/paymentsのエラー率が5%超。最終デプロイ：14:15、@sarah。[ログを見る] [トレースを見る]」
後者に近づけるコツはいくつかあります。恣意的な閾値ではなくベースラインからの逸脱で発報する。オーナーシップでルーティングする（決済のエラーは組織全体ではなく決済チームへ）。関連エラーは50件の個別通知ではなく1つのSlackメッセージにまとめる。そしてフィードバックループは短く。「何かが壊れた」から「開発者が知る」までは1分以内が目安で、そのためには5分ごとのバッチではなくリアルタイムのログストリーミング、全ダッシュボードへのデプロイマーカー、サービス境界をまたいでも切れない分散トレーシングが必要です。
使う人のために作る#
運用チームがやりがちな最大の失敗は、自分たちのためにモニタリングを作ってしまうことです。対策は別に高度なものではありません。デバッグ中の開発者の隣に座って、どこで詰まるかを観察する。インシデント中にどんな質問が飛び交うかを聞く。「どのサービス？」「何が変わった？」「リクエストの中身は？」。プロダクトにとって本当に重要なメトリクスを突き止める。それはまずCPUではなく、チェックアウト完了率やアップロード成功率のようなものです。
次に摩擦を取り除きます。新しいサービスの計装に丸1日かかるなら、誰もやりません。使っているフレームワーク（Django、Express、Spring）を自動計装するライブラリ、コピペで使えるダッシュボードとアラートのテンプレート、チケットを切らずに自分でメトリクスを追加できるセルフサービスの仕組みを用意しましょう。そして全体をコードとして扱うこと。設定はバージョン管理に入れ、アラートルールは「鳴るべきときに鳴る」ことをテストし、マルチリージョンに向かうつもりなら早めに織り込んでおきます。
AWSの小規模チームならまずCloudWatch#
エンジニア50人以下でAWSに乗っているなら、CloudWatchが正しい出発点です。初日から高級なツールを買いたくなる気持ちは抑えたほうがいい。EC2、Lambda、RDS、ECSは自動でCloudWatchにレポートするので、計装コードを書かなくても可視性が手に入ります。小規模チームなら月額10〜50ドル程度で固定のプラットフォーム料金はなし。メトリクス、ログ、トレース（X-Ray経由）、アラームが一箇所に揃います。意味のあるアラートとダッシュボードなら、数週間ではなく午後のうちに作れます。
過小評価されがちなのがCloudWatch Logs Insightsです。Elasticsearchを立てなくてもログにクエリを投げられます：
fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(5m)そのほかのポイント：
- 複合アラームでノイズを減らす。エラー率が高く「かつ」レスポンスタイムが劣化しているときに発報する。条件ごとに個別ではなく。
- 本当の価値はカスタムメトリクスにあります。CloudWatch SDKでビジネスメトリクス（サインアップ、トランザクション、機能の利用状況）をインフラメトリクスと並べて送りましょう。
- CloudWatch Syntheticsは、ユーザージャーニーをなぞるカナリアテストをスケジュール実行してくれます。チェックアウトが壊れていることに、ユーザーより先に気づけます。
- X-Rayなら最小限のセットアップで分散トレーシングが手に入ります。大半のマイクロサービス構成にはこれで十分です。
卒業のタイミングも分かりやすいです。マルチクラウドになったとき、本格的な異常検出が欲しくなったとき、ダッシュボードのカスタマイズがつらくなったとき、あるいはチームが50人を超えて本格的なコラボレーション機能が必要になったときです。
大きめのチームならDatadog#
Datadogは高いです。大きな組織なら年間2万〜10万ドル超は普通ですが、スケールすれば元は取れます。AWS、Azure、GCP、オンプレ、コンテナ、サーバーレス、データベース、フロントエンドを1つのビューで監視できます。Watchdogが手動の閾値設定なしで異常パターンを検出してくれるのも大きい。数千のサービスを人間が目視で見張ることはできませんから。さらにCloudWatchにはないコラボレーションの層が揃っています。チーム別ダッシュボード、RBAC、共有の調査ノートブック、PagerDuty/Opsgenie連携、複数条件アラート、閾値突破の予測、メンテナンスウィンドウ、そしてコードレベルのプロファイリングまで潜れるAPMと自動生成のサービスマップです。
導入はだいたいこの順番でやります。まず重要なサービスから計装し、初日からチームと環境でタグ付けを徹底する。命名規則、ダッシュボードのテンプレート、アラートの重要度レベル、SLOの定義は早い段階で合意しておく（標準の後付けは本当に苦行です）。CI/CDのデプロイマーカー、インシデント管理、Slackと連携させる。トレーニングの時間も確保すること。Datadogは強力ですが、直感だけでは使いこなせません。そして請求額には目を光らせる。ノイズの多いメトリクスをフィルタし、大量トラフィックのサービスではトレースをサンプリングし、実際に使っている機能を定期的に棚卸ししましょう。
契約前に見ておく価値があるのは、New Relic（似た構成で、大量トレーシングなら安いことも）、Dynatrace（AIOpsが強く金融系で人気）、Splunk（ログ分析は最強クラス、セキュリティ部門がすでに使っているならなおさら）、Grafana Cloud（すでにPrometheus/Lokiなら自然な選択）あたりです。
実際のところ、多くのチームはハイブリッドに落ち着きます。AWSネイティブなサービスは自動で安いCloudWatch、アプリケーション層はDatadog、そしてCloudWatchのメトリクスをDatadogに取り込んで統一ビューにする。地味ですが、ちゃんと機能します。
CloudWatchとDatadogの比較#
| CloudWatch | Datadog | |
|---|---|---|
| 向いているチーム | エンジニア50人以下、AWSだけのチーム | サービスが多く、複数のクラウドを使う大きめの組織 |
| コストの形 | 従量課金で固定のプラットフォーム料金なし。小規模チームなら月10〜50ドル程度 | 大きな組織なら年間2万〜10万ドル超が普通。請求額から目を離せない |
| 導入の手間 | EC2・Lambda・RDS・ECSは自動でレポート。意味のあるアラートなら午後のうちに | 重要なサービスから計装、タグと命名規則を早めに合意、トレーニングの時間も必要 |
| マルチクラウド | AWS中心。マルチクラウドになったら卒業のサイン | AWS・Azure・GCP・オンプレ・コンテナ・サーバーレスを1つのビューで |
| 異常検出 | 基本は自分で調整するアラーム。それ以上が欲しくなったらこれも卒業のサイン | Watchdogが手動の閾値設定なしで異常を検出 |
| コラボレーション | 手薄。50人を超えると物足りなくなる | チーム別ダッシュボード、RBAC、共有ノートブック、PagerDuty/Opsgenie連携 |
| トレーシング | X-Ray、最小限のセットアップ | コードレベルのプロファイリングまで潜れるAPM、自動生成のサービスマップ |
ゼロから始めるなら：モニタリング構築の手順#
私ならこの順番でやります。
- まず開発者に、インシデント中に何がつらいかを聞く。
- 重要なフローのSLOを定義する。ログイン、チェックアウト、検索にとって「動いている」とは何か。
- そのクリティカルパスから計装する。
- 次に分散トレーシングを入れる（マイクロサービス構成ではデバッグ効率への投資対効果が一番高い）。
- アラートはCPUではなくそのフローに設定し、それぞれ担当チームに届くようにする。
- すべてのアラートにランブックを書き、午前3時の自分が何を確認すべきか分かるようにする。
- 四半期ごとのレビューをカレンダーに入れ、古いアラートを消し、ずれた閾値を直し、ダッシュボードが今のアーキテクチャを反映しているか確認する。
私がこれまで何度もチームを救い出してきた落とし穴も挙げておきます。ツールの入れすぎ（連携する3つは連携しない6つに勝る）。ベースラインのないグラフ（500 rpsは平常なのか10倍のスパイクなのか？）。ユーザーに関係ないものの監視（ステートレスなコンテナのディスクI/Oなど）。そしてモニタリング自体の冗長性の欠如。インシデントの最中にアラート基盤が落ちたら、一番見えなくてはいけない瞬間に何も見えなくなります。
どれも最高級のツールは必要ありません。必要なのは、開発者が必要な情報を、実際に見る場所で、素早く手にできることです。