• ログイン今すぐ開始

本書は、お客様のご参考のために原文の英語版を機械翻訳したものです。

英語版と齟齬がある場合、英語版の定めが優先するものとします。より詳しい情報については、本リンクをご参照ください。

問題を作成する

インフラの構築"ホストが" の状態を報告しないこと

インフラストラクチャ モニタリングの Host not reporting condition を使用して、インフラストラクチャ エージェントからのデータ受信が停止したことを通知します。この機能では、ホストのグループに対して動的にアラートを出したり、時間ウィンドウを5分から60分に設定したり、アラート通知を最大限に活用することができます。

機能

最も重要なホストのセットに基づいて条件を定義し、各 フィルターセット に適したしきい値を設定することができます。 Host not reporting イベントは、インフラストラクチャエージェントからのデータが、指定した時間内に コレクター に到達しなかった場合に発生します。

注意

タグやラベルを使用して Host Not Reporting 状態をフィルタリングした後、対象となるホストから重要なタグやラベルを削除した場合、システムはそのホストが接続を失ったと認識するため、Host Not Reporting違反を開きます。

この機能は柔軟性があるため、監視対象や、特定の個人やチームにいつ通知するかを簡単にカスタマイズすることができます。また、通知メールには、トラブルシューティングを迅速に行うためのリンクが含まれています。

ホストレポート停止条件

機能

モニターの内容

フィルターセット を使って、アラート条件で監視したいホストを選択することができます。この条件は、これらのフィルターに一致するホストを今後追加した場合にも自動的に適用されます。

通知方法

条件は ポリシーに含まれています 。既存のポリシーを選択したり、電子メール通知付きの新しいポリシーを作成するには、Infrastructure monitoring UIから行います。他のタイプの 通知チャンネルで新しいポリシーを作成したい場合UI を使用します。

通知のタイミング

ポリシーで特定された電子メールアドレスには、ポリシーの インシデント設定 に応じて、適用したフィルタに一致するホストの 閾値 違反について自動的に通知されます。

トラブルシューティングを行う場所

通知メールの上部にあるリンクは、ホストが切断された時間を中心に、 インフラストラクチャ イベント ページ に移動します。メール内のその他のリンクからは、さらに詳細な情報を見ることができます。

作成"ホストが" の状態を報告しない

Host not reporting の条件を定義すること。

  1. 標準的な手順に従って、 インフラストラクチャの状態を作成する
  2. Select Host not reporting as Alert type.
  3. 通知をトリガーするための Critical の閾値を定義します。最小5分、最大60分。
  4. 「Don't trigger alerts for hosts that perform a clean shutdown」 オプションを有効にします。コマンドラインでシャットダウンするように設定されているホストがある場合に、誤った警告を防ぐことができます。
    現在、この機能はすべてのWindowsシステムとsystemdを使用しているLinuxシステムでサポートされています。あるいは、上述のオプションをチェックするとともに、 hostStatus: shutdown tag をホストに追加することもできます。これにより、そのタグがある限り、エージェントのバージョンやOSに関係なく、そのホストに対してすべてのHost Not Reporting違反が開かなくなります。このタグを削除すると、システムはそのホストに対して再びHost Not Reporting違反を開くことができるようになります。

ポリシーの インシデントの設定 に応じて、定義された 条件のクリティカル のしきい値を超えたときに使用する通知チャネルが定義されます。"誤検出を避けるために、" ホストは、違反が開かれる前の全期間の報告を停止しなければなりません。

例: フィルタリングされた一連のホストのいずれかが 7 分間のデータ報告を停止したときに違反をオープンする条件を作成します。

  • いずれかのホストが5分間報告を停止し、その後報告を再開した場合、条件 違反を開いていない。
  • 他のホストが問題なくても、いずれかのホストが7分間報告を停止した場合、条件 違反を開きます。

問題点の究明

ホストがデータを報告していない原因をさらに調査する。

  1. 通知メールに記載されている内容を確認してください。
  2. 電子メール通知からのリンクを使用して、インフラストラクチャ モニタリングの Events ページ から環境の進行中の変更を監視します。たとえば、 Events ページを使用して、ルートユーザーがホストの構成を変更した直後にホストが切断されたかどうかを判断するのに役立ちます。
  3. オプションです。電子メール通知の Acknowledge リンク を使用して、警告されたインシデントを認識し、所有していることを確認します。
  4. 事件の詳細 ページ の追加情報を調べるには、メールのリンクを使用してください。

意図的な停電

想定外の状況と計画的な状況を区別するには、 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システムも含まれます。**
Copyright © 2022 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.