New Relic の UI ページの対象エンティティのインデックスの横にはヘルスステータスインジケータが表示されるものがあります。
ヘルスインジケータは New Relic が監視しているアプリやその他のエンティティのステータスを示す色付き (緑、黄色、赤、または灰色) で表示します。対象エンティティにアラートが設定されているかどうか、またはインシデントが発生しているかどうかを簡易的に確認することができます。
サポートケースへの質問では対象エンティティの関連アラートを設定したが、ヘルスステータスが灰色 (アラート未設定) から変化しない、というご質問をいただく場合がございます。
本ブログでは、アラート設定とヘルスステータスの関連性および灰色から変わらない場合の確認方法などを記載いたします。
エンティティステータスの意味
エンティティステータスのは 4種類あり、それぞれ下記の意味となります。
| カラー | ヘルスステータスの意味 |
| 緑 | UI で表示できるデータが収集されており、継続中のアラートインシデントが報告されていない。 |
| 黄色 | 対象エンティティは劣化状態にある (警告しきい値 に違反したインシデントが継続中で存在している)。 |
| 赤 | クリティカルしきい値 に違反したインシデントが継続中で存在している。 |
| グレー (灰色) | エンティティのステータスが不明な状態。対象エンティティに関するアラート データを受信していない。エンティティに対してアラートが設定されていない、またはエンティティのアラート条件がエンティティに対するシグナルが報告されていない状態。 |
ref. 色分けされたヘルスステータス
識別としては、4種類ありますが、セットアップの観点では灰色か否かを意識します。
- アラート設定がされているかいないか
- 設定されていない場合は灰色、設定されている場合はその他の色 (緑、黄色、赤)
- そのエンティティに関する障害が発生しているか
- 障害 (インシデント、Issue) が発生していない場合は緑、発生している場合は 黄色 (警告)、赤 (クリティカル)
エンティティ一覧ページでのヘルスステータスの表示例
エンティティにアラート設定を行う
ヘルスステータスで、エンティティにアラートが設定されていると認識させる (灰色以外にする) ためには、2つのステップが必要です。
- 対象エンティティのデータを対象とするアラートコンディションが作成されている
- 対象エンティティのデータを対象とするアラートシグナルが報告されている
簡単に言えば、対象エンティティのアラート用の評価データ (アラートシグナル) が存在すれば、認識されます (灰色以外になります)。
シグナルデータが作成されるためにアラートコンディションが必要になります。
対象エンティティ用のアラートコンディションだけが存在していても、データ報告がない (シグナルがない) 場合は、アラート未設定 (灰色) のままとなります。
NRQL 型アラートコンディション
アラートコンディションでは、対象エンティティを設定するような項目は存在しないため、アラートクエリで設定されします。
その際に シグナルが対象エンティティを一意に認識できるように WHERE や FACET を設定します。
具体例 1 WHERE 条件で 1つの エンティティ情報が特定できるように指定されている場合:
下記のような場合に WHERE 条件で エンティティの GUI が指定されているような場合は、対象データは単一の エンティティに限定されるため、シグナルにエンティティを認識させることができます。
SELECT average(cpuPercent) AS `CPU used %` FROM SystemSample
WHERE entityGuid = '{対象エンティティの GUID}'
しかし、下記のように複数のエンティティが対象となっている場合はシグナルはエンティティを一意に特定することができないため、うまくいきません。
(複数のエンティティが設定されていても、データが 1つのエンティティしか発生していない場合は、一意に特定されるので認識されます)
SELECT max(cpuPercent) AS `max CPU used %` FROM SystemSample
WHERE entityGuid IN ('エンティティ A の GUID', 'エンティティ B の GUID')
もう少し別の言い方をすると、シグナルの対象データが単一のエンティティデータであれば、シグナルは対象を特定することができます。
エンティティ GUI でなくとも別の項目でも構いません。
収集対象に同一ホスト名のホストがない場合は、WHERE の条件に hostname や entityName を指定しても問題ありません。
SELECT average(cpuPercent) AS `CPU used %` FROM SystemSample
WHERE hostname = '対象ホスト名'WHERE 条件に指定したタグをもつエンティティが 1台のみであれば、コンディションの対象データは 単一ホストからの情報になるため、シグナルはエンティティを特定することができます。
(tags.environment:staging をもつ SystemSample データが 1台のみであれば、問題ありません。)
SELECT average(cpuPercent) AS `CPU used %` FROM SystemSample
WHERE tags.environment = 'staging'コンディションの対象データは 単一ホストからの情報になるため、シグナルはエンティティを特定することができるので、対象イベントの報告をするホストが 1台であれば、シグナルはエンティティを特定することができます。
(ProcessSample イベントで httpd データを報告するホストが 1台のみであれば、エンティティを特定する条件を記述する必要はありません。)
SELECT count(*) FROM ProcessSample WHERE processDisplayName = 'httpd'とは言え、対象ホストや APM アプリが増え、同一項目を報告するようになれば、複数対象のデータが報告されるようになります。
その場合は、FACET を利用して各ホストやアプリごとにシグナルが作成されるようにしましょう。
SELECT average(cpuPercent) AS `CPU used %` FROM SystemSample
FACET entityName
上記のアラートクエリの場合、WHERE 条件の指定はありませんが、FACET entityName と指定しているため、シグナルは entityName ごとに作成されます。SystemSample データで同一の entityName がなければ、シグナルのデータは単一エンティティの情報になるため、エンティティを認識することができます。
クラスター化された項目などを除ければ、基本的にはインフラホストのアラート項目ではホストごとで収集、評価されるものと思いますので FACET entityName によって、エンティティごとにシグナルを作成するようにするのが良いと思います。
また、既存のアラートコンディションで FACET enityName が設定されていれば、新規に追加したホストでもデータ受信が開始され、シグナルが出荷されたタイミングでエンティティステータスは非灰色に変わるようになります。ホストの追加に伴い都度アラートコンディションを調整する必要はなくなります。
シグナルがエンティティを認識しているかの確認
アラートシグナルの情報は、NrAiSignal イベントをクエリすることで確認でき、シグナルがエンティティを認識している場合は entity.guid が記録されます。
NrAiSignal にて、WHERE 条件に対象エンティティを指定する、または WHERE 条件に対象アラートコンディションを指定するなどで確認することができます。
// 対象エンティテ GUID を指定してシグナルデータを確認する場合
SELECT endTimestamp, signalValue, conditionId, signalId, entity.guid, resetCause, * FROM NrAiSignal WHERE entity.guid = '{{対象エンティティの GUID}}'
// アラートコンディション id を指定して、シグナルデータを確認する場合
SELECT endTimestamp, signalValue, conditionId, signalId, entity.guid, resetCause, * FROM NrAiSignal WHERE conditionId = {{対象アラートコンディションの id}}NrAiSignal での entity.guid の確認例 (entity.guid がある場合)
NrAiSignal での entity.guid の確認例 (entity.guid がない場合)
シグナルに entity.guid が結びついていない場合
シグナルが記録されているが、entity.guid が結びついていない場合は、多くの場合、アラートクエリに問題があります。
先に説明してきたように対象データとして、複数のエンティティの情報が含まれている可能性があります。
アラートクエリの対象データを SELECT * などに変えて、複数のエンティティデータが含まれていないかを確認しましょう。
必要に応じて、WHERE 句や FACET 句を調整します。
シグナルが記録されていない
NrAiSignal でコンディションid を指定した確認をした際に、シグナル自体が存在しなかったという場合、アラートコンディションまたは対象データを受信していないということが考えられます。
ストリーミングメソッドとして、Event flow を利用している場合などは後続データを受信するタイミングでシグナルが作成されるため、データ受信間隔が長い場合は想定するタイミングでシグナルが作成されていない可能性があります。
ref. よくある質問とトラブルシューティング Alerts 関連 (シグナル/インシデント編)
シグナルに entity.guid が結びついているデータがあるが灰色のまま (または灰色になってしまった)
NrAiSignal では、過去に シグナルに entity.guid が結びついていたデータが記録されているが、エンティティステータスが灰色のまま、または、過去に非灰色だったが数日後に灰色になってしまったなどの場合は
シグナルデータが取れなくなってしまったということが考えられます。
データが取得できなくなってしまった場合は、アラート設定ができていない、と表示されるようにヘルスステータスは灰色に戻ります。
シグナルに entity.guid が結びついていたデータが記録された場合は、非灰色に変化しますが、その後、シグナルデータが収集されなくなった場合、灰色に戻されてしまう場合があります。
ログ監視や Synthetic モニターなどでエラー発生時のみが対象データとなるようなアラートコンディションの場合、継続的にシグナルデータが発生しないため、上記にようにアラートが未設定に戻される場合があります。
エンティティに不定期データに対するアラート設定だけを行なっている場合は、継続的にステータスを緑で表示させ続けることは難しいため、継続的にシグナルが発生するような項目のアラートを別途作成するか、通常時は灰色ステータスで障害発生時のみ赤または黄色になると認識いただき運用いただく必要がございます。
Synthetic モニターの FAILED 検知のような場合は、filter 関数などを利用して回避することは可能です。
ref. 例: 返されたnull値対ゼロ値
また、非灰色から灰色 (not configured) に戻る期間 (TTL) は、一定周期ではなく、新しいシグナルデータを発生した際に過去のシグナルデータをもとに都度、計算され算出されます。
エンティティのヘルスステータスの変更ログ (履歴) の確認
ヘルスステータスの変更は、EntityAudits イベントに記録されます。灰色 -> 緑、緑 -> 赤または緑 -> 灰色 などアラート設定が認識されたタイミングだけでなく、障害が発生したことの変化も記録されます。
SELECT eventTimestamp, metadataSeverityName, event, guid,* from EntityAudits
WHERE event = 'SEVERITY_CHANGE' and guid = '{entity.guid}' SINCE 1 WEEKS AGO LIMIT MAXエンティティステータスの変更履歴の確認例
対象データに欠損期間が発生してしまうような場合は、データの欠損期間とヘルスステータスの変更タイミングが一致しているかを確認してみてください。
まとめ
エンティティ (ヘルス) ステータスとアラート設定の関係性について、記載いたしました。
アラートを設定したが、ヘルスステータスが灰色 (アラート未設定) のまま、という場合は本ブログの内容をご確認ください。
また、上記の内容では原因を特定できないような場合もありますので、解決しない場合はサポートにお問い合わせください。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
