「自分のマシンでは動く」と「本番環境で動く」の間にはギャップがあります。モニタリングはそのギャップを埋めるはずなのに、大抵はうまくいきません。開発者が問題に直面した時に手が伸びるツールではなく、運用チーム向けのツールとして構築されているからです。
悪いモニタリングとは#
ツールがないことではありません。こういうことです：
- 盲目的なデバッグ：本番環境のログにアクセスできれば5分で済むバグに、開発者が3時間費やす
- 顧客がバグを見つける：アラートではなく、サポートチケットから障害を知る
- アラート疲労：1日200件のアラート、ほとんどが無関係で、全員がすべてを無視する
- 遅いインシデント対応：何かが壊れて、最初の30分は修正するのではなく何が起きたかを把握することに費やされる
パターンは毎回同じです。モニタリングは存在するけれど、開発者の実際の作業フローとつながっていないのです。
本当に必要なもの#
メトリクス、ログ、トレース—連携していること#
- メトリクスは何かがおかしいことを教えてくれる（エラー率の急上昇、レイテンシの跳ね上がり）
- ログは何が起きたかを教えてくれる（スタックトレース、リクエストペイロード、エラーメッセージ）
- トレースはどこで起きたかを教えてくれる（どのサービス、どのエンドポイント、どのデータベースコール）
これらはリンクされていてこそ役に立ちます。アラートが発火した時、メトリクスから関連ログ、トレースへとクリックスルーできるべきです。開発者が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分ごとのバッチ処理ではなく）
- リリースが問題を引き起こしたかどうかを確認できるデプロイメントマーカー付きダッシュボード
- サービス境界を越えて機能する分散トレーシング
運用チームではなく開発者のためにモニタリングを構築する#
DevOpsチームが犯す最大の間違い：自分たちのためにモニタリングを構築すること。
開発者と話す#
ツールを選ぶ前に：
- デバッグセッション中に開発者の横に座る。何をしているか、何を検索しているか、どこで行き詰まっているかを観察する。
- インシデント中にどんな質問をするか聞く。「どのサービス？」「何が変わった？」「リクエストはどんな形？」
- 製品にとって重要なメトリクスを見つける。CPUではなく、チェックアウト完了率、検索レイテンシ、ファイルアップロード成功率のようなもの。
摩擦を取り除く#
新しいサービスの計装に1日かかるなら、開発者はやらないでしょう。以下を提供する：
- 一般的なフレームワーク（Django、Express、Spring）を自動計装するライブラリ
- ダッシュボードとアラートのコピペテンプレート
- チケットを起票しなくても開発者が自分でメトリクスを追加できるセルフサービスツール
メンテナンス性を保つ#
- モニタリング設定をバージョン管理に保存する
- アラートルールをテストする—アラートが発火すべき時に発火することを検証する
- マルチリージョンに向かうなら最初から計画する
チームサイズ別のツール選択#
AWS上の小規模チーム：CloudWatchから始める#
50人以下のエンジニアでAWS上で運用しているなら、CloudWatchが正しい出発点です。
設定不要のインフラメトリクス：EC2、Lambda、RDS、ECSはすべて自動的にCloudWatchにレポートします。計装コードを書かなくても可視性が得られます。
低コスト：小規模チームで月額$10-50。固定のプラットフォーム料金なし。
すべてが一箇所に：メトリクス、ログ、トレース（X-Ray経由）、アラーム。ツールの乱立が少ない。
すぐにセットアップ可能：数週間ではなく数時間で意味のあるアラートとダッシュボードを構築。
CloudWatchを活用するコツ#
- CloudWatch Logs Insightsは過小評価されています。ElasticSearchをセットアップしなくてもログをクエリできます：
fields @timestamp, @message
| filter @message like /ERROR/
| stats count() by bin(5m)複合アラームでノイズを削減。エラー率が高い AND レスポンスタイムが劣化している時にアラート。各条件を個別にではなく。
カスタムメトリクスこそ価値がある。CloudWatch SDKを使ってビジネスメトリクス（サインアップ、トランザクション、機能使用状況）をインフラメトリクスと一緒に追跡する。
CloudWatch Syntheticsはスケジュールでユーザージャーニーをシミュレートするカナリアテストを実行。ユーザーより先に重要なパスの破損を発見。
X-Ray統合で最小限のセットアップで分散トレーシングを実現。ほとんどのマイクロサービスアーキテクチャには十分。
移行すべき時#
CloudWatchの限界が見え始めるのは：
- マルチクラウドに移行する時
- 高度な異常検出が必要な時
- ダッシュボードのカスタマイズが困難になった時
- 50人以上のエンジニアでより良いコラボレーション機能が必要な時
大規模チーム：DataDog#
DataDogは高価です（大規模組織で年間$20-100K以上）が、スケール時にはその価値があります。
クロスプラットフォーム：AWS、Azure、GCP、オンプレミス、コンテナ、サーバーレス、データベース、フロントエンド—すべてを一つのビューで監視。
自動異常検出：Watchdogが手動の閾値設定なしに異常パターンを検出。数千のサービスを手動で監視することはできません。
チームコラボレーション：チーム固有のダッシュボード、RBAC、共有調査ノートブック、PagerDuty/Opsgenie統合。
高度なアラート：複数条件アラート、予測（閾値突破の予測）、トラフィックパターンに適応する異常検出、メンテナンスウィンドウ。
深いAPM：コードレベルのプロファイリング、トレースに紐づくセキュリティ監視、サービス別コスト帰属、自動生成のサービスマップ。
DataDogの展開#
小さく始める：重要なサービスから計装。タグ付けでチームと環境別に整理。
早めに標準を設定：メトリクスの命名規則、ダッシュボードテンプレート、アラートの重要度レベル、SLO定義。これにより後の苦痛が大幅に軽減されます。
すべてと統合：CI/CDデプロイメントマーカー、インシデント管理、Slack通知、ITSMチケッティング。
チームをトレーニング：内部ドキュメント、チームチャンピオン、APMとプロファイリングのワークショップ。DataDogは強力ですが学習曲線があります。
コストを注視：ノイズの多いメトリクスをフィルタリング、大量サービスでのトレースサンプリング、機能使用状況の定期監査、すべてにコスト配分用タグ付け。
代替案#
- New Relic：DataDogに似ている、大量トレーシングで安い場合も
- Dynatrace：AI/AIOpsが強い、金融サービスで人気
- Splunk：ログ分析は最強クラス、セキュリティ用に既に使っているなら特に
- Grafana Cloud：オープンソース寄り、Prometheus/Lokiを既に使っているなら最適
ハイブリッドアプローチ#
多くのチームはツールを組み合わせています：
- AWSネイティブサービスにはCloudWatch（自動、安い）
- アプリケーションとクロスプラットフォームの可視性にはDataDog
- DataDogがCloudWatchメトリクスを取り込んで統一ビューを実現
これが最も実用的な構成であることが多いです。
よくある落とし穴#
ツール過多：連携する3つのツールは、連携しない6つのツールに勝ります。あらゆるモニタリング製品を導入しないこと。
コンテキストのないメトリクス：「リクエスト/秒」を表示するグラフはベースラインなしでは意味がありません。500 rpsは正常なのか10倍のスパイクなのか？
誰も使わない：開発者がダッシュボードを開かないなら、モニタリングは機能していません。ワークフローの一部にすること。別のシステムにしないこと。
間違ったものを監視する：ユーザーとビジネス成果にとって重要なものを追跡する。「ステートレスコンテナのディスクI/O」はおそらく不要です。
モニタリングのモニタリングがない：インシデント中にアラートシステムがダウンしたら、最も重要な時に何も見えなくなります。冗長性を組み込むこと。
はじめの一歩#
ゼロからモニタリングを構築する場合、または壊れた構成を修正する場合：
- まず開発者と話す。インシデント中に何に苦労しているかを聞く。
- SLOを定義する。最も重要なユーザーフローにとって「動いている」とはどういう意味か？目標を設定する。
- クリティカルパスを計装する。最も重要なユーザージャーニー—ログイン、チェックアウト、検索、ビジネスを支えるもの—から始める。
- トレーシングを追加する。分散トレーシングはマイクロサービスアーキテクチャにおいて最大のデバッグROIを提供。
- ランブックを書く。すべてのアラートに、何を確認すべきか、一般的な原因の修正方法を説明するドキュメントへのリンクを。
- 四半期ごとにレビュー。古いアラートの削除、閾値の更新、ダッシュボードが現在のアーキテクチャを反映しているか確認。
良いモニタリングとは最も豪華なツールを持つことではありません。開発者が問題を素早く修正するために必要な情報を提供することです。