概要
New Relicのモニタリング機能の１つであるSyntheticsモニタリングの動作をモニタリングしてみました。
Syntheticsに常にエラーを返すURLを監視させ、インシデント・イシューが作成される様子、イシューからNotificationが送信される様子を観察しています。
目的
- 安定した監視を行い、最適なチューニングをするためモニタリング設定、アラート条件、それにより生成されるインシデント・イシュー、Notificationの様子自体を学び把握すること。
- New Relic自体のSLAも100%ではありません。Statusページの情報以外に、きめ細かく実際の状況を把握・記録しておきたいという意図もあります。
システム構成
解説
- New Relicで、「必ずHTTPステータス500を返すURL」を1分間隔で監視し、1分に1回程度アラートを発生させる。アラートの通知にはworkflowsとdestinations方式を使用しています。
- アラート発生をトリガーにAWS Lambdaを実行し、Invocationメトリクスを監視する。この際、AWS Lambdaでアラートを強制的にResolveする（アラートの自動Resolveまで待機させない）
- Cloud Watch Alarmで7分間1度もInvocationがない場合は「監視異常」と判定し、Slackに通知。「監視異常」状態が解除されたタイミングで復旧を通知。※数値は適宜チューニングしてます
補足
-
AWS Lambda上でのアラート解除には、New Relicから提供されているNerdGraph APIを使用しています。
- NerdGraph APIはNew RelicデータにNRQLクエリを実行できるGraphQL形式のAPI。REST APIも提供されているが、NerdGraph APIが推奨されており、REST APIは後々NerdGraph APIへ統合される予定だそうです。
- NerdGraphエクスプローラーというAPIが実行できるGUIが提供されているので組み込む前にテストできて便利でした。
- 今回使用したAPIはこちら 👉 aiIssuesResolveIssue
-
NRQLクエリの制限内でAPIを呼び出します。
- アカウントごと、1分あたり3,000クエリが上限
-
アラートの解除をするにあたって、New Relic のアラート機能の概念、用語ついてはこちらを参照しました。
動作確認
今回設定したSyntheticsモニタリングの動作を手動でOFFにしてSlackに通知がくるか確認しました。
-
Syntheticsモニタリングの設定画面より「Monitor enabled」のチェックを外す
-
7分以上経過後、Slackに通知来ました。
学んだこと
- New Relic提供のAPIについての知識
- CloudWatch Alarm周りの知識
- New Relicのアラートポリシー、アラート、イシュー、インシデントの関係
- NRQLの使い方
- New Relicのダッシュボード機能で、1時間ごとの「Syntheticsでの監視回数」「発生インシデント数」「発生イシュー数」をNRQLでそれぞれ表示して可視化してみました。参考：New Relicのインシデント/イシューをNRQLでクエリしてみる
稼働させてみて
New Relicで 2/17 15:09 - 18:45 JST の間でworkflows経由のアラート通知の遅延が発生しました。
https://status.newrelic.com/
このタイミングで本システムを稼働させていたので、Slackに15:20に異常通知、18:49に復旧通知が来ており、障害発生〜復旧を検知することができていました。
さまざまな監視サービスを利用するにあたって、障害が起きた場合はいち早く検知することが必要になります。
今回はNew Relicで試してみましたが、他の監視サービスでも同じようなことをやってみたいです。