アラート・Workflow（通知）のトラブルシューティング その1

アラートとAI機能に関する大規模変更についてでお伝えしている通り、アラートや通知に関連する機能に関して変更が行われています。そのため、アラートや通知に関するお問い合わせの数も増えております。今回はアラートや通知で期待通りの結果がえられない場合の切り分け方法と、テクニカルサポートにお問い合わせいただく際に迅速な解決のために必要な情報をまとめていこうと思います。今回は第1回として、UIから確認できる範囲での調査方法を紹介します。

アラートの問題かWorkflowの問題か

多くの場合、くるべきはずだったアラート通知がこないことや、くるべきでなかったアラート通知が来たことで問題だと認識します。そのため、新しい通知機能である「Workflow」に問題があるとお問い合わせいただくことがあります。しかし、アラート条件に問題があるケースもあります。そこでまずは、アラート条件に違反して通知するまでの流れを把握することが重要です。

アラートの概念と用語に記載されている以下の図で説明してみます。

アラート設定はアラート条件で定義されます。どのデータ（イベントやメトリクス、ログ）がどの閾値をどのように超えたら違反状態とみなすかというのが定義です。1つあるいは複数のアラート条件をまとめるのがアラートポリシーです。そして、アラート条件に違反するとインシデント（Incidents）が作成されます。

Incidentが直接通知をトリガーするわけではありません。IncidentはIssueにまとめられ、IssueがWorkflowを起動します。起動したWorkflowに定義されている通知の宛先であるDestinationごとに通知が行われます。

そのため、まずはIssueが発生しているかどうかで切り分けます。

Issueが発生しているか確認する

Issueを確認するは、New RelicのUIでAlerts & AI メニューを開き、Issue & activityを選びます。デフォルトでは現在進行中の（stateがActiveな）Issueが表示されます。

通知が来ると期待したのに来なかった場合、Time Pickerをその時間前後にして、フィルター条件を削除してすべて表示します。また、通知が来るべきではないのに来た場合もTime Pickerをその時間前後にして、Alert ConditionやAlert policyでフィルターして通知のもととなったIssueを特定します。

Issueが見つかった場合は、そのIssueを開いて詳細を確認します。サポートに問い合わせるためにPermalinkをコピーして記録しておきます。

上のスクリーンショットで①がPermalinkをコピーするアイコン、②がWorkflow経由で通知された場合の通知の宛先、③がこのIssueの原因となったIncidentのアラートポリシー、④が同じくアラート条件、⑤がIssue payloadです。

この次にどこをみるかは問題と症状によって変わります。

1. 通知が来ると期待したのに来なかった場合
   1. 該当するIssueがあった ⇒ Workflowの調査
      また、通知の宛先のアイコンに取り消し表示がついている場合 ⇒ muting ruleの調査
   2. 該当するIssueがなかった ⇒ アラート条件の調査
2. 来るべきでない通知が来た場合
   1. 該当するIssueがあった => アラート条件の調査

Workflowを調べる

Workflowを調べるのは該当するIssueが存在するのに、通知が来ると期待していたのに来なかった場合です。そのため、まずはそのIssueが作成された場合どのWorkflowが動作するべきだったかを確認します。確認の方法については、残念ながらすべてのWorkflowを地道に確認することしかできません。そのため、Workflowを作成する際にアカウントごとにある程度の方針を決めておくのがよいでしょう。例えば、アカウントには1つのWorkflowのみを作成する、やポリシーごとに作成する、です。詳しくは「Relic Solution: アラートワークフローの実装パターン」を参照してください。

調べるポイントとしては、Workflowに設定されている「Filter data」の条件です。この条件と発生したIssueのPayload（前の図の⑤）を比べて、Workflowが発動すべきだったかどうかを判断します。

通知するべきWorkflowがあるのに通知されなかった場合、あるいはIssueの通知の宛先のアイコンに取り消し表示がある場合、Muting Ruleにより通知が抑止された可能性があります。Muting Ruleはアカウント単位での設定と、Workflow単位での設定の両方が可能になっているため、両方を確認する必要があります。

Muting Ruleの設定方法の詳細についてはドキュメントを確認してください。https://docs.newrelic.com/docs/alerts-applied-intelligence/new-relic-alerts/alert-notifications/muting-rules-suppress-notifications/#workflow-behavior

Muting Ruleでの抑止も該当しない場合、Grace Periodによる設定が考えられます。特にIssueが生成されたからすぐにクローズされたケースで通知が来なかった場合、Grace Periodにより通知されなかった可能性があります。

Alerts & AIのSETTINGS>Generalのメニューを開き確認します。

Grace Periodの期間内にクローズしたため通知がこなかったケースで、通知を受け取りたい場合、まずGrace Periodの期間を短くする変更が考えられます。この場合、Grace Periodの設定がアカウント単位であることに注意してください。

また、アラート条件単位で「Correlate and suppress noise」のチェックを外すことでGrace Periodの設定を適用されないようにすることもできます。

詳しくはこちらのドキュメントを参照してください。

https://docs.newrelic.com/jp/docs/alerts-applied-intelligence/applied-intelligence/incident-intelligence/user-settings/

アラート条件を調べる

通知が来ると期待したのに来なかった場合で該当するIssueがない場合、あるいは来るべきでない通知が来た場合はアラート条件を調べます。前者の場合は検知すべきアラート条件がなぜアラート条件違反を検知しIssueを生成しなかったのか、後者の場合はIssueを生成したアラート条件がなぜアラート条件違反を検知しIssueを生成したのかを調べます。

ところでアラート条件に関する調査は多くの場合、NRQLによる調査が必要です。そのため、今回はいくつか見るべきポイントを挙げることにします。NRQLによる調査を含むより詳しい調査方法は後日公開します。

そのアラート条件が含まれるアラートポリシーのIssue Preferenceの設定によっては、すでにIssueが作成されている場合、別のアラート条件で違反が発生しIncidentがオープンになっても、作成済みのIssueにマージされ新たなIssueは生成されず、通知も行われないことがあります。Issue Preferenceについてはドキュメントを参照ください。https://docs.newrelic.com/jp/docs/alerts-applied-intelligence/new-relic-alerts/alert-policies/specify-when-alerts-create-incidents/

アラート条件の評価はNRQLでクエリする保存されたデータを対象にしているわけではありません。以下の図で示されていStreaming dataというのがアラート条件の評価のデータソースですが、これはNew RelicにIngestされたデータがNRQLでクエリするために保存するデータと独立して処理されます。特にデータに遅延があった場合（イベントやメトリクスのもつタイムスタンプとNew RelicにIngestされた時間が大きくずれている場合）、アラート評価のタイミングではデータは存在していないのに、Ingestが完了したあとにNRQLでクエリするとデータが存在しているため、アラート評価とNRQLでのクエリ結果がずれることになります。遅延の大きいデータがある場合は特に注意ください。

アラート条件の編集ページにあるプレビューによるアラートの判定はLoss of Signalなど考慮していない項目があるため、必ずしも正しいとは限りません。プレビューでアラート条件に違反している（していない）のにIssueが生成されない（される）、という判断は間違っている可能性があります。

NRQLアラートでは、WHERE句に該当するイベントやメトリクスが存在しない場合、NULL値として評価されます。NULL値はアラート条件の違反したともしないとも判定しないため、Incidentが起きていない状態でNULL値であればIncidentはオープンされませんし、Incidentがオープンの状態でNULL値であればオープン中のIncidentはクローズされません。例えば、エラーログの検出など、普段は存在しないが存在したときにアラートを通知したいというケースが該当します。詳しくはドキュメントを参照ください。https://docs.newrelic.com/jp/docs/alerts-applied-intelligence/new-relic-alerts/alert-conditions/create-nrql-alert-conditions/#example-null

NRQLアラート条件のstreaming aggregation methodはデータの性質に応じて適切な方法を選ぶ必要があります。ここでいう性質とは、イベントやメトリクスのもつタイムスタンプとそれがNew RelicにIngestされるタイミングに関する性質です。端的にいえば、イベントやメトリクスのタイムスタンプとIngestされるタイミングが0に近く常にほぼ一定の値であればEvent flowが適しています。一定期間のデータを一定間隔でまとめて送信している場合、タイムスタンプとIngestされるタイミングがデータによって異なりますが、この場合はEvent Timerが適しています。また、データのタイムスタンプが実際の時間と大きくずれている場合、つまりMobileやBrowserなど端末の時刻が信頼できない場合はCadenceが適している数少ないケースとなります。詳しくはドキュメントを参照してください。https://docs.newrelic.com/jp/docs/alerts-applied-intelligence/new-relic-alerts/advanced-alerts/understand-technical-concepts/streaming-alerts-key-terms-concepts/

Gap-filling strategyを設定している場合、埋められるギャップの最長期間は2時間です。それ以上データが存在しない場合にはギャップを埋める動作は行われません。https://docs.newrelic.com/jp/docs/alerts-applied-intelligence/new-relic-alerts/alert-conditions/create-nrql-alert-conditions/#data-gaps

まとめ

今回まとめた調査方法は、お客様ご自身で解決する場合はもちろんですが、テクニカルサポートにお問い合わせいただくときの初期情報としても重要なものです。必要な情報を最初にいただければ、より迅速な問題解決につなげることができます。ここで再度必要な初期情報をまとめました。

• どのような症状が問題なのか（通知が来ると期待したのに来なかったのか、来るべきでない通知が来た場合のか）
• その症状が起きていた時刻
• 関連すると思われる、アラート条件、アラートポリシー、Issue、Workflow、Muting Ruleを表示するPermalink
• 関連する項目は症状によって異なります。
  • 通知が来ると期待したのに来なかった場合
    • 該当するIssueがあった ⇒ Workflow
      また、通知の宛先のアイコンに取り消し表示がついている場合 ⇒ muting rule
    • 該当するIssueがなかった ⇒ アラート条件、アラートポリシー
  • 来るべきでない通知が来た場合
    • 該当するIssueがあった => アラート条件、アラートポリシー