本記事では、New Relic テクニカルサポートにお寄せ頂くことが多いお問い合わせ内容をもとに Workflow 通知に関連するいくつかのトピックについて解説します。
製品ドキュメント の補足として、意図通りのアラート通知を行うまたはトラブルシューティングのヒントとして頂ければ幸いです。
また、複雑さを回避するために本記事では、アラートポリシーの correlation なし設定の場合を前提といたします。
Workflow の Filter data の 4つの Priority について
Filter data の Basic モードでの設定では Priority として、下記の 4種類の選択肢が表示されますが
- LOW
- MEDIUM
- HIGH
- CRITICAL
現行の (NRQL 型の) アラートコンディションでは CRITICAL と HIGH が利用されます。
LOW および MEDIUM は、EOL となった APM 用のアラート機能にて利用されていたもので、現在では 外部からの インシデントイベント REST API 利用の際に利用がが可能という程度で、アラートコンディションを利用する方法では、利用することはないかと思います。
また、HIGH/CRITICAL は Issue の priority に対応します。Filter data の Priority で HIGH のみにチェックが付いている場合は、Issue の priority が HIGH の場合に Workflow は稼働します。
Filter data の Priority が未設定の場合は Issue priority に関係なくいずれの priority の場合でも Workflow は稼働します。
Issue の priority (HIGH と CRITICAL) については次の項目に記載ます。
Filter data > Priority のデフォルト選択肢
Issue の priority (HIGH と CRITICAL) について
NRQL 型アラートコンディションでは Critical 閾値、Warning 閾値 およびシグナルロスト用の 3つの閾値設定があります。
それぞれの閾値に違反した場合に作成されるインシデントの priority は次のようになります。
- Critical 閾値に違反したインシデントの priority は critical
- Waning 閾値に違反したインシデントの priority は warning
- シグナルロスト発生時のインシデントの priority は critical
次に Issue の priority の考えたですが、これはその Issue に所属するインシデントの中で最も高い priority がその Issue の priority を決定します。
- warning のインシデントしか存在しない Issue の場合、Issue priority は HIGH
- warning インシデントと critical インシデントが混在する Issue の場合、Issue priority は CRITICAL
- critical なインシデントしか存在しない Issue の場合、Issue priority は CRITICAL
Issue の priority は インシデントは Open/Close には依存しません。インシデント継続中であろうとクローズ済みであろうと、所属する最も priority の高いインシデントの priority が Issue の priority を決定します。
また、基本的には Issue priority は HIGH から CRITICAL に変化することはあっても、CRITICAL から HIGH に変化することはありません。
- warning インシデントが所属する Issue に critical インシデントが追加された場合、Issue priority は HIGH から CRITICAL に変化します
- critical インシデントが所属する Issue に warning インシデントが追加された場合、Issue priority は CRITICAL のまま変化しません
- waning と critical が所属する Issue で、critical インシデントのみが復旧した場合、Issue priority は CRITICAL のまま変化しません
Workflow の Filter data で、Priority で HIGH のみを指定している場合で、Issue Priority が HIGH から CRITICAL に変化した場合は、Workflow のマッチ条件に合致しなくなるため、稼働しなくなります。
同一シグナルにおいて、Warning インシデントと Critical インシデントに関する通知先を分けたい
現状では、デフォルトの機能では実現できません。Warning 閾値用のアラートコンディションと Critical 閾値用のアラートコンディションをそれぞれ作成いただく必要がございます。
同一シグナルの Waning インシデントと Critical インシデントが同時間帯で発生した場合、同一の Issue に属することになります。
また、Workflow は Issue に対するイベントで稼働し、インシデントの追加、クローズイベントは認識されますが、そのインシデントの priority までは認識されません。
別途インシデントイベントを監視する方法で、実現することはできますが、シンプルな方法ではありません。
Workflow をアラートコンディション単位で稼働するようにしたい
アラートポリシーまたはアラートコンディション作成時に作成される Workflow では対象の PolicyId がデフォルトで設定されますが Filter data は編集いただけます。
Filter data で account や指定タグなどを設定することで、フィルターに合致する Issue イベントが発生した場合に、稼働するようにカスタマイズが可能です。
アラートコンディションごとに Workflow を稼働させたい場合は
Alerts > Workflows > 選択した workflow
Filter data 項目 Advanced 方式で設定
属性として conditionFamilyId (accumulations.conditionFamilyId) を入力し、演算子 (exactrly matches)、値 (アラートコンディションId) を設定ください。
また同一の workflow 内で、アラートコンディションごとの通知制御はできません。
通知対象分だけ workflow を作成いただく必要がございます。
また、conditionFamilyId 指定の場合は、アラートポリシー > Notifications には 作成した Workflow は表示されない仕様となります。
アラートポリシー > Notifications タブに Workflow が表示されなくなった
現状では Workflow の filter data で、アラートポリシーのほかに tag などのフィルターを追加した場合、(ポリシーId の指定があった場合でも) 対象 Policy 配下の Notifications タブでの関連表示はされなくなってしまいます。
(追加する項目によっては、関連表示されるものもございます)
Issue イベント発生時のフィルターマッチ時の動作としては、ポリシー配下の Notifications タグでの連携表示とは関係なく
指定された Filter data 条件にマッチした場合、workflow は稼働します。
連携された workflow の有無がわかりにくくなってしまうようで申し訳ございませんが、仕様である旨ご理解ください。
アラート通知 (Notify) の実行履歴を確認したい
Issue Notifications Log での確認
アラート通知の記録は、成功失敗にかぎらず
Alerts > Workflows > Issue Notifications Log にて確認いただけます。
表示項目は、時刻、Status, DestinationType, Operation, Issue タイトル, Trigger イベント、Workflow 名 でフィルターやタイムピッカーを利用して、対象を絞ることが可能です。
また、クリックすると詳細が表示され、失敗通知の場合、エラー内容を確認いただけます。
NRQL での確認
同内容は、NrAiNotification をクエリすることでも確認をいただけます。
クエリ形式での WHERE や SINCE/UNTIL などの指定、集計関数や時系列グラフなどの傾向分析にもご利用いただけます。
// NrAiNotification イベントのサンプルクエリ
SELECT status, trigger, issueName, issueLink, workflowName, destinationType, destinationName, operation, * FROM NrAiNotification
WHERE status != 'SUCCESS' SINCE 1 days AGO LIMIT 100アラート通知の失敗を検知したい (アラート通知の結果を監視したい)
アラート通知の失敗を検知されたいという場合は、NrAiNotification イベントに対し status != SUCCESS などの条件でアラート設定を行うことで通知の成功・失敗を監視することが可能です。
アラートコンディション例:
NrAiNotification イベントで SUCCESS 以外の status が記録された場合、違反とする。閾値判定での回復なし (手動での Issue クローズを想定)
- Window Duration: 1分
- Event timer (タイマー1分)
- static 閾値: result > 0 at least once in 1分
- アラートクエリ:
SELECT count(*) FROM NrAiNotification WHERE status != 'SUCCESS'
また、メール通知の失敗する対象とする場合は、メール通知失敗検知時の Workflow 通知の通知先 (destination) は、通常アラートの通知先とは異なる通知先を設定ください。
Webhook (slack) で通知が失敗する (violationChartUrl の取得失敗)
violationChartUrl には、workflow の通知処理内で作成されるインシデントチャートの URL が格納されますが チャートの作成処理が時間内に完了せず、タイムアウトで失敗してしまう場合があるようです。 その場合、violationChartUrl 変数には "Not Available" という文字列が、格納されることとなります。
slack の webhook の場合、image_url に URL 以外のデータが設定されていると、Slack 側で受付が拒否されてしまい、Webhook 通知が失敗してしまうようです。
上記の回避方法として、if および contains ヘルパーなどを用いて、violationChartUrl が URL 以外の文字列であった場合は image_url を記載しないようにすることで通知自体の失敗を防ぐことが可能となります。
if, contains ヘルパーを用いた記載例:
{{#if violationChartUrl}}{{#contains "https" violationChartUrl}}
{
"type": "image",
"title": {
"type": "plain_text",
"text": "image1",
"emoji": true
},
"image_url": "{{ violationChartUrl }}",
"alt_text": "image1"
},
{{/contains}}{{/if}}
また、if ヘルパーのみを利用した場合、うまく回避することができない点にご注意ください。 Handlebars の if では false, undefiend, null, 空文字, 0 などが 偽 と判定されます、 本事象では violationChartUrl に "Not Available" 文字列が格納されてしまうため、if の判定では、真 と評価されてしまいます。 contains や eq などを利用して回避ください。
メール通知が届かない (Dropped, Bounce ステータス)
User unknown や過剰受信などの理由でメールの受信を拒否されてしまった場合、Issue Notifications Log や NrAiNotification の status が Bounce と記録され、通知メールが届かない場合がございます。
また、一度 Bounce ステータスが記録されたメールアドレスは、以降のメール送信が行われないように送信抑制リストに登録されてしまいます。
対象メールアドレスが送信抑制リストにある場合、Issue Notifications Log や NrAiNotification の status には Dropped と記録され、メールは送信されません。
Bounce が発生した原因は NrIntegrationError イベントに記録される場合がございます。エラーが記録されている場合は内容を確認いただき、対象メールアドレスが受信できるようにご対応ください。
対象メールアドレスの送信抑制リストからの削除やその他の通知に関するトラブルシューティングについては、サポートチームにて確認・対応いたしますので、サポートケースにてご連絡ください。
メール/Slack通知の内容をカスタマイズしたい (特定の通知項目を無効化したい)
メール/Slack 通知の文面に関しては、Enrichment によるチャートの追加や Custom Details で任意のテキスト情報を追記いただくことは可能ですが
情報の削減やレイアウトを変更する方法はございません。
表示内容の過不足や任意の内容で通知をカスタマイズされたい場合は、Webhook や EventBridge 通知での対応をご検討ください。
Webhook 通知や EventBridge 通知では json 形式で任意の文面を設定いただけますので、
お客様にて用意された連携先の API 等を経由して任意のフォーマットのメールを送る等も可能かと思います。
メール/Slack 通知の Custom Details にトリガーファセット値を利用する
Custom Details には workflow 変数を利用することができます。
また、アラートクエリの FACET として指定した項目は タグとして認識されるため、Custom Details に出力することが可能です。 必要に応じて、FACET 項目を追加いただき、accumulations.tag.FACET名 で取得ください。
アラートクエリが次のような場合 (FACET appName が指定されている場合)
SELECT average(duration) FROM BrowserInteraction FACET appName
対象の appName は、accumulations.tag.appName に格納されます。Custom Details では次のように出力いただけます。
{{ accumulations.tag.appName }}
ただ、アラートクエリで FACET を追加する場合、シグナルのグルーピングに影響があるため、シグナルの対象データが変化してしまう場合がございます。 FACET の追加によって、閾値設定を見直す必要がある場合や回復判定が行われなくなってしまう場合もございますので、変更を行う場合は、変更内容の意味をご理解いただいた上で、実施ください。
ログ監視で検出したメッセージ自体を通知本文に含めたい
ログ監視のアラートについて、現時点では検出されたメッセージ本文を直接通知に含めることはできません。
NRQL型アラートコンディションにおいて、アラートのトリガーとなるのは、厳密にはメッセージの検出そのものではなく、条件に該当するメッセージ件数を示す数値であり、アラートの内部情報にはメッセージ本文やその識別情報が含まれていないためです。
あらかじめアラート対象ログを表示するダッシュボードを作成しておき、Runbook URL でリンク先に指定するといった代替の運用方法や Workflow の Enrichment 機能の利用をご検討ください。
Workflow の Enrichment は、Workflow による通知時に追加の NRQL クエリを実行し、その結果を通知に添付する機能です。
こちらでアラート条件と同様の NRQL クエリを指定し、SELECT 句で message フィールドを取得することで、概ね想定と近い通知を受けることが可能となります。
アラートコンディションの Title template で Signal Lost (信号喪失) 時のタイトルが変更されない
現行の仕様では、Signal lost (信号喪失) に関するインシデントのタイトルは変更ができません。
NRQL 型アラートコンディションのタイトルテンプレートでは、インシデントタイトルのカスタマイズが可能となりましたが
同機能では信号喪失に関するインシデントのタイトルは対象外となっております。
ref. ドキュメント (NRQL アラート条件のタイトル テンプレート > あなたが始める前に > 信号喪失インシデント)
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
