ヒント
NRQL 条件ガイド モードでは、インフラストラクチャの「ホストが報告しない」(HNR) NRQL 条件を作成するための厳選されたエクスペリエンスが提供されます。 これは、インフラストラクチャの「ホストのレポートなし」条件を作成する代わりに推奨される方法です。
インフラストラクチャ モニタリングのHost not reporting 条件を使用して、インフラストラクチャエージェントからのデータの受信が停止したときに通知します。 この機能を使用すると、ホストのグループを動的に集計し、5 分から 60 分までの時間枠を設定し、 通知を最大限に活用できます。
特徴
最も重要なホストのセットに基づいて条件を定義し、フィルタリングされたホストのセットごとに適切な閾値を構成できます。 Host not reportingイベントは、インフラストラクチャエージェントからのデータが指定した時間枠内にコレクターに到達しなかった場合にトリガーされます。
注意
タグまたはラベルを使用して Host Not Reporting 条件をフィルタリングし、対象のホストから重要なタグまたはラベルを削除した場合、システムはそのホストが接続を失ったと認識するため、ホストが報告されていないインシデントを開きます。
この機能は柔軟性があるため、監視対象や、特定の個人やチームにいつ通知するかを簡単にカスタマイズすることができます。また、通知メールには、トラブルシューティングを迅速に行うためのリンクが含まれています。
Host not reporting condition | Features |
|---|---|
モニターの内容 | エンティティ フィルター バーを 使用して、アラート条件で監視するホストを選択できます。この条件は、これらのフィルターに一致する今後追加するホストにも自動的に適用されます。 |
通知方法 | 条件は ポリシーに含まれます。既存のポリシーを選択することも、インフラストラクチャ監視 UI から電子メール通知を使用して新しいポリシーを作成することもできます。他のタイプの 通知チャネルを使用して新しいポリシーを作成する場合は、 UIを使用します。 |
通知のタイミング | 電子メール アドレス (ポリシーで識別される) には、ポリシーの インシデント設定 に応じて、適用したフィルターに一致するホストの しきい値 インシデントが自動的に通知されます。 |
トラブルシューティングを行う場所 | 電子メール通知の上部にあるリンクをクリックすると、ホストが切断された時間を中心としたインフラストラクチャEventsページに移動します。 メール内の追加リンクをクリックすると、さらに詳しい情報が表示されます。 |
作成"ホストが" の状態を報告しない
Host not reporting条件基準を定義するには:
標準的な手順に従って、 インフラストラクチャの状態を作成する 。
Alert typeとしてHost not reportingを選択します。
通知をトリガーするための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インシデントを再びオープンできるようになります。ヒント
hostStatus: shutdownタグの代わりに、ホスト エンティティにタグtermination: expectedを追加できます。 これにより、ホストがシャットダウンする予定であることが New Relic に伝えられ、Don't trigger alerts for hosts that perform a clean shutdown [クリーン シャットダウンを実行するホストに対してアラートをトリガーしない]限り、Host not reporting [ホストが報告しない]インシデントが発生するのを防ぎます。条件でオプションが選択されています。
ポリシーのインシデント設定に応じて、条件に定義されたCritical閾値を超えたときに使用する通知チャネルが定義されます。 「誤検知」を回避するには、インシデントが発生する前の全期間にわたってホストはレポートを停止する必要があります。
Example: フィルタリングされたホスト セットのいずれかがseven分間データのレポートを停止した場合にインシデントを開く条件を作成します。
- いずれかのホストが 5 分間レポートを停止し、その後レポートを再開すると、条件does notによってインシデントがオープンします。
- いずれかのホストが 7 分間レポートを停止した場合、他のホストが正常であっても、条件doesによってインシデントが発生します。
問題点の究明
ホストがデータを報告していない原因をさらに調査する。
- 通知メールに記載されている内容を確認してください。
- Events電子メール通知のリンクを使用して、インフラストラクチャ の ページUI から環境の進行中の変更を監視します。たとえば、 Eventsページを使用すると、ルート ユーザーがホストの設定を変更した直後にホストが切断されたかどうかを判断できます。
- オプション: 電子メール通知のAcknowledgeリンクを使用して、警告インシデントを認識し、その所有権を取得していることを確認します。
- メール リンクを使用して、 Incident detailsページの追加詳細を調べます。
意図的な停電
オプションDon't trigger alerts 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システムも含まれます。**