• EnglishEspañol日本語한국어Português
  • ログイン今すぐ開始

この機械翻訳は、参考として提供されています。

英語版と翻訳版に矛盾がある場合は、英語版が優先されます。詳細については、このページを参照してください。

問題を作成する

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

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

特徴

最も重要なホストのセットに基づいて条件を定義し、フィルタリングされたホストのセットごとに適切な閾値を構成できます。 Host not reportingイベントは、インフラストラクチャエージェントからのデータが指定した時間枠内にコレクターに到達しなかった場合にトリガーされます。

注意

タグまたはラベルを使用して Host Not Reporting 条件をフィルタリングし、対象のホストから重要なタグまたはラベルを削除した場合、システムはそのホストが接続を失ったと認識するため、ホストが報告されていないインシデントを開きます。

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

Host not reporting condition

Features

モニターの内容

エンティティ フィルター バーを 使用して、アラート条件で監視するホストを選択できます。この条件は、これらのフィルターに一致する今後追加するホストにも自動的に適用されます。

通知方法

条件は ポリシーに含まれます。既存のポリシーを選択することも、インフラストラクチャ監視 UI から電子メール通知を使用して新しいポリシーを作成することもできます。他のタイプの 通知チャネルを使用して新しいポリシーを作成する場合は、 UIを使用します。

通知のタイミング

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

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

電子メール通知の上部にあるリンクをクリックすると、ホストが切断された時間を中心としたインフラストラクチャEventsページに移動します。 メール内の追加リンクをクリックすると、さらに詳しい情報が表示されます。

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

Host not reporting条件基準を定義するには:

  1. 標準的な手順に従って、 インフラストラクチャの状態を作成する

  2. Alert type

    として

    Host not reporting

    を選択します。

  3. 通知をトリガーするための

    Critical

    閾値を定義します: 最小 5 分、最大 60 分。

  4. コマンドライン経由でホストをシャットダウンするように設定している場合に誤ったアラートを防止するには、

    Don't trigger alerts for hosts that perform a clean shutdown

    オプションを有効にします。 現在、この機能は systemd を使用するすべての Windows システムと Linux システムでサポートされています。

    ヒント

    さらに、上記のオプションをチェックするとともに、ホストにhostStatus: shutdown タグを追加することもできます。これにより、エージェントのバージョンや OS に関係なく、そのタグが付いている限り、そのホストのすべてのHost not reportingインシデントがオープンされなくなります。タグを削除すると、システムはそのホストでHost not reportingインシデントを再びオープンできるようになります。

ポリシーのインシデント設定に応じて、条件に定義されたCritical閾値を超えたときに使用する通知チャネルが定義されます。 「誤検知」を回避するには、インシデントが発生する前の全期間にわたってホストはレポートを停止する必要があります。

Example: フィルタリングされたホスト セットのいずれかがseven分間データのレポートを停止した場合にインシデントを開く条件を作成します。

  • いずれかのホストが 5 分間レポートを停止し、その後レポートを再開すると、条件

    does not

    によってインシデントがオープンします。

  • いずれかのホストが 7 分間レポートを停止した場合、他のホストが正常であっても、条件

    does

    によってインシデントが発生します。

問題点の究明

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

  1. 通知メールに記載されている内容を確認してください。

  2. Events

    電子メール通知のリンクを使用して、インフラストラクチャ の ページUI から環境の進行中の変更を監視します。たとえば、

    Events

    ページを使用すると、ルート ユーザーがホストの設定を変更した直後にホストが切断されたかどうかを判断できます。

  3. オプション: 電子メール通知の

    Acknowledge

    リンクを使用して、警告インシデントを認識し、その所有権を取得していることを確認します。

  4. メール リンクを使用して、

    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システムも含まれます。**
Copyright © 2024 New Relic株式会社。

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