New RelicのSyntheticsモニタリングをモニタリングしてみた


# 概要
​
New Relicのモニタリング機能の１つである[Syntheticsモニタリング](https://docs.newrelic.com/jp/docs/synthetics/synthetic-monitoring/using-monitors/alerts-synthetic-monitoring/)の動作をモニタリングしてみました。
Syntheticsに常にエラーを返すURLを監視させ、インシデント・イシューが作成される様子、イシューからNotificationが送信される様子を観察しています。
​
## 目的
- 安定した監視を行い、最適なチューニングをするためモニタリング設定、アラート条件、それにより生成されるインシデント・イシュー、Notificationの様子自体を学び把握すること。
- [New Relic自体のSLA](https://docs.newrelic.com/docs/licenses/license-information/referenced-policies/service-level-availability-commitment/)も100%ではありません。Statusページの情報以外に、きめ細かく実際の状況を把握・記録しておきたいという意図もあります。

​
# システム構成
​
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/331389/6aee3524-e6a1-2196-99a1-82e5640f99a8.png)


## 解説

1. New Relicで、「必ずHTTPステータス500を返すURL」を1分間隔で監視し、1分に1回程度アラートを発生させる。アラートの通知にはworkflowsとdestinations方式を使用しています。
1. アラート発生をトリガーにAWS Lambdaを実行し、Invocationメトリクスを監視する。この際、AWS Lambdaでアラートを強制的にResolveする（アラートの自動Resolveまで待機させない）
1. Cloud Watch Alarmで7分間1度もInvocationがない場合は「監視異常」と判定し、Slackに通知。「監視異常」状態が解除されたタイミングで復旧を通知。※数値は適宜チューニングしてます


## 補足

- AWS Lambda上でのアラート解除には、New Relicから提供されている[NerdGraph API](https://docs.newrelic.com/jp/docs/apis/nerdgraph/get-started/introduction-new-relic-nerdgraph/)を使用しています。
    - NerdGraph APIはNew RelicデータにNRQLクエリを実行できるGraphQL形式のAPI。REST APIも提供されているが、NerdGraph APIが推奨されており、REST APIは後々[NerdGraph APIへ統合される予定](https://docs.newrelic.com/jp/docs/apis/intro-apis/introduction-new-relic-apis/#rest-api)だそうです。
    - [NerdGraphエクスプローラー](https://api.eu.newrelic.com/graphiql)というAPIが実行できるGUIが提供されているので組み込む前にテストできて便利でした。
    - 今回使用したAPIはこちら 👉 [aiIssuesResolveIssue](https://docs.newrelic.com/jp/docs/apis/nerdgraph/examples/nerdgraph-issues-api-via-github/#resolve-ack-issues)
    - [NRQLクエリの制限](https://docs.newrelic.com/jp/docs/query-your-data/nrql-new-relic-query-language/get-started/rate-limits-nrql-queries/)内でAPIを呼び出します。
        - アカウントごと、1分あたり3,000クエリが上限

- アラートの解除をするにあたって、New Relic のアラート機能の概念、用語ついてはこちらを参照しました。
    - [アラートの概念と用語](https://docs.newrelic.com/jp/docs/alerts-applied-intelligence/applied-intelligence/incident-intelligence/basic-alerting-concepts/)

​
## 動作確認

今回設定したSyntheticsモニタリングの動作を手動でOFFにしてSlackに通知がくるか確認しました。

1. Syntheticsモニタリングの設定画面より「Monitor enabled」のチェックを外す
![Screen Shot 2023-02-27 at 18.09.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/331389/17a4c47b-1ecd-4f65-fac9-4ef8a7f38509.png)

2. 7分以上経過後、Slackに通知来ました。
![Screen Shot 2023-02-27 at 18.29.31.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/331389/0f4edb2a-75e5-fbd6-7d9e-b57f62ccab23.png)

​
# 学んだこと

- New Relic提供のAPIについての知識
- CloudWatch Alarm周りの知識
- New Relicのアラートポリシー、アラート、イシュー、インシデントの関係
- NRQLの使い方
    - New Relicのダッシュボード機能で、1時間ごとの「Syntheticsでの監視回数」「発生インシデント数」「発生イシュー数」をNRQLでそれぞれ表示して可視化してみました。参考：[New Relicのインシデント/イシューをNRQLでクエリしてみる](https://qiita.com/shu85t/items/eeab52aeb64dc45095a3)

# 稼働させてみて
​
New Relicで 2/17 15:09 - 18:45 JST の間でworkflows経由のアラート通知の遅延が発生しました。
https://status.newrelic.com/

このタイミングで本システムを稼働させていたので、Slackに15:20に異常通知、18:49に復旧通知が来ており、障害発生〜復旧を検知することができていました。

![Screen Shot 2023-02-27 at 18.59.46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/331389/49bef990-13b8-00ed-38e9-8ef7c58fbb56.png)


さまざまな監視サービスを利用するにあたって、障害が起きた場合はいち早く検知することが必要になります。
今回はNew Relicで試してみましたが、他の監視サービスでも同じようなことをやってみたいです。