リソース使用率ではなくユーザーレビュー性能やエラーレートに基づくアラートの重要性を解説。
午前3時15分。電話が高優先度のPagerDutyインシデントで振動します：クリティカル：APIサーバーCPU使用率 > 95%。ラップトップを開き、Grafanaダッシュボードを引き上げると、CPUが4分間大幅にスパイクした一方で、HTTP 500エラー率は0%のままで、APIレイテンシーは完全にフラットだったことに気づきます。
アラートを確認し、深くため息をついて、もう一度眠ります。ひどいアラートの教科書的な定義を経験しました。
数十年にわたり、インフラストラクチャ監視はCPUやメモリなどの使用率メトリクスに大きく依存してきました。しかし、コンテナ化されたマイクロサービスとオートスケーリングクラウドインフラストラクチャの時代には、リソース消費に対するアラートはアンチパターンです。この記事ではその理由を探ります。
なぜまだCPU閾値アラートを設定するのかを理解するために、ベアメタルサーバーの時代を振り返る必要があります。ラックに単一のデータベースサーバーがあった時、CPUが99%に達することは、マシンの計算ヘッドルームがゼロになることを意味しました。トラフィックがわずかでも増加すれば、サーバーは必然的にクラッシュします。
モダンなクラウドアーキテクチャは異なります。リソース使用率を最大化してクラウドコンピューティングコストを削減するために、オートスケーリンググループを明示的にデプロイします。ノードが常にCPU 40%で動作している場合、オーバープロビジョニングされています。実際には、ノードが限界に近いところで効率的に動作し、水平スケーリングがオーバーフローを処理することを 望んでいます。
オーケストレーション層が流入を処理するとき、高いCPUは健全でコスト効果の高いシステムのサイン——緊急事態ではありません。
アラートを設計する際、問題の 原因とユーザーが体験する 症状を区別する必要があります。
高いメモリスパイクは 原因（または基礎となる状態）です。502 Bad Gatewayを受け取るユーザーは 症状（実際の痛み）です。
バックグラウンドcronジョブが大きなファイルを解析しながら2分間ノードのCPUの100%を消費するが、専用のバックグラウンドワーカーキューで実行される場合、ユーザーはパフォーマンスの低下をまったく経験しません。これのためにエンジニアをページングすることは純粋なノイズを生み出します。
逆に、データベースのデッドロックはデータベースのCPUの5%しか消費しないかもしれませんが、すべてのユーザートランザクションを停止させます。CPUでのみアラートを出す場合、重大な障害を完全に見逃すことになります。
リソース使用率スパイクが偽陽性を引き起こす3つの一般的なシナリオを検討しましょう：
JavaやGoなどの言語では、GCポーズでクリーンアップされる前にオブジェクトが割り当てられるため、断続的なメモリスパイクが予想されます。これらののこぎり歯状波形に基づいてメモリアラートをトリガーすることは、非常に不安定であることで知られています。
毎晩のデータベースバックアップやログローテーションは、当然激しいディスクI/OとCPUを必要とします。主要なアプリケーション機能を妨げない限り、アラートを必要としません。
接続の突然の流入は、TLSハンドシェイクが交渉され、接続プールがウォームアップされる際にCPUを即座に圧迫します。アプリケーションが数分以内に効果的にオートスケールする限り、短い飽和は標準的な操作手順です。
ページャーアラートは「ゴールデンシグナル」（レイテンシー、トラフィック、エラー、飽和）にのみ予約されるべきです。
代わりに：CPU > 90%
アラートを出す：P99レイテンシー > 1500ms（5分間）
CPUが99%に達しても、レイテンシーが1500msの閾値を安全に下回っている場合、チームを眠らせましょう。
代わりに：メモリ > 85%
アラートを出す：HTTP 5xxエラー率 > 2%
メモリリークが最終的にPodの再起動を引き起こし、ドロップされたリクエストにつながる場合、5xxエラー率アラートが症状を捉え、チームを正確にページングします。
CPUとメモリのメトリクスは役に立たないわけではありません——単に ページャーに値しないだけです。
これらのメトリクスは2つの場所に属します：
インフラストラクチャの健全性を中心にオンコールスケジュールを作成することをやめてください。ユーザーの健全性を中心に構築してください。生のハードウェア閾値を排除し、症状ベースのレイテンシーとエラーアラートにコミットすることで、エンジニアは疲労が少なくなり、実際に発火するアラートを信頼するようになります。
移行には信頼性の高い外部テレメトリが必要です。Heimdallのようなプラットフォームはユーザーが体験することを正確に監視し——実際のHTTPレイテンシーと実際のDNS解決能力に基づいてアラートを適用し——チームがクラスター内のノイズの多いCPU閾値ルールを安全にオフにできるようにします。
可用性、インシデント対応、そしてユーザーが気づく前に問題を表面化させるモニタリングシステムの構築に焦点を当てた、シニアシステム信頼性エンジニア（SRE）。
