LogicMonitor + Catchpoint: 自律型ITの新時代へ

さらに詳しく

問題を特定する

アラートの解決と対応を行う前に、まずアラートの原因となっている問題を特定する必要があります。アラートは必ずしも全体像を示すものではありません。アラートは、アラートを生成したコンポーネントについて、さらなる調査が必要であることを示す指標として活用する必要があります。

アラートの調査を開始するのに最適な場所はダッシュボードです。 ダッシュボードが戦略的に設定されていると仮定すると、ダッシュボードは根本原因をすばやく特定するのに役立ちます。

アラートに対応するための戦略

アラートへの対応方法はいくつかあります。対応方法は個人の好みによって異なりますが、問題を解決できるかどうかに応じて、どのような対応をすべきかについてのガイドラインがあります。

LogicMonitorは、XNUMXつの応答タイプをサポートします。 それぞれを適切に使用するためのガイドラインについては、次のセクションで説明します。

アラートの確認

アラートの確認応答により、そのアラートに関する今後の通知ルーティングが抑制されます。問題を解決できると判断した場合は、アラートを確認応答する必要があります。問題の解決には、問題の原因となっているものを修正し、必要に応じてアラートが再発しないようにするための措置を講じることが含まれます。今後のアラートを抑制するための措置には、以下のものがあります。

  • アラートしきい値を調整します。詳細については、 データポイントの静的しきい値.
  • アラートを無効にする。詳細については、 アラート生成を無効にする.
  • 次のセクションで説明するダウンタイムをスケジュールして、予想される定期的なメンテナンスの期間をカバーします。
  • アラートを発生させているデータソースインスタンスを検出対象から除外するか、クローン化されたデータソースを作成して、異なるアラートしきい値で検出/分類します。Linuxホスト上のNFSマウントされたファイルシステムなど、検出対象から除外してはならないインスタンス群がある場合や、ロードバランサー上のQA VIPなど、他のインスタンスとは異なるしきい値を設定する必要があるインスタンス群がある場合は、アクティブ検出フィルタリングを使用することでこれを実現できます。

注意:

  • アラートの確認は、重大度が低下してもクリアされない場合、同じイベントに適用されます。 たとえば、レベルエラーのディスク使用状況アラートを確認し、アラートレベルが警告に低下するようにスペースを解放した場合、警告アラートはすでに確認済みと見なされます。 ただし、重大度が高くなっても、下位レベルでのアラートの確認応答はアラートのエスカレーションに影響しません。 たとえば、ディスク使用量エラーアラートを確認しても、ドライブがいっぱいになった場合、クリティカルアラートのエスカレーションには影響しません。
  • 重大度の高いアラートの確認は、アラートセッション内で重大度が低下した時と、同じ重大度に上昇した時にイベントを確認します。例えば、ディスク使用量がエラーレベルのアラートを確認し、空き容量を増やすと、アラートレベルは警告レベルに下がります。この場合、警告アラートは確認済みとみなされます。このアラートがしきい値を超えて上昇し、アラートレベルが再びエラーレベルに上昇した場合も、確認済みとみなされます。

アラート セッションは、データポイントのアラートのライフサイクルを追跡します。アラート セッションは、データポイントに対して任意の重大度のアラートが最初に作成されたときに開始され、アラートが任意の重大度レベルで存続する限り継続します。アラート セッションは、データポイントが任意のアラート重大度のしきい値を一貫して満たし続け、データポイントに対して任意の重大度のアラートが存在し続ける限り、アラートが低い重大度から高い重大度に移行した場合や、高い重大度から低い重大度に移行した場合にも継続します。

アラートのダウンタイム(SDT)のスケジューリング

ダウンタイムをスケジュールすると、構成されたSDT期間中、指定されたインスタンス、データソース、デバイス、またはWebサイトのすべてのアラート通知ルーティングが抑制されます。 これは、その特定のアラートのそれ以上の通知のみを抑制するアラートの確認とは対照的です。

次の場合は、SDT にリソースを配置する必要があります。

  • ダウンタイムを事前にスケジュールするのを忘れました。
  • 解決策は現在準備中ですが、問題が解決されている間は通知を受信し続けたくありません。 たとえば、サーバーのメモリが不足しているというアラートを受信して​​いて、現在注文中のメモリが多い場合は、SDT応答タイプを開始して、アラートが繰り返し通知されないようにすることができます。

インスタンス、データソースまたはデバイス、ウェブサイト、コレクターのSDTの詳細については、以下を参照してください。 SDTタブ, WebサイトSDT, コレクターSDT.

注意: EventSourceアラートにSDTで応答する場合、アラート条件に関連付けられた個々のイベントIDだけでなく、EventSource全体がSDTに配置されます。

アラートのエスカレーション

SDTが適切でなく、問題の内容が不明な場合、問題を特定して解決する時間がない場合、または問題の解決方法がわからない場合は、エスカレーションチェーンの次のステップにアラートをエスカレーションする必要があります。詳細については、以下を参照してください。 エスカレーションチェーン.

注意:

アラートに応答する場所

アラートを確認、SDT、またはエスカレーションできる場所がいくつかあります。

  • LogicMonitorプラットフォームのアラートページから。詳細については、 アラートページからのアラートの管理.
  • LogicMonitorプラットフォームの「アラート」タブ(「リソース」または「ウェブサイト」ページからアクセス可能)から。詳細については、以下を参照してください。 [アラート]タブ.
  • アラートによってメール通知が生成された場合には、メール通知から返信することができます。詳細については、 電子メールまたはSMS電子メールによるアラート通知への応答.
  • アラートによってテキストメッセージで通知が送信された場合、テキストメッセージスレッドから返信することができます。詳細については、 ネイティブSMSアラート通知への応答.
  • アラートによって、メッセージング プログラムや ITSM ソリューションなどのサードパーティ ツールにルーティングされる通知が生成された場合は、そのサードパーティ ツールから応答できます。 詳細については、次を参照してください。 LogicMonitor 統合の概要.

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