New Relic Alertのニッチ？な機能 Enrichmentでアラート対応を自動化する件

この記事は[New Relic Advent Calendar 2023](https://qiita.com/advent-calendar/2023/newrelic) シリーズ1の12日目です。
## Enrichmentってなに。なにができるの。
便利な割に全然使われている感じがしないEnrichmentですが、こいつはなんなのというのをひとことで言うと、
`監視のアラート発報時、通知先にAlert conditionとは別のNRQLの実行結果を追加する機能`です。

すぐには理解できませんよね。
ポイントは、**自動化に超便利**、**Notificationに任意の別のNRQLの結果を追加して別の処理に繋げられる**ことです。変わってない？

監視をやっていてアラートへの対応を自動化したいと思っても、conditionのNRQLの結果だけだと、conditionは具体的な値を取得するNRQLではないはずなので、自動化処理をしたい対象を限定できません。Enrichmentを追加するとその対象の具体的な値を追加して通知できるというわけです。

### 使い始め方
<img width="600" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3591236/0ace0417-748c-4e7f-79da-db46e2717fd9.png">

Workflowの編集画面で追加できます。こちらの公式Blog記事も参照いただくといいかもしれません。
[WorkflowのWebhookでリッチな通知を作成する ](https://newrelic.com/jp/blog/how-to-relic/workflow-rich-webhook)

### データフォーマット
* 通知先がslackの場合
EnrichmentのNRQLの結果が画像で追加で添付されます。
あくまで目視用途になりますが、これだけでも楽になる運用はあるはず。画像じゃなかったらもっと嬉しいけど。
<img width="400" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3591236/559cf22c-a9d5-7b99-43b7-704b8457c615.png">

* 通知先がAWS EventBrigeやwebhookの場合
通知そのものがJSONフォーマットのデータとして送信されEnrichmentの結果も一つのJSON内に文字列で含まれます。そのため、値を使って別の処理を始められるというわけです。
![キャプチャ3.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3591236/2ed3a691-b571-2724-b608-65acf717ae42.png)
NRQLはデタラメにしてますが、こんな感じで設定すると、
Name your queryの値`arackIpaddr`とAS句の`ipaddr`がJSON内に放り込まれているので、送った先でパースできます。
☆のところです。なお、中略しない場合JSONとっても長いです。
~~~
{
    "version": "0",
    "id": "xxxxx",
    "detail-type": "NewRelicEvent",
    "source": "xxxxx",
    "account": "xxxxx",
    "time": "2023-12-10T13:29:12Z",
    "region": "xxxxx",
    "resources": [],
    "detail": {
        "test": {
            "name": "json",
            "hash": {},
            "data": {
                "root": {
                    "closedIncidentsCount": 1,
                    "issueActivatedAt": "2023-11-30T10:14:18.128Z",
                    "accumulations": {
                        "origin": "newrelic",
                        "nrqlQuery": [],
                        "conditionProduct": [
                            "NRQL"
                        ],
                            中略
                    "atackIpaddr": [
                        {
                            "timestamp": 1702189909717,
                            "ipaddr": "x.x.x.x"     ← ☆このように受け取れる
                        }
                    ],
                    "renderedEnrichers": [
                        {
                            "enricherName": "atackIpaddr",
                            "imageUrl": "xxxxx",
                            "rawImageUrl": "xxxxx",
                            "queryUrl": "xxxxx"
                        }
                    ],
                            中略
            }
        }
    }
}
~~~
## 具体的な利用例
この利用例では、DDoS攻撃と見なしたIPアドレスからのアクセスを拒否するために、Network ACLに対象のIPアドレスを追加します。

運用システム自体がAWS上に構築されていることもあり、自動化にはAWS Lambdaを使用します。
<img width="" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3591236/f634b792-4c36-4da6-a663-d69fbdfe386e.png">
Workflowで、Alert通知時にEnrichmentで追加したNRQLの結果をEventBrigeに連携するように設定します。これはWorkflowsがガイダンスで教えてくれます(EventBrigeのUIが分かりづらいのもあって一筋縄ではいかないですが)
EventBrigeではLambdaに接続し、Lambdaで通知結果をJSONデータとして受け取って、そのあとは好きなように加工します。ライブラリの問題でPythonがおススメです。

この先の詳細はもはやNew Relicの話ではなくLambdaとAWSCLIとNACLの話なので割愛しますが、この仕組みによって、DDoSをNew Relicで監視し、被攻撃時に直ちに対象IPアドレスからのアクセスを拒否することができるようになりました。

他にも、Lambdaの後ろにAmazon Connect(電話番号持ったり電話かけてIVR応答したりできる)を接続して、notificationに伴って担当者へ発呼する仕組みも作りました。Lambdaに渡せばなんでもできる。監視の自動化楽しい！

## おわりに
わたしの所属している会社だと、分業が激しいので監視部門で開発めいたことをするのはなかなか難しいんですが、現業を打開したい監視エンジニアの方の参考になれば幸いです。

Qiitaはじめて書いたので、これを機に2024は知ってることをdumpしていこうかなという目標を持ったので、書いてよかったねということで締めとさせていただきます。