使用していない最も重要な監視レポート

LogicMonitorのベストプラクティスブログ

優れた監視システムを使用しても、ノイズを抑えることが難しい場合があります。 (実際、監視が強力であるほど、より多くのデータが自動的に収集およびテストされるため、これは困難になる可能性があります。)また、スタッフがアラートを無視し始めたくないため、監視でノイズを抑えることが重要です。意味のないアラートが多すぎる場合。

もちろん、このプロセスに役立つベストプラクティスはありますが、アラートノイズの攻撃を開始するための最良の方法のXNUMXつは、最も簡単な方法のXNUMXつでもあります。ノイズの発生源を強調するレポートを設定し、一度確認するだけです。週間。

[レポート]タブで、[追加]、[レポート]の順に選択します。 事前に作成されたレポートテンプレートの表が表示されます。このテンプレートから[アラート]を選択し、以下に示すように入力する必要があります。

Picture1

Picture1

すべてのホストについて、先週をカバーするようにレポートを設定することをお勧めします(ただし、一連のホストのみを担当する場合は、アラートが発生したホストのみを反映するようにレポートを変更してください)。 スケジュールされたダウンタイムの期間中に発生したアラートを除外します(これらのアラートはとにかく送信されませんでした)。 [アラート数の要約]チェックボックスをオンにしてから、アラート数で並べ替える並べ替え方法を選択します。 (このソート順は、アラートカウントの要約ボックスがチェックされるまで使用できません。)

このレポートを実行すると、次のような出力が得られます。

fc9c8af0-6033-4522-a4d7-445163533b03

これにより、この場合、80つの開発ホストのIPMIイベントログの監視を変更するだけで、先週のアラートのXNUMX%を排除できることが非常に簡単にわかります。アラートを除外するか、SDTを使用するか、無効にすることもできます。それが単なる開発ホストであることを考えると、その監視。

次に、トップのノイズメーカーを処理し、問題を調整、無効化、または修正します。これにより、最小限の作業でアラートノイズの量を大幅に減らすことができます。

そして、毎週月曜日にこのレポートがメールで送信されるので、問題を常に把握し、監視を有意義なものに保つことができます。 そうすることで、システムのパフォーマンスが向上し、アラートノイズが排除されます。アラートが発生した場合でも、それが意味のあるものであり、人々がそれに反応することを確信できます。

スティーブ·フランシス

創業者

スティーブはLogicMonitorの創設者です。

LogicBlogを購読して、LogicMonitorの最新の開発に関する最新情報を入手し、ITエキスパートとエンジニアのワールドクラスのチーム、およびITプロフェッショナルが愛する製品。

LogicBlogの他の記事

アンペアロボット 影

お店の話をしましょう。

STARTED GET