NewRelic導入時の監視設計

NE株式会社開発統括部所属の大嶋([@atsusics](https://twitter.com/atsusics)) です。 
この記事は[New Relic Advent Calendar 2022](https://qiita.com/advent-calendar/2022/newrelic)1７日目の記事になります。

# 概要
弊社では今年からサーバー監視ツールをNewRelicに切り替えました、その際にNewRelicの機能に合わせ監視設計見直しを行いました。その時に考えたことを紹介させていただきます。

# 前提情報
## ネクストエンジン
弊社ではEC運営支援プラットフォームである[ネクストエンジン](https://next-engine.net/)を提供しています
このプロダクトは大きく分けると3つに分類することができます

- メイン機能
    - ネクストエンジンで提供される基本的な機能
- プラットフォーム
    - ログイン、サポート用の機能
- 各種アプリ
    - 各種モール専用アプリ、効率化アプリなど

それぞれAWS上で稼働しており、アラート対応などについてはSREメンバーだけでなく、アプリケーションエンジニアと協力して対応しています。

以前の監視設計でもSlack通知する際のルールを決め設計していたが、運用していく中でいくつか課題が浮き彫りになってきました。
そこで、NewRelic導入のタイミングで再度監視設計をしました。
<br>


<script async class="speakerdeck-embed" data-slide="31" data-id="8f672b5aee934099b2a7af40869cf4dd" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>


# 課題

- 「アラートが鳴っている（Alert or Notify）」と「Alertチャンネルで鳴っている」がわかりづらかった
    - ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/261535/a2975464-5375-8910-578b-84fbb3459db8.png)
- 要対応としていてユーザー影響が出るものをAlertチャンネルに通知するとしていたが、雑多なアラートが増え、さまざまなAlertチャンネルが乱立することで狼アラートの増加やSlackチャンネルの不参加による障害検知遅れの可能性が高まってきた
- NewRelicでは閾値設定でCritical、Warningとなるので、Slackチャンネルとの紐付けわかりづらくなる恐れがあった
    - ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/261535/45546450-4fed-0bf3-b87c-703b1b1609ba.png)
- ユーザー影響がなく緊急性はないが、作業が必要なタスクが漏れてしまうこ恐れがあった

# 解決策
## 概要

> プロダクトは大きく分けると3つに分類することができます
> - メイン機能
>     - ネクストエンジンで提供される基本的な機能
> - プラットフォーム
>     - ログイン、サポート用の機能
> - 各種アプリ
>     - 各種モール専用アプリ、効率化アプリなど

としているので、通知も大きく3つに分け、それぞれに閾値criticalに対応したcritical_XXXX、閾値warningに対応したwarning_XXXXの合計６個のSlackチャンネルにアラート通知をするようにした。


また、
> ユーザー影響がなく緊急性はないが、作業が必要なタスクが漏れる

を解決するために、弊社で採用しているタスク管理ツールAsanaにNewRelicから直接タスク作成するようにした。

## 概要図
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/261535/a4866973-7017-cbe8-70b7-8718902eb6de.png)

次からは各項目について続けていきます

## Slackチャンネル
それぞれの違いは以下に記載しています。
共通するのは温度感が違うにしても、対応が必要なものだけを通知している点です
すぐに対応が必要でないものはAsanaにタスクするようにしています

### critical_XXXX
ユーザー影響が出ている場合に通知されるチャンネル
基本的には通知がならない（ようにしたい！）。逆に通知された場合は障害として最優先で対応する

#### 参加者
- エンジニア
- カスタマーサクセスメンバー
- 営業メンバー

といったエンジニア以外も参加

### warning_XXXX
ユーザー影響が出ていないが何かしらの対応が必要な場合に通知されるチャンネル
通知されたら障害になる前にエンジニアが対応する

#### 参加者
- エンジニア

基本的にはエンジニアのみ参加＋任意

## Policy
以下4つを作成する

- Asana
- MainFunction
- Platform
- Apps

## Condition
各Policy内にConditionを作成していく
基本的には本番環境のみを監視する。
AWSであれば、newrelic.cloudIntegrations.providerAccountName で絞っていく

以下２パターンがある
- 閾値を１つだけ設定
    -  Slack通知する場合はcritical_XXXXに通知されるので、１発でユーザー影響があるようなものの場合はこのパターン
    -  Asanaにタスク追加するものもこのパターン
- 閾値を2つ設定
    - 閾値warningを違反した場合はwarning_XXXXに通知される
    - 閾値criticalを違反した場合はcritical_XXXXに通知される
    - なので、閾値criticalはかなり厳しめに設定しておき、warningで問題を早めにキャッチアップし対応、本当にやばい時はcriticalで検知し障害として対応


## Workflow
### Slack通知
2（Critical,Warning）＊3（Mainfunction,Platfrom,Apps）
=6個
の組み合わせで作成する

それぞれ、Policy（policyName）と閾値（priority）をフィルターに設定することで、特定のPolicy内の特定の閾値ごとに通知するSlackチャンネルを分けることができる

例：
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/261535/317dbaff-94b7-2a04-0b6d-c07a9de389f3.png)

### Asanaタスク追加
PolicyをAsanaに絞り、webhookからタスク追加
（詳細は後日）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/261535/852fb7f2-db41-c511-4062-9220fc3de5a4.png)

# まとめ

NewRelicのCondition、Workflow等の設定項目から素直に監視設計したものを紹介させていただきました。
この記事が少しでも監視設計をする際に役に立てればと思っております。
またもし、もっと良い方法など知っている方はご教授いただけると嬉しいです！