アラートに対応するためのガイドライン

問題を特定する

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

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

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

次のセクションで説明するように、アラートに応答できる場所がいくつかあります。 回答方法は個人の好みによって異なりますが、目前の問題を解決できるかどうかに応じて、提供する必要のある回答の種類に関するガイドラインがあります。

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

• アラートの確認
• アラートのダウンタイム（SDT）をスケジュールする
• アラートのエスカレーション

アラートの確認

アラート確認応答は、その特定のアラートのそれ以上の通知ルーティングを抑制します。 問題を解決できると思われる場合は、アラートを確認する必要があります。 問題の解決には、問題の原因を修正し、必要に応じてアラートが再発しないようにするためのアクションを実行することが含まれます。 それ以上のアラートを抑制するアクションには、次のものがあります。

• アラートしきい値の調整。
• アラートを無効にします。
• 次のセクションで説明するダウンタイムをスケジュールして、予想される定期的なメンテナンスの期間をカバーします。
• アラートデータソースインスタンスを検出から削除するか、複製されたデータソースを作成して、さまざまなアラートしきい値で検出/分類します。 検出されるべきではないインスタンスのセット（Linuxホスト上のNFSマウントファイルシステムなど）がある場合、または他のインスタンスとは異なるしきい値が必要な場合（ロードバランサーのQA VIPなど）、ActiveDiscoveryフィルタリングを使用してそれを実現できます。

注記：

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

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

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

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

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

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

インスタンス、データソース、またはデバイスのダウンタイムのスケジュールの詳細については、を参照してください。 SDTタブ; Webサイトのダウンタイムのスケジュールについては、を参照してください。 WebサイトSDT; コレクターのダウンタイムのスケジュールについては、を参照してください。 コレクターSDT.

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

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

アラートを次のステップにエスカレーションする必要があります エスカレーションチェーン SDTが適切でなく、問題が何であるかわからない場合、問題を特定および/または解決する時間がない場合、または問題を解決する方法がわからない場合。

Note: 例え エスカレーション間隔 一致するアラートルールがゼロに設定されている場合でも、アラートはエスカレートします。

Note: 通知が原因で抑制されたアラートをエスカレーションすることはできません 動的しきい値 or 根本原因分析 評価。

アラートに応答する場所

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

• LogicMonitorプラットフォームにある[アラート]ページから。 見る アラートページからのアラートの管理 より詳細をご確認いただけます。
• LogicMonitorプラットフォームにある[アラート]タブ（[リソース]または[Webサイト]ページから入手可能）から。 見る [アラート]タブ より詳細をご確認いただけます。
• アラートが電子メール経由でルーティングされる通知を生成する場合は、電子メール通知から（返信として）応答できます。 見る 電子メールまたはSMS電子メールによるアラート通知への応答 より詳細をご確認いただけます。
• アラートがテキスト経由でルーティングされる通知を生成する場合は、テキストスレッドから（返信として）応答できます。 見る ネイティブSMSアラート通知への応答 より詳細をご確認いただけます。
• アラートによって、メッセージング プログラムや ITSM ソリューションなどのサードパーティ ツールにルーティングされる通知が生成された場合は、そのサードパーティ ツールから応答できます。 詳細については、次を参照してください。 LogicMonitor 統合の概要.