ホスティング型のAPMも、本番のトレーシングも、わざわざ思い出して開くダッシュボードもありません。追加でお金がかかっているのはログアーカイブだけで、月2ドルほどです。以下が全リストと、やめたもの・信じなくなったものです。そのうちのひとつのせいで、私はユーザーが誰ひとり体験していない障害を何日も追いかけていました。

ここで言うモニタリングと、どれだけ小さな規模の話か

#

私がDevOpsモニタリングと言うときは、2つのことを指しています。誰かに言われる前に何かが壊れていると気づけること、そして当て推量なしに原因を突き止められることです。以下のツールはすべて、この2点で評価しています。

昨年、開発者が本当に使ってくれるモニタリングの作り方という記事を書きましたが、そのときはおもにチームを想定していました。小さなチームならクラウド事業者に組み込みのモニタリング、サービスが何百もあるならホスティング型のAPM、という具合です。今回はその同じ考え方の、いちばん小さい側の端です。2つのプロダクトはどちらもいまの技術スタックで書いたとおりFlyのshared-cpu-1xマシン上のDjangoで、開発者はどちらも私ひとりです。モニタリングがプロダクトで開発者がそのユーザーだとすれば、私のモニタリングのユーザーは1人だけということになります。9月にFlyのメトリクスからベースラインを取ったところ、マーケットプレイスのAPIのCPU使用率は平均1%でした。エンタープライズのスタックではありませんし、そう見せるつもりもありません。

メトリクス、ログ、トレースの3本柱のうち、私が持っているのは2本です。どちらのプロダクトにも分散トレーシングはありません。それぞれDjangoのコードベースひとつとデータベースひとつで、トレースがまたぐべきサービス境界がないからです。私が見ているトレースは、自分のワークステーションで動かしているリバースプロキシのものだけです。

一覧

#

「両アプリ」と書いていないものは、すべてマーケットプレイスの話です。見積もりアプリはもっと少なく、Flyのヘルスチェック・ログ・メトリクス、iOSのアプリ解析、そしてデータベースを毎日Parquetに書き出してDuckDBで問い合わせる仕組みくらいです。クラッシュレポートもアラートのチャンネルもなく、この記事でいちばん大きな穴はここです。(アップデートサービスの行について開示しておくと、このサービスを提供している会社は、同社のブログに書く記事に対して私に報酬を払っています。)

エラー：チャットに投稿するロギングハンドラー

#

9月までは、処理されなかった500も、失敗したプッシュ通知も、壊れたWebSocketフレームも、出てくる場所は flyctl logs だけでした。そしてあのストリームを自分から読みに行く人はいません。いまはロギングハンドラーが、API・WebSocketサーバー・バックグラウンドワーカーのどこで起きたものでも、ERROR以上のレコードをすべてチャットチャンネルに送ります。WARNINGはあえて通知しません。

ハンドラーはバックグラウンドのスレッドで送信するので、リクエストを遅くしません。ハンドラーの中では何もログに書かないので、再帰しません。そして同じエラーは10分に1回まで、1時間に最大30件までしか送らないので、障害が起きても千件のメッセージではなく1件として読めます。

このチャンネルには、エラーと突き合わせて読みたいものも流れてきます。デプロイは開始時、立ち上がったとき、失敗した箇所でコミットと実行者付きで投稿し、OTAアップデートやWebリリースも同じです。ひとつのアカウントに間違ったサインインコードが集中したときもERRORで記録するので、誰かが当てずっぽうに試していれば障害と同じ場所に現れます。

10月、どのログにも対応する行がないアラートがひとつ届きました。それ以来、アラートには短いランダムなid、ホスト名、プロセスの起動コマンドを付け、同じ行をそのプロセスのログにも書くようにしています。idがどこにも見つからなければ、そのアラートはそこにログを書かないプロセス、たとえばSSHのシェルから来たということです。チャンネルに届くものはすべて、私が一緒に作業しているコーディングエージェントが読めるフィードにも入ります。コードを触っているエージェントも、私と同じタイミングでエラーを目にするわけです。

ログ：FlyのシッパーでS3へ、DuckDBで検索

#

Fly自身のバッファが持っているのは数分ぶんの出力、だいたい直近100行ほどです。デプロイを見守るには十分ですが、昨日のことには役に立ちません。そこで3つめのFlyアプリでFlyのログシッパーを動かしています。組織のログストリームを購読するVectorで、変えたのはS3シンクひとつだけです。

[sinks.aws_s3]
  type = "aws_s3"
  bucket = "myapp-logs"
  compression = "gzip"
  key_prefix = "logs/{{fly.app.name}}/%F/"   # one folder per app per day
  batch.timeout_secs = 300                  # a quiet app still lands its lines

マーケットプレイスのアプリのログは1行残らず、gzipしたJSONとしてS3互換のバケットにたまります。シッパーは256MBのshared-cpu-1xマシン1台で、月2ドルほど、ストレージ代は小銭程度です。DuckDBはマクロひとつでファイルをその場で読み、1日分ならおよそ1秒で返ってきます。

CREATE MACRO logs(app, day := '*') AS TABLE
  SELECT * FROM read_json_auto('s3://myapp-logs/logs/' || app || '/' || day || '/*.log.gz',
                               union_by_name := true);

SELECT timestamp, message FROM logs('myapp-api', '2026-09-06') WHERE message LIKE '% 500 %';

ゼロスケールの記事でコールドスタートを測ったのも、このマクロでした。起動スクリプトがフェーズごとに名乗り、どの行にもマシンのidが付いているので、あとは GROUP BY だけです。

つまり、ひとつのストリームを読む人ごとに3段階に分けているわけです。アーカイブはINFO以上をすべて保持し(本番のアプリがINFOでログを出しているのはこのためです)、ライブ表示のスクリプトはWARNINGとERRORだけを見せ、チャットチャンネルはERRORを受け取ります。ただ、どれも呼び出し元はわかりません。アクセスログにはクライアントのIPもユーザーエージェントもないので、それはCloudflareで調べます。

メトリクス：Flyに標準で付いてくるPrometheus

#

Flyは組織ごとにマネージドのPrometheusを動かしてくれるので、自前のメトリクス基盤は持っていません。知りたいことがあるときにAPIを叩きます。マシンごとのメモリ、CPU、バーストクレジット(共有CPUでは fly_instance_cpu_balance が効いてきます)、アプリごとのレスポンス数や同時実行数などです。最初に知っておきたかったことが2つあります。fly tokens create で作ったトークンは Authorization: FlyV1 <token> として渡します。Bearer が使えるのは flyctl auth token の個人トークンだけで、読み取り専用トークンだと “something went wrong resolving organization” が返ってきます。そして保持期間はおよそ2週間です(Flyの説明では15日ほど)。

これが本領を発揮したのは9月でした。ログに “Could not open a database connection” が1日に何度も出ていて、どう見てもアプリのバグに見えました。マネージドPostgresのクラスタも同じPrometheusに入っていて、そのエラーが出た分にはいつも、プライマリのスクレイプ時間が80ミリ秒ほどから1〜10秒に跳ね上がっていました。レプリカは平常で、Postgresの起動時刻は動いていません。Postgresが再起動したのではなく、その下のホストが止まっていたのです。タイムスタンプを添えてFlyのサポートに送り、10月初めのメンテナンス再起動でプライマリが別のホストに移ってからは、毎日の停止はなくなりました。

クラッシュレポート：自前のAPIに向けたSentryのSDK

#

以前は、スマホでアプリが落ちても、私に見える場所のどこにも痕跡が残りませんでした。当然の答えはSentryで、私はその半分だけを取り入れました。アプリにはSentryのオープンソースSDKが入っていますが、DSNは私のDjango APIのエンドポイントを指しています。そのエンドポイントがSentryのenvelope形式を受け取り、クラッシュをまとめ、同じチャット用のハンドラーで通知します。トレーシング、セッション、リプレイはオフにしていて、受け取るのはエラーだけです。

sentry.ioに登録しなかったのは、1日に数件のレポートのために、ユーザーデータを預ける業者をひとつ、プライバシーポリシーの記述を1行、請求書を1枚増やしたくなかったからです。代わりに払っている代償はシンボリケーションで、これはまだ置き換えられていません。スタックはminifyされたJavaScriptか生のネイティブアドレスなので、イシューを見れば何がどのリリースと端末で落ちたのか、直前にユーザーが何をしていたのかはわかっても、ソースのどこなのかはわかりません。

ダッシュボードはメッセージ1本

#

どちらのアプリにもダッシュボードは作っていません。昨年の記事にダッシュボードの判定基準を書きました。誰にも自発的に開かれないダッシュボードは存在価値を証明できていない、というものです。勝手に届くメッセージなら開く必要がないので、私にとっていちばんダッシュボードに近いのは、毎朝チームのチャットに届く1本の投稿です。

最初は直近24時間の本番エラーです。チャットチャンネルではなくログアーカイブから読みます。アラートは件数を絞っているので、何かが何回起きたのかを教えてくれないからです。数字、id、アドレスを伏せてからまとめるので、同じ失敗が100件あっても件数付きの1行になり、メールアドレスがチャンネルに流れることもありません。

続いて失敗したヘルスチェック、前日の利用状況を1週間前の同じ曜日と比べたもの(日曜日が月曜日と同じになることはありません)、直近1週間の検索流入、返信待ちのチャット、タスクボード、そして支出です。読み込めなかったセクションはそう書かれ、投稿自体は届きます。

アプリ解析の数字をAPIで読んでいると、少し疑ってかかるようになります。8月にはアゼルバイジャンからAndroidの初回起動が121件あり、その後アンインストールが119件続きました。その月のAndroidの合計は、これを除いて読んでいます。

リリースには専用の画面があります。OTAアップデートを自前のサーバーから配っていたころ、リリースを見る手段は “is active” のチェックボックスが付いた管理画面の一覧だけで、何台がアップデートを受け取ったのかまったくわかりませんでした。いまのサービスのダッシュボードは、端末が実際にどのリリースを動かしているか、インストールがどうだったか、そして壊れたバンドルが落ちてSDKが前のものに戻したときにはそのクラッシュロールバックまで見せてくれます。ホスティング型のアップデートサービスへの移行については別の記事にまとめています。

やめたもの、信じなくなったもの

#

この中に有料のツールはひとつもありません。ほとんどはシグナルだと思っていたのに実はそうではなかったもので、あとひとつは置き場所を間違えていたジョブです。

ユーザーエージェントでまとめるまでの、Cloudflareの504率

#

9月、Cloudflareのダッシュボードには、1日のリクエストの22%が504で失敗しているように見える数字が出ていました。アプリが30秒ごとにポーリングするエンドポイントに集中していて、ヘルスチェックはすべて緑、アプリ自身のログではそのリクエストは速く返っていました。何日もかけました。マシンのコールドスタートに25〜33秒かかり、それが1日92回起きていることを突き止めて直し、ゼロスケールの記事にそれが原因だと書きました。

翌朝、同じ504をユーザーエージェントでまとめてみました。9月5日から9日までの7,344件は、すべてCloudflare自身のEarly Hintsのキャッシュ参照(ユーザーエージェントは bastion early hints と nginx-ssl early hints)でした。この参照はオリジンには一切届きません。その行の504はタイムアウトではなく、キャッシュミスを記録したものです。実際のリクエストのパスをなぞるので、いちばん忙しいエンドポイントに集まり、本当にユーザーが失敗しているように見えました。アプリ、ブラウザ、curl、検索エンジンのクローラーには1件もありません。オリジンが Link ヘッダーを送っていなかったので、Early Hintsは何の役にも立っておらず、いったんオフにしました。その後、ちゃんと動くようにしました。

コールドスタートの対応自体は無駄になりませんでした。デプロイもスリープからの復帰も速くなっています。ただ、直しているつもりだった障害は、一度もユーザーに届いていませんでした。

だからこそ、いちばん伝えたいルールはこれです。CDNのエラー率を信じる前に、ユーザーエージェントでまとめて、CDN自身の仕組みから出たものではないか確かめてください。Cloudflareの無料プランなら httpRequestsAdaptiveGroups へのGraphQLクエリで、1日ずつ見られます。次の騒ぎも同じクエリで片付きました。ポーリング用のエンドポイントのひとつが1日70〜260件から2,880件に跳ね上がったのですが、スクレイパーではありませんでした。テストのあとiOSシミュレーターでアプリを起動したままにしていた、私自身のMacでした。

緑のヘルスチェック

#

Flyは両アプリの /api/health/ を30秒ごとに確認し、その結果でどのマシンにトラフィックを送るかを決めます。その仕事は得意です。ただ、ヘルスチェックはすでに起動しているマシンに対して動くので、マシンが起動する前に起きることは見えません。コールドスタート、プロキシの前の待ち行列、ついに届かないリクエストなどです。いまはルーティング以外のことは期待していません。

デプロイにはかわりにプローブのスクリプトを使います。デプロイのあいだずっとオリジンを叩き、ひとつでも失敗すれば終了コード1で終わります。このスクリプトが素の flyctl deploy で7.3秒の空白を捉え、先に予備のマシンを起こすデプロイスクリプトに切り替えてからは、2,514件中の失敗はゼロでした。

ヘルスチェックは、それ自体が原因の障害も2回起こしています。7月には、Djangoの SECURE_SSL_REDIRECT がFlyの平文HTTPのプローブに301で応え、すべてのマシンがチェックに失敗して、全員に503が返りました。8月には、ヘルス用ビューの except Exception を絞り込んだせいで “connection already closed” のエラーが500として漏れ、ビューのリトライがまさにそのケースのためにあったのに、Flyがマシンを外してしまいました。いまのチェックは、このプロセスがリクエストを処理できるかだけを問い、データベースが止まっても両アプリがルーティングから外れることはありません。

朝のサマリーも、数え方で同じ教訓を学びました。マーケットプレイスはアイドルのマシンをサスペンドするので、リクエストで起こされたマシンは起動後数百ミリ秒で最初のチェックに失敗し、次のチェックで通ります。それを数えていたせいで毎朝が障害のように読めたので、1分以内に再び通った失敗は、いまはマシンの復帰とデプロイとして別に表示しています。

CIの定期実行ジョブ

#

朝のサマリーは、cronで動くCIのワークフローとして始まり、1日で引っ越しました。アプリ解析と検索のデータを読むようになると、必要な鍵がアナリティクスのプロジェクトのサービスアカウントキーになったからです。そのプロジェクトで何でもできる鍵なので、CIのシークレットには置きたくありませんでした。いまは私のMacのスケジューラーが20分ごとに動かし、オークランド時間の朝8時を過ぎていて、その日の投稿がまだのときだけ投稿します。8時に眠っていたMacは、目を覚ましたときに投稿するわけです。ワークフローは、アプリ解析と検索のセクションを抜いた手動用の予備として残しています。

もう一度始めるなら

#

最初の障害のあとではなく、最初のユーザーが来る前に3つを用意します。チームがすでに読んでいるチャットチャンネルへのエラー通知(件数制限付き)、SQLで問い合わせられるオブジェクトストレージのログアーカイブ、そしてプラットフォームがすでに集めているメトリクス。月に数ドルで済みます。クラッシュレポートは、アプリがスマホに載る週に入れます。そうしないと、スマホで起きたクラッシュは誰にも何も伝えないからです。朝のサマリーは、確認する場所が増えすぎて、結局どこも確認しなくなりそうになったころに足せば十分です。

トレーシングは、リクエストがまたぐ2つめのサービスができるまで、ホスティング型のAPMは、共有ダッシュボードとオンコールの当番表、そして他社の請求書を払う予算が必要なチームができるまで待ちます。昨年の記事で紹介したツールが元を取り始めるのはそこからです。それまでのいちばん役に立つ習慣はタダです。数字が怖く見えたら、何が壊れたかを決める前に、その数字を何が生み出したのかを確かめること。この記事に出てきた騒ぎのいくつかは、プロダクトではなくモニタリングそのものから生まれていました。

「手元では動く」と「本番で動く」の間にはギャップがあって、モニタリングはそれを埋めるためにあるはずです。ところが大抵は埋まりません。開発者が障害時に手を伸ばすツールとしてではなく、運用チーム向けのツールとして作られてしまうからです。

最近フリーランスとして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の比較

#

ゼロから始めるなら：モニタリング構築の手順

#

私ならこの順番でやります。

1. まず開発者に、インシデント中に何がつらいかを聞く。
2. 重要なフローのSLOを定義する。ログイン、チェックアウト、検索にとって「動いている」とは何か。
3. そのクリティカルパスから計装する。
4. 次に分散トレーシングを入れる（マイクロサービス構成ではデバッグ効率への投資対効果が一番高い）。
5. アラートはCPUではなくそのフローに設定し、それぞれ担当チームに届くようにする。
6. すべてのアラートにランブックを書き、午前3時の自分が何を確認すべきか分かるようにする。
7. 四半期ごとのレビューをカレンダーに入れ、古いアラートを消し、ずれた閾値を直し、ダッシュボードが今のアーキテクチャを反映しているか確認する。

私がこれまで何度もチームを救い出してきた落とし穴も挙げておきます。ツールの入れすぎ（連携する3つは連携しない6つに勝る）。ベースラインのないグラフ（500 rpsは平常なのか10倍のスパイクなのか？）。ユーザーに関係ないものの監視（ステートレスなコンテナのディスクI/Oなど）。そしてモニタリング自体の冗長性の欠如。インシデントの最中にアラート基盤が落ちたら、一番見えなくてはいけない瞬間に何も見えなくなります。

どれも最高級のツールは必要ありません。必要なのは、開発者が必要な情報を、実際に見る場所で、素早く手にできることです。