NewRelicを使って、様々なメトリクスの収集や監視を設定されていると思います。監視の設定の中でも、少し特殊でお問い合わせが多いのが、LogやSyntheticのデータをNRQLを使ってアラートを作成されたケースとなります。このブログでは、簡単なベストプラクティスをご紹介します。
お問い合わせでよくあるのが以下のようなものです。
- Logで特定のメッセージが現れたときに通知を行うように設定したが、期待通りに通知がこない
- Syntheticsのテストが失敗したけど、期待通りに通知がこない
- Syntheticsのテストが成功するようになったけど、Incidentが自動でクローズされない。
では、どのような、ポイントに注意して、設定を行えば、通知が期待通りに来るのでしょうか?実際の例を参考にしながら、見ていきましょう。
例1)Logで、特定の文字の出現を監視する
LogをNewRelicに連携している場合、特定の文字列が一定数以上、出現したら通知を発生させたいケースがあると思います。例えば、1分間の間隔でみて1回以上、「error」という文字列が発生した場合に、incidentを発生させるためには、どのような設定にすれば良いでしょうか?
まず、NRQLのクエリーは次のようになるになります。
そして、設定は次のようになります。
ここで、重要なポイントは、赤い矢印で示している箇所で、Streaming methodとして、Event timerを設定する。ということになります。(ほかは監視したい条件に応じて変更してください)
今回利用している、クエリーの場合、正常時の結果は常に、ゼロになります。このようなゼロが続くようなデータで、Event flowを使った場合では、期待通りに動作することはできません。詳細に関しては、こちらのブログを参考にしてください。
例2)Syntheticのテストの失敗を監視する。また復帰後自動でincidentを閉じる
例1では、Logを監視し、incidentを発生するようにすることができました。Logの場合は、自動で閉じる必要がないケースが多いですが、Syntheticの場合は、復旧したら自動でincidentを閉じてほしいでしょう。
では、例1同様に1度失敗で、incidentを発生させ、また成功するようになったら、自動でincidentを閉じるようなコンディションを作成しましょう。
クエリーは先程と大きな違いはないですが、以下のようになります。Syntheticなので、対象のモニターを特定するために、WHERE句にmonitorIdを条件として追加し、成功以外の数を取得するようにしています。(monitorIdの確認方法に関しては、本ブログの後半に記述しています)
そして、設定は次のようになります。
ここでも、Streaming methodにEvent timerを設定していることも重要なのですが、赤枠で囲まれたLost signalの設定を追加していることがポイントになります。コンディションの設定画面で + Add lost signal threshold をクリックしてもらうことで追加ができます。設定を追加し、Close all current open violationsにチェックを入れることで、復帰時にincidentを自動でクローズすることができます。
詳細は、こちらを参照していただくと書かれているのですが、count(*)
のクエリーを用いた場合で結果がゼロの場合、NULLとして扱われます。そのため、復帰時はシグナルが喪失したときの条件に該当し、incidentを自動で閉じていただくことができます。
例3)Syntheticのテストが止まった場合もincidentを発生させる
例えば、設定を誤って消してしまったことや無効にしたままだったなど、記憶にある方もいるのではないでしょうか。例2で書いたケースの場合、成功以外の数を数えているので、もしSytheticの実行を止めてしまって、そもそもSyntheticが実行されていなかった場合、incidentを発生させることができません。そうしたケースも監視したい場合は、どうするのがよいのでしょうか?
具体的なクエリーや設定画面は以下の通りになります。

ポイントは以下の2つです。
- クエリーで成功の数を数える
- 失敗の数で判断すると、止まったときと成功時とが同じ値(ゼロ)になってしまいます。成功の数を数えることで、失敗と停止を同じこととして判断することができます。
- Open new "lost signal" violationにチェックを入れる
- 失敗し、成功が判定のウィンドウになかった場合、ゼロ(NULL)になります。そのため、この条件を使って、失敗時やテスト停止時にincidentを発生させるようにします。
- なお、完全にゼロにならないケースもあることにも注意してください。例えば、判定のウィンドウで通常は、2回成功がある場合で、1回のみ失敗したケースです。その場合は、この設定でincidentを発生させることはできないので、通常通り、Open violation when the..に続く設定で適切な値を設定することも忘れないでください。
また、勘の良い方は、Streaming methodがEvent flowに変わっていることに気づいたかもしれません。今までの例と違って、成功の回数を見るようにクエリーを変更したので、通常時の値がゼロではなくなったからです。Event timerでも動作はしますが、継続してデータが発生する場合は、Event flowを選択するのが推奨になります。理由が気になる方は、こちらのブログを参照してみてください。
参考:モニターIDの確認方法
本ブログでSyntheticのクエリーの条件として、monitorIdでSyntheticを特定しました。monitorNameを使うとわかりやすいかもしれませんが、monitorNameは設定であとから変更ができ、変更された場合は監視が期待通りに動作しなくなります。そのため、一意なmonitorIdを条件に追加しました。monitorIdはSyntheticsの画面で、対象のSynetheticテストを選択後、左側のメニューでSummaryを選択した状態で、画面右側に表示されるので、そちらで確認いただけます。
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.