LogやSyntheticの監視のベストプラクティス

公開済み Updated 所要時間:約 7分

NewRelicを使って、様々なメトリクスの収集や監視を設定されていると思います。監視の設定の中でも、少し特殊でお問い合わせが多いのが、LogやSyntheticのデータをNRQLを使ってアラートを作成されたケースとなります。このブログでは、簡単なベストプラクティスをご紹介します。

お問い合わせでよくあるのが以下のようなものです。

  • Logで特定のメッセージが現れたときに通知を行うように設定したが、期待通りに通知がこない
  • Syntheticsのテストが失敗したけど、期待通りに通知がこない
  • Syntheticsのテストが成功するようになったけど、Incidentが自動でクローズされない。

では、どのような、ポイントに注意して、設定を行えば、通知が期待通りに来るのでしょうか?実際の例を参考にしながら、見ていきましょう。

 

例1)Logで、特定の文字の出現を監視する

LogをNewRelicに連携している場合、特定の文字列が一定数以上、出現したら通知を発生させたいケースがあると思います。例えば、1分間の間隔でみて1回以上、「error」という文字列が発生した場合に、incidentを発生させるためには、どのような設定にすれば良いでしょうか?

まず、NRQLのクエリーは次のようになるになります。

SELECT count(*) FROM Log WHERE message LIKE '%error%'

そして、設定は次のようになります。

ここで、重要なポイントは、赤い矢印で示している箇所で、Streaming methodとして、Event timerを設定する。ということになります。(ほかは監視したい条件に応じて変更してください)

今回利用している、クエリーの場合、正常時の結果は常に、ゼロになります。このようなゼロが続くようなデータで、Event flowを使った場合では、期待通りに動作することはできません。詳細に関しては、こちらのブログを参考にしてください。

例2)Syntheticのテストの失敗を監視する。また復帰後自動でincidentを閉じる

例1では、Logを監視し、incidentを発生するようにすることができました。Logの場合は、自動で閉じる必要がないケースが多いですが、Syntheticの場合は、復旧したら自動でincidentを閉じてほしいでしょう。

では、例1同様に1度失敗で、incidentを発生させ、また成功するようになったら、自動でincidentを閉じるようなコンディションを作成しましょう。

クエリーは先程と大きな違いはないですが、以下のようになります。Syntheticなので、対象のモニターを特定するために、WHERE句にmonitorIdを条件として追加し、成功以外の数を取得するようにしています。(monitorIdの確認方法に関しては、本ブログの後半に記述しています)

SELECT count(*) FROM SyntheticCheck 
  WHERE monitorId = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' 
  AND result != 'SUCCESS'

そして、設定は次のようになります。

ここでも、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を発生させることができません。そうしたケースも監視したい場合は、どうするのがよいのでしょうか?

具体的なクエリーや設定画面は以下の通りになります。

SELECT count(*) FROM SyntheticCheck 
  WHERE monitorId = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' 
  AND result = 'SUCCESS'
alert condition synthetic 2

ポイントは以下の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を選択した状態で、画面右側に表示されるので、そちらで確認いただけます。