IT監視は、監視とアラートを管理するためのいくつかのアプローチを備えた複雑な分野です。 現在の監視ソリューションのほとんどは、静的しきい値ベースのアラートを提供します。このアラートでは、リソース使用率が定義されたしきい値に違反したときにIT運用スタッフに通知されます。 静的しきい値の問題は、これらが手動で調整されることであり、組織の特定の環境とニーズに合わせて調整することは、IT運用チームにとって大きな課題です。 動的しきい値は、ノイズの多い不要なアラートを減らしますが、常に最適なオプションであるとは限らないシナリオがあります。 静的しきい値と動的しきい値の両方の長所と短所、およびそれらを使用するのが最も理にかなっている場合については、読み続けてください。
動的しきい値を使用する必要がある場合
さまざまなしきい値があります
パフォーマンスカウンターの適切なしきい値を特定するのは簡単な作業ではありません。 さらに、チューニングによってアプリケーションの柔軟性も制限されます。 これは事実上、サーバーが異なるアプリケーションを実行しているにもかかわらず、多くのサーバーで同じしきい値が使用されることを意味します。 たとえば、ビジー状態のサーバーの70％のCPU使用率は正常であり、アラームを生成する必要はありませんが、比較的使用率の低いサーバーの場合、50％のCPU使用率でも何かが間違っている可能性があります。 また、同じ資産（サーバーやファイアウォールなど）は、負荷が異なるという理由だけで、XNUMX日の異なる時間帯または曜日ごとに同じパフォーマンスを示すことはありません。
私のお気に入りの例は、Active Directoryサーバーです。これは通常、ユーザーがログインする朝の時間帯に大量のトラフィックを引き付けますが、週末を含む営業時間外は静かになります。 信頼できる静的しきい値を設定することは、負荷が一定ではなく、季節的な特性を示す環境では常に課題です。
アラートデリュージ
しきい値を手動で調整するには時間がかかり、完全に達成されるまで、実際の問題は監視ソリューションによって警告されません。 監視ソリューションは、多くの誤検知を報告し、IT運用チームのメールボックスを誤警報で溢れさせる可能性があります。 誤検知のノイズによって引き起こされる注意深い疲労は、真の検知を見逃すリスクを高めます。
周期的変動
静的しきい値も、周期的な変動ではあまり良くありません。 パフォーマンスカウンターには通常の週次および月次の変動があり、ビジネスのニーズに応じて許容されますが、特定の期間に異なるしきい値を手動で維持するには時間がかかり、誤警報が発生しやすくなります。
静的しきい値を使用する必要がある場合
スマートモニタリングソリューションは、メトリックのパターンを分析し、環境内で何が正常であるかを学習し、物事（メトリックの読み取り）がすでに確立された正常外にある場合にのみアラートを生成します。 これらのソリューションは、周期的な変動を認識する必要があり、さまざまな周期でのメトリックのパターンの変化に対応する必要があります。 チューニングは自動で行われるため、面倒な作業は少なくなります。 インフラストラクチャ監視ツール パターンを視覚化し、しきい値を自動的に作成するのに役立つものは、手動で調整する必要があるものよりも時間がかかりません。
そうは言っても、静的しきい値を使用する方が理にかなっているシナリオがいくつかあります。 たとえば、メトリック値が以前の値から変更されたこと、つまりデルタで通知を受けたい場合です。 この場合、動的しきい値は連続する値の変化率ではなくデータストリームで機能するため、静的しきい値を使用するのが最適です。 さらに、API応答（200、202、404など）コードなどのステータス値に動的しきい値を使用することは、応答コードが数値ではなく、これらで生成される信頼区間が誤解を招く可能性があるため、役に立ちません。
LogicMonitorのアプローチ
IT監視チームが静的しきい値で経験する最も顕著な問題は、アラートの洪水と、豊富なノイズから本当に有用で実行可能なものを理解できることです。 LogicMonitorは、この問題を最初のフェーズで段階的に解決し、アラートノイズを低減しました。 メトリックのパターンを分析し、動的しきい値を生成し、これらのしきい値を活用してアラートノイズを低減するシステムを構築しました。 静的しきい値の設定が不十分な場合（またはデフォルト設定から継承されている場合）、監視ソリューションは無数のアラートを生成し、それらのほとんどは役に立たなくなります。 現在、このアラートノイズを停止するために、高度な機械学習アルゴリズム、別名動的しきい値によって生成された信頼帯を使用しています。 アラートがトリガーされ、値が信頼範囲内にある場合、システムはそのアラートをルーティングしません。 アラートは効果的に抑制されます。
このアラート削減機能を実現するために、XNUMXつの独立したコンポーネントを使用します。XNUMXつは一定の間隔で信頼帯を生成するアルゴリズム中心のサービスであり、もうXNUMXつはこの信頼帯を消費し、これに基づいてアラートをルーティングするかどうかを決定する高度なアラートシステムです。か否か。
このアラート抑制機能は、2019年1月にお客様にリリースされました。 抑制、フェーズ2は約 生成 MLアルゴリズムによって生成されたバンドを利用してアラートを送信します。 フェーズ2では、動的しきい値を定義し、この定義に基づいてアラートを生成する機能を導入します。 これにより、ユーザーは定量化することでアラートの重大度を調整する強力な機能を利用できます。 現在の読み取り値がどの程度逸脱しているか MLアルゴリズムによって識別された通常またはベースラインから。
アラート抑制とアラート生成を組み合わせると、誤検知が最小化され、真陽性が最大化されます。 LogicMonitorユーザーは、両方の長所を活用できます。設定が不十分な静的しきい値に基づいて生成されたアラートが抑制され、ノイズが減少します。メトリック値がしきい値を超えると、動的しきい値ベースのアラートエンジンがアラートを生成します。 動的しきい値を定義するための高度なユーザーインターフェイスを構築し、これらの設定の調整に役立つ視覚的な支援も提供しています。
ユーザーは、最後の60回のポーリングの値のXNUMX％が上位からXNUMXバンドずれたときに、警告アラートを生成することを選択できます。
例：
コンフィデンスバンド： （低：20、高：60、中：40）
HighBand： （高–中）：20
LowBand :(中–低）：20
したがって、最後のXNUMX回の投票の場合、値は次のようになります。 65、82、81、70、84。 ここで、82,81,84つの値[60]（60％）は高値（XNUMX）からXNUMXバンド離れており、エンジンは警告アラートをトリガーします。
Alert Engineは、最後のものを考慮して、スライディングウィンドウパターンで動作します 投票数 各評価の値。
ユーザーは、次の画像に表示されているインタラクティブチャートを使用して、動的しきい値の定義を調整できます。
LogicMonitorは、アラートワークスペースも強化しました。動的しきい値を使用して生成された各アラートには、追加情報を含む信頼帯グラフが付属します。 このグラフは、電子メール通知でも送信されます。
この機能により、LogicMonitorのAIOpsチームは、顧客により多くの価値を提供し、静的しきい値を手動で調整するために費やされる無数の時間を削減するシステムを構築しました。 今後もこの機能と信頼帯ジェネレーターシステムを強化し、お客様により多くの価値を提供していきます。 さらに詳しく LogicMonitorのAIOps早期警告システムについて、または デモ.
