Elevate 2026開催まであとわずか。シカゴ、ロンドン、シドニーのいずれかでお会いしましょう。

Register here

Partners

ドキュメント

LMアカデミー

LMコミュニティ

価格

Platform
解決策
業種
職種
結果はありません。
無料トライアル

14日間フルアクセス LogicMonitor プラットフォーム

Elevate 2026開催まであとわずか。シカゴ、ロンドン、シドニーのいずれかでお会いしましょう。

Register here

ロジックモニターブログ

静的しきい値と動的しきい値: IT 監視にはどちらが適していますか?

静的しきい値と動的しきい値の両方の長所と短所、およびそれらを使用するのが最も理にかなっている場合についての詳細をご覧ください。

7〜10分

ニュースレター

最新情報のメール配信を登録

最新のブログ、ホワイトペーパー、電子ガイドなどを直接受信ボックスにお届けします。

シェア

IT 監視は、監視とアラートを管理する複数のアプローチがある複雑な分野です。現在の監視ソリューションのほとんどは、静的しきい値ベースのアラートを提供し、リソース使用率が定義されたしきい値を超えると IT 運用スタッフに通知されます。静的しきい値の問題は、これらが手動で調整され、組織の特定の環境とニーズに合わせて調整することが IT 運用チームにとって大きな課題であることです。

一方、動的しきい値は、より適応的なアプローチを提供し、リアルタイムのデータ収集に基づいてしきい値を自動的に調整し、不要なアラートのノイズを削減します。ただし、これは万能のソリューションではなく、すべてのシナリオで常に最適なオプションであるとは限りません。

この記事では、静的しきい値と動的しきい値の両方の長所と短所を検討し、監視ニーズに最適なタイミングでそれぞれを使用する方法について説明します。

主要な取り組み

動的しきい値は、リアルタイムデータに基づいて自動的に調整することで、監視に対するより適応的なアプローチを提供し、不要なアラートを減らします。
静的な閾値は実装が簡単ですが、変化する状況への適応性がないため、アラート疲れにつながる可能性があります。
静的しきい値と動的しきい値のどちらを選択するかは、ワークロードの予測可能性やメトリックの重要性など、環境の特定のニーズによって異なります。
LogicMonitorのアプローチは、動的なしきい値設定と機械学習を組み合わせて、誤検知を最小限に抑え、実用的なアラートを最大化し、プロバイダーのIT運用を合理化します。

動的しきい値を選択する場合

さまざまな閾値の必要性を理解する

パフォーマンスカウンタの適切なしきい値を特定するのは簡単なことではありません。さらに、チューニングはアプリケーションの柔軟性を制限します。これは、異なるアプリケーションを実行しているサーバーであっても、多くのサーバーで同じしきい値が使用されることを意味します。たとえば、忙しいサーバーのCPU使用率が70%であれば正常であり、アラームを生成する必要はありませんが、比較的使用率の低いサーバーでは、50%でもアラームを生成する必要はありません。 CPU 使用率が低いということは、何か問題があることを意味している可能性があります。また、同じ資産 (サーバーやファイアウォールなど) であっても、負荷が異なるという理由だけで、時間帯や曜日によってパフォーマンスが異なることがあります。

私のお気に入りの例は、Active Directoryサーバーです。これは通常、ユーザーがログインする朝の時間帯に大量のトラフィックを引き付けますが、週末を含む営業時間外は静かになります。 信頼できる静的しきい値を設定することは、負荷が一定ではなく、季節的な特性を示す環境では常に課題です。

動的しきい値はリアルタイムで適応し、アラートのノイズを排除して、ダッシュボードで本当に重要なことに集中できるようにします。

アラート疲労の管理: 動的しきい値がどのように役立つか

しきい値を手動で調整するには時間がかかり、完全に達成されるまで、実際の問題は監視ソリューションによって警告されません。 監視ソリューションは、多くの誤検知を報告し、IT運用チームのメールボックスを誤警報で溢れさせる可能性があります。 誤検知のノイズによって引き起こされる注意深い疲労は、真の検知を見逃すリスクを高めます。

動的しきい値はリアルタイムデータに適応するだけでなく、より多くのことを可能にします プロアクティブな問題と異常検出これにより、IT チームは潜在的な問題が深刻化する前に対処できるようになります。

動的しきい値による周期的変動の処理

静的しきい値も、周期的な変動ではあまり良くありません。 パフォーマンスカウンターには通常の週次および月次の変動があり、ビジネスのニーズに応じて許容されますが、特定の期間に異なるしきい値を手動で維持するには時間がかかり、誤警報が発生しやすくなります。

静的しきい値を使用する場合

スマートモニタリングソリューションは、メトリックのパターンを分析し、環境内で何が正常であるかを学習し、物事（メトリックの読み取り）がすでに確立された正常外にある場合にのみアラートを生成します。 これらのソリューションは、周期的な変動を認識する必要があり、さまざまな周期でのメトリックのパターンの変化に対応する必要があります。 チューニングは自動で行われるため、面倒な作業は少なくなります。 インフラストラクチャ監視ツール パターンを視覚化し、しきい値を自動的に作成するのに役立つツールは、手動で調整する必要があるツールよりも時間がかかりません。

そうは言っても、静的しきい値を使用する方が理にかなっているシナリオがいくつかあります。たとえば、メトリック値が以前の値から変化したことを通知したい場合、つまりデルタの場合です。この場合、動的しきい値は連続した値の変化率ではなくデータストリームに対して機能するため、静的しきい値を使用するのが最適です。さらに、次のようなステータス値に動的しきい値を使用すると、 API レスポンス (200、202、404 など) コード 応答コードは数値ではないため役に立ちません。また、応答コードに基づいて生成される信頼区間は誤解を招く可能性があります。

静的しきい値はシンプルですが、動的な環境では無関係なアラートによって IT チームを圧倒する可能性があります。

LogicMonitor が動的しきい値を使用してアラートノイズを削減する方法

IT 監視チームが静的しきい値で経験する最も顕著な問題は、アラートの氾濫と、大量のノイズの中から本当に役に立ち、実用的なものを理解できることです。LogicMonitor は、最初のフェーズでアラート ノイズを削減することで、段階的にこの問題を解決しました。メトリックのパターンを分析し、動的しきい値を生成し、これらのしきい値を利用してアラート ノイズを削減するシステムを構築しました。静的しきい値が適切に設定されていない場合 (または既定の設定から継承されている場合)、監視ソリューションは無数のアラートを生成しますが、そのほとんどは役に立ちません。現在、このアラート ノイズを阻止するために、高度な機械学習アルゴリズムによって生成される信頼帯 (動的しきい値とも呼ばれます) を使用しています。アラートがトリガーされ、値が信頼帯内に収まると、システムはそのアラートをルーティングしません。アラートは効果的に抑制されます。

このアラート削減機能を実現するために、2 つの独立したコンポーネントを使用しています。1 つは、定期的に信頼帯を生成するアルゴリズム中心のサービスであり、もう 1 つは、この信頼帯を使用して、アラートをルーティングするかどうかを決定する高度なアラート システムです。

顧客インフラストラクチャとLogicMonitorシステム間の高レベルのアーキテクチャグラフ

このアラート抑制機能は、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チームは、顧客により多くの価値を提供し、静的しきい値を手動で調整するために費やされる無数の時間を削減するシステムを構築しました。 今後もこの機能と信頼帯ジェネレーターシステムを強化し、お客様により多くの価値を提供していきます。

動的しきい値の実装: ステップバイステップガイド

動的しきい値を実装すると、IT監視を大幅に強化できます。 騒音を減らす 意味のあるアラートに焦点を当てます。動的しきい値を効果的に実装するためのステップバイステップのガイドを以下に示します。

ステップ1: 初期設定

まず、環境にとって重要な主要なパフォーマンス メトリックを特定します。これには、CPU 使用率、メモリ使用量、ネットワーク レイテンシ、および通常はワークロードに応じて変化するその他のパフォーマンス インジケーターが含まれます。監視ソリューションを構成して、これらのメトリックのデータ ソースを継続的に収集および分析します。

ステップ2: 履歴データを活用する

動的しきい値は、通常の動作のパターンを確立するために履歴データに依存します。周期的な変動を捉えるには、週や月など、さまざまな期間にわたる履歴データを使用します。たとえば、日次、週次、季節ごとの傾向を分析して、確実なベースラインを設定します。このベースラインは、さまざまなサイクルで観察される典型的な動作に応じてシステムがしきい値を自動的に調整するために不可欠です。

ステップ3: 閾値感度を微調整する

すべてのアラートが同じように作成されるわけではありません。各メトリックの重要度に合わせて、動的しきい値の感度を調整します。たとえば、逸脱がすぐにサービスに影響する可能性があるメトリックには厳しいしきい値を設定し、それほど重要でないメトリックには緩いしきい値を設定します。スライディング ウィンドウ パターンを使用して、最近のデータ ポイントでのメトリックの逸脱を評価すると、システムはリアルタイムの変更に迅速に対応しながら、小さな変動に対する過剰反応を回避できます。

ステップ4: 既存の監視システムとの統合

動的しきい値設定が既存の IT 監視ツールとシームレスに統合されていることを確認します。これには、監視ソリューションにデータを供給するための API、プラグイン、またはその他のコネクタの構成が含まれる場合があります。動的しきい値から生成されたアラートが静的しきい値またはその他の監視ルールからのアラートと並んで表示され、対処できるように、監視環境を統一しておくことが重要です。

ステップ5: 継続的な監視と調整

動的しきい値は、設定して忘れるソリューションではありません。動的しきい値のパフォーマンスを継続的に監視し、環境の変化に応じて調整してください。アラートとしきい値の計算を定期的に確認して、現在の運用パターンが反映されていることを確認してください。アラートと応答を使用してシステムをさらに微調整し、時間の経過とともに精度を高めるフィードバック ループを実装します。

LogicMonitorで次のステップへ

アラート ノイズを削減し、動的なしきい値を使用して IT 監視を改善する準備はできていますか? LogicMonitor の AIOps 早期警告システムが、インシデント管理を合理化し、パフォーマンスを最適化するのにどのように役立つかをご覧ください。 

© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。

関連ブログ

可観測性ROI：実際の導入による真のコスト削減
Blog

可観測性ROI：実際の導入による真のコスト削減

可観測性を高めることで、アラートのノイズを減らし、インシデント対応を迅速化し、ダウンタイムを削減し、エンジニアが計画的な作業に費やす時間を増やすことができます。LogicMonitorの顧客は、これらのメリットを活用してコストを削減し、より適切なインフラストラクチャの意思決定を行っています。
2026 年 9 月 9 日
さらに詳しく
HTTPSは中間者攻撃への解決策となるのか？
Blog

HTTPSは中間者攻撃への解決策となるのか？

合成監視によって隠れたHTTPリダイレクト攻撃がどのように明らかになったか、そしてHTTPS、HSTS、配信経路の可視化がユーザーを傍受から守る理由をご覧ください。
2026 年 9 月 9 日
さらに詳しく
古いDNSグルーレコード：親レコードと権威レコードの不一致を診断する方法
Blog

古いDNSグルーレコード：親レコードと権威レコードの不一致を診断する方法

権威サーバーは正しいIPアドレスを返しているにもかかわらず、ユーザーが古いIPアドレスにアクセスしてしまうケースがあります。ここでは、古いグルーレコードを見つけて、親ゾーンのリファラルを修正する方法をご紹介します。
2026 年 9 月 9 日
さらに詳しく