かつて私は47個のダッシュボードパネルがあるGrafanaインスタンスを引き継いだことがあります。CPU使用率、メモリ使用量、ディスクI/O、ネットワークバイト数、JVMヒープ — 想像できるあらゆるメトリクスが揃っていました。すべてが緑色。常に。
その2日後、APIが4時間にわたってダウンしました。アラートは一つも発報しませんでした。
なぜか？ CPUは22%、メモリは45%、ディスクは30%。すべて「健全」でした。実際の問題はコネクションプールの枯渇 — 誰も監視していなかったメトリクスでした。
四つの黄金信号（それ以外は不要）
GoogleのSRE本がこれを的確に示しています。必要なのは正確に四つの信号だけです。
1. レイテンシ — リクエストにどれだけ時間がかかるか？ 平均レイテンシではありません — それは問題を隠します。P50、P95、P99を追跡しましょう：
- P50 = 200ms は、ユーザーの半数が200msで応答を得ていることを意味します（良好）
- P95 = 800ms は、20人に1人のユーザーが800ms待つことを意味します（許容範囲）
- P99 = 5000ms は、100人に1人のユーザーが5秒待つことを意味します（問題）
P99こそが実際のパフォーマンスです。平均値は嘘をつきます。
2. トラフィック — どれだけのリクエストを処理しているか？ これがベースラインです。火曜日の午後2時にトラフィックが80%低下した場合、他のすべてのメトリクスが緑色でも何かがおかしいのです。
3. エラー — リクエストのうち何パーセントが失敗するか？ エラー数ではなく、エラー率を追跡しましょう。100万リクエスト中100件のエラー（0.01%）は問題ありません。200リクエスト中100件のエラー（50%）は障害です。
4. 飽和度 — システムはどの程度満杯か？ データベース接続、メモリ、キュー深度、スレッドプール。いずれかのリソースが使用率80%に達したら、行動を起こす必要があります — 壊れているからではなく、余裕を失っているからです。
私の実際のモニタリング設定
Nexuralプラットフォームの場合：
\\
