インフラストラクチャ一括カバレッジにより、サーバー、コンテナ、その他のインフラストラクチャ コンポーネントに監視アラートが設定され、問題がアプリケーションや顧客に影響を与える前に検出されます。
このスコアカードルールについて
このインフラストラクチャ一括適用ルールは、ビジネス稼働時間成熟度モデルのレベル 1 (リアクティブ) の一部です。 重要なインフラストラクチャ コンポーネントに、問題が発生したときに通知するための基本的なアラートが設定されていることを確認します。
これが重要である理由:インフラストラクチャの問題は、多くの場合、アプリケーションの問題に連鎖します。適切なインフラストラクチャアラートがなければ、サービスが遅い、または利用できないと顧客が苦情を言い始めたときに初めて問題が発見される可能性があります。
このルールの仕組み
このルールは、インフラストラクチャ エンティティを調べて、アラート条件が定義されているかどうかを確認します。具体的には、次のアラートを探します。
- INFRA-HOST エンティティ:物理サーバー、仮想マシン、 cloudインスタンス
- INFRA- Kubernetesエンティティ: Kubernetesとコンテナ
いずれかのモニターインフラストラクチャエンティティに少なくとも 1 つのアラート条件が欠けている場合、ルールは失敗します。
スコアを理解する
- 合格（緑）：すべてのインフラストラクチャエンティティに少なくとも1つのアラート条件が定義されている
- 不合格 (赤): 1 つ以上のインフラストラクチャ エンティティの包括的カバレッジが不足しています
- 目標:すべての重要なインフラストラクチャ コンポーネント全体を 100% 一括カバー
これが意味するもの:
- 合格スコア:インフラストラクチャ監視基盤が整備されている
- 不合格スコア:一部のインフラストラクチャコンポーネントがチームに警告されずに故障する可能性があります
インフラストラクチャの網羅範囲をどう改善するか
スコアにインフラストラクチャ アラートが欠落していることが示されている場合は、次の手順に従って包括的なカバレッジを確立してください。
1. カバーされていないインフラストラクチャを特定する
- 失敗したエンティティを確認します。包括的なカバレッジが不足している特定のホストまたはポッドを特定します。
- 重要度による優先順位付け:最初に本番システムとビジネスに不可欠なインフラストラクチャに焦点を当てます
- 監視ギャップを評価する:欠落したアラートが実際の監視ギャップを表しているかどうか、または意図的な除外を表しているかどうかを判断します。
2. 重要なインフラストラクチャ アラートをセットアップする
インフラストラクチャ エンティティごとに、次の重要なメトリクスのアラートを構成します。
ホスト監視アラート:
- CPU使用率:集計 CPU使用率が5分間80%を超えた場合
- メモリ使用量:メモリ使用率が 5 分間 85% を超えた場合の集計
- ディスク容量:ディスク使用率が90%を超えるか、使用可能な容量が1GBを下回ったときに集計
- ホストの可用性:ホストが3分間データの報告を停止したときの集計
Kubernetes ポッドアラート:
- ポッド再起動頻度： 10分間に3回以上ポッド再起動した場合の集計
- コンテナのリソース制限:コンテナが CPU またはメモリの制限に近づいた場合の分割
- ポッドの可用性:ポッドが 2 分以上実行状態にない場合に集計
- ノードのリソース圧力:ノードでメモリまたはディスクの圧力が発生したときの回数
3. アラート条件を効果的に設定
適切な閾値を使用してください。
- 保守的な閾値から始めて、環境の通常の動作に基づいて調整します
- 開発、ステージング、本番環境ごとに異なる閾値を考慮する
- 予想される使用パターンを考慮する（例：バッチ処理ジョブ、トラフィックの急増）
適切な評価ウィンドウを設定します。
- 自然に変動するメトリクスには長いウィンドウ (5 ～ 10 分) を使用します
- 可用性と重大な障害条件には、より短いウィンドウ（1～3 分）を使用します。
- 一時的な急上昇でトリガーされる過度に敏感なアラートを避ける
4.一括ルーティングとエスカレーションを確立する
- 通知チャネルの定義:電子メール、Slack、またはPagerDutyインテグレーションを設定する
- 担当チームの割り当て:アラートが対応できるチームに届くようにする
- エスカレーション手順の作成:最初のアラートが確認されない場合に何が起こるかを定義する
- 通知の配信テスト:アラートが実際に対象の受信者に届くか確認する
改善の測定
これらのメトリクスを追跡して、インフラストラクチャ全体のカバレッジの改善を検証します。
- カバレッジ率: AIモニタリングによる生産インフラストラクチャの網羅率100%
- まとめた有効性:インフラストラクチャ アラートがアプリケーションの問題を防止する頻度を監視する
- 応答タイム:チームがインフラストラクチャ アラートにどれだけ早く応答するかを測定します
- 誤検知率:不要なノイズを避けるためにアラートが調整されていることを確認する
一般的なシナリオと解決策
レガシーまたは廃止されたインフラストラクチャ:
- 問題:古いホストやコンテナがまだ監視に表示されるが、アラートは不要
- 解決策:使用されていないエンティティを監視から削除するか、非本番環境としてタグ付けしてカバレッジ要件から除外します。
開発およびテスト環境:
- 問題:開発/テストインフラストラクチャが乱雑になる 集計カバレッジ メトリクス
- 解決策:タグまたは命名規則を使用して環境を分離し、カバレッジルールを本番システムに集中させる
特殊なインフラストラクチャ:
- 問題:一部のインフラストラクチャではカスタム監視アプローチが必要
- 解決策:さまざまなインフラストラクチャ タイプ (データベース、ロード バランサーなど) に対して環境固有の一括テンプレートを作成します。
クラウド自動スケーリングリソース:
- 問題:動的に作成されたインスタンスが累計設定を継承しない可能性がある
- 解決策:インフラストラクチャ テンプレートまたは自動化を使用して、新しいインスタンスが適切に網羅されるようにします。
高度な考慮事項
カバレッジルールのカスタマイズ
次の場合には、スコアカード ルールを調整する必要があります。
- さまざまなエンティティ タイプ:インフラストラクチャには、他のエンティティ タイプ (データベース、ロード バランサなど) が含まれます。
- 環境の分離:本番環境のインフラストラクチャのみに焦点を当てたい
- ビジネスの重要性:一部のインフラストラクチャは他のインフラストラクチャよりも重要です
他の監視ツールとの統合
複数の監視ツールを使用する場合:
- 一括報道により重複した通知が作成されないようにする
- 既存の監視システムと連携してギャップを回避する
- インフラストラクチャアラートの中央集約ポイントとしてNew Relicの使用を検討してください
重要な考慮事項
- 重要なシステムから始める:顧客に直接影響を与える本番環境のインフラストラクチャに最初に焦点を合わせます。
- カバー範囲とノイズのバランスをとる:包括的なカバー範囲がアラート疲れを招かないようにする
- 定期的なメンテナンス:インフラストラクチャの進化に合わせてアラート条件を確認し更新します
- チームの準備:チームが作成するアラートに実際に対応できることを確認する
次のステップ
- 即時の対応:現在カバーされていないインフラストラクチャに対して基本的なアラートを設定する
- 継続的な監視:インフラストラクチャの変更に応じてカバレッジを維持するために、このスコアカードのルールを毎週確認します。
- レベル2に進む:インフラストラクチャのアラートが確立されたら、 プロアクティブな監視プラクティスに重点を置きます。
インフラストラクチャ モニタリングのセットアップに関する詳細なガイダンスについては、 インフラストラクチャ モニタリングのドキュメントを参照してください。