インフラストラクチャ モニタリングの Host not reporting condition を使用して、インフラストラクチャ エージェントからのデータ受信が停止したことを通知します。この機能では、ホストのグループに対して動的にアラートを出したり、時間ウィンドウを5分から60分に設定したり、アラート通知を最大限に活用することができます。
特徴
最も重要なホストのセットに基づいて条件を定義し、フィルタリングされたホストのセットごとに適切なしきい値を構成できます。Host not reporting [ホストが報告しない]イベントは、インフラストラクチャ エージェントからのデータが、指定した時間枠内に コレクター に到達しない場合にトリガーされます。
注意
タグまたはラベルを使用して Host Not Reporting 条件をフィルタリングし、対象のホストから重要なタグまたはラベルを削除した場合、システムはそのホストが接続を失ったと認識するため、ホストが報告されていないインシデントを開きます。
この機能は柔軟性があるため、監視対象や、特定の個人やチームにいつ通知するかを簡単にカスタマイズすることができます。また、通知メールには、トラブルシューティングを迅速に行うためのリンクが含まれています。
ホストレポート停止条件 | 特徴 |
|---|---|
モニターの内容 | エンティティ フィルター バーを 使用して、アラート条件で監視するホストを選択できます。この条件は、これらのフィルターに一致する今後追加するホストにも自動的に適用されます。 |
通知方法 | 条件は ポリシーに含まれます。既存のポリシーを選択することも、インフラストラクチャ監視 UI から電子メール通知を使用して新しいポリシーを作成することもできます。他のタイプの 通知チャネルを使用して新しいポリシーを作成する場合は、 UIを使用します。 |
通知のタイミング | 電子メール アドレス (ポリシーで識別される) には、ポリシーの インシデント設定 に応じて、適用したフィルターに一致するホストの しきい値 インシデントが自動的に通知されます。 |
トラブルシューティングを行う場所 | 通知メールの上部にあるリンクは、ホストが切断された時間を中心に、 インフラストラクチャ イベント ページ に移動します。メール内のその他のリンクからは、さらに詳細な情報を見ることができます。 |
作成"ホストが" の状態を報告しない
Host not reporting の条件を定義すること。
標準的な手順に従って、 インフラストラクチャの状態を作成する 。
Select Host not reporting as Alert type.
通知をトリガーするための Critical の閾値を定義します。最小5分、最大60分。
コマンド ライン経由で ホストをシャットダウンするように設定しているときに誤ったアラートが発生するのを防ぐ場合は、Don't trigger alerts for hosts that perform a clean shutdown[クリーン シャットダウンを実行するホストに対してアラートをトリガーしない] オプションを 有効にします。現在、この機能は、systemd を使用するすべての Windows システムおよび Linux システムでサポートされています。
ヒント
あるいは、上記のオプションをオンにして、ホストに
hostStatus: shutdownタグ を追加することもできます。これにより、エージェントのバージョンや OS に関係なく、そのタグが付いている限り、そのホストに対して Host Not Reporting [ホストが報告しない] インシデントがすべて開かれなくなります。タグを削除すると、システムはそのホストに対して Host Not Reporting [ホスト非報告] インシデントを再度開くことができるようになります。
ポリシーの インシデント設定に応じて、条件に対して定義された Critical [クリティカル] しきい値を超えたときに使用する通知チャネルが定義されます。「誤検知」を回避するには、ホストはインシデントがオープンされる前に、一定期間レポートを停止する必要があります。
例: フィルタリングされたホストのセットのいずれかが 7 分間データのレポートを停止したときにインシデントをオープンする条件を作成します。
- いずれかのホストがレポートを 5 分間停止し、その後レポートを再開しても、この状態ではインシデントは発生 しません 。
- いずれかのホストが 7 分間報告を停止した場合、他のホストが正常であっても、その状態によりインシデントが発生 します 。
問題点の究明
ホストがデータを報告していない原因をさらに調査する。
- 通知メールに記載されている内容を確認してください。
- 電子メール通知のリンクを使用して、インフラストラクチャ UI の Events [イベント] ページ から環境内の進行中の変更を監視します。たとえば、 Events [イベント] ページを使用すると、root ユーザーがホストの構成を変更した直後にホストが切断されたかどうかを判断できます。
- オプションです。電子メール通知の Acknowledge リンク を使用して、警告されたインシデントを認識し、所有していることを確認します。
- 電子メールのリンクを使用して、 Incident details [インシデントの詳細] ページで追加の詳細を調べます。
意図的な停電
想定外の状況と計画的な状況を区別するには、 Don't trigger alert for hosts that perform a clean shutdown を指定します。などの状況でこのオプションを使用します。
- ホストは意図的にオフラインにされています。
- ホストがメンテナンスのために計画的に停止している。
- ホストがシャットダウンまたはデコミッションされたこと。
- クラウドコンソールでホストのオートスケーリングやインスタンスのシャットダウンを行う。
LinuxやWindowsのシャットダウンシグナルを頼りに、クリーンなシャットダウンのフラグを立てます。
これらのシナリオがエージェントによって検出されることを確認しました。
- systemdを使用するEC2インスタンス（Amazon Linux、CentOs/RedHat 7以降、Ubuntu 16以降、Suse 12以降、Debian 9以降）でのAWS Auto-scalingイベント。
- ユーザー主導によるWindowsシステムのシャットダウン
- systemd を使用する Linux システムのユーザーによるシャットダウン（Amazon Linux、CentOs/RedHat 7 以降、Ubuntu 16 以降、Suse 12 以降、Debian 9 以降）。
これらのシナリオは、 エージェントによって検出されないことがわかっています。
*** systemd を使用していない Linux システム（CentOs/RedHat 6 以前、Ubuntu 14、Debian 8）のユーザー主導のシャットダウン。これには、Upstart や SysV init システムを使用しているその他の最新の Linux システムも含まれます。
- systemdを使用していないEC2インスタンス（CentOs/RedHat 6以前、Ubuntu 14、Debian 8）でのAWS Auto-scalingイベント。これには、UpstartまたはSysV initシステムを使用しているその他の最新のLinuxシステムも含まれます。**