New Relicでの通知設計を考える

ゲームソリューション部の出村です。

4月になり、新しい部署や新しい業務でこれからNewRelicを活用していくという方もいることでしょう。ということで、基本に立ち返って通知設計について考えておくべき点や、NewRelicをどのように活用していけばよいのか、について書いていきます。

通知に必要な要素とは？

通知を設計する際には、最初に通知の目的を明確化します。目的とは「利用者が通常通り利用できているかを知るため」、「ビジネス的なメトリクスを知るため」など様々な事が考えられます。

それらを決めた後、以下の3点を明確にします。

• 監視対象を決め、どのような条件になったら通知するのか？
• どのような手段で通知するのか？
• 誰に通知を届けるのか？

この3つの要素を整理することで、過不足のない通知を実現できます。

条件の設計

まずは、「監視対象」に対して「どのような状態になったら通知するか」を定義する必要があります。通知の精度を高めるには、以下のような観点で条件を設計し、それぞれに対応するNew Relicの機能を活用することが重要です。

どのメトリクスを見るのか？

通知のトリガーとなるメトリクスを選定します。例えば、WebサーバーであればCPU使用率、レスポンスタイム、エラーレートなどが一般的です。

New Relicの機能と監視対象は以下の様になっています。

• Infrastructure Monitoring ：ホストやコンテナのCPU、メモリ、ディスク使用率などのリソースメトリクスを監視。
• APM（Application Performance Monitoring）：アプリケーションのレスポンスタイム、スループット、エラーレートなどを取得。
• Synthetic Monitoring ：サーバーへのアクセス状況を監視
• Browser Monitoring ：フロントエンド側のパフォーマンスや可用性を監視可能。

しきい値はいくつに設定するか？

通知を出す基準となるしきい値（閾値）を設定します。高すぎると問題を見逃し、低すぎるとノイズが増えるため、適切な値の設定が重要です。固定値ではなく、過去の値と比較した異常値を検出することで、本当に重要な異常を見逃さないようにすることもできます。

New Relicでの対応機能：

• Static Thresholds（静的しきい値）：固定値を使って設定。例：CPU使用率が80%を超えたら通知。
• Anomaly Thresholds（異常しきい値）：過去のパフォーマンス傾向に基づいた動的なしきい値。異常検知に有効。

条件は1つか？複数か？

単一の条件で通知を出すのか、複数の条件を組み合わせるのかを検討します。複数の条件を組み合わせることで、より精度の高い通知が可能になりますし、通知を集約することで細かく大量の通知がくることも防げます。

New Relicでの対応機能：

• NRQL Alerts（New Relic Query Language）：複数の条件や属性を組み合わせた柔軟なアラート条件の定義が可能。
  • 例：レスポンスタイムが2秒以上かつエラー率が5%以上のときに通知
• Alert Policies：1つのポリシーに複数の条件を設定し、グルーピングする方法

無視したい条件があるか？

夜間のバッチ処理やメンテナンス中など、一時的に通知を抑制したいケースがあります。こうした「通知不要なタイミング」を考慮することも重要です。

New Relicでの対応機能：

• Muting Rules（ミュートルール）：
  • 特定の時間帯やタグなどのアラートの設定項目と一致したアラートを、一時的に無効化。

補足：NRQL Alertsとは？

NRQL（New Relic Query Language）は、New Relicのデータベース（NRDB）に対してクエリを発行するための言語です。NRQLを使えば、通常のアラート条件では表現できないような複雑な条件も定義できます。

通知手段の選定

通知の手段は状況に応じて使い分けることが重要です。さまざまな通知方法がありますので、それらを緊急度にあわせて使い分ける必要があります。

通知手段の例：

• Slack
• メール
• JIRA（チケット起票）
• PagerDutyやOpsgenieなどのアラート管理ツール

緊急度に応じた使い分け例：

緊急度	通知手段	対応例
高（即時対応）	電話、Slack（モバイル通知）	インフラ障害、サービス停止
中（当日中対応）	Slack、JIRA	エラー率上昇、パフォーマンス劣化
低（情報共有）	メール、週次レポート	軽微な異常、改善提案

誰に通知を送るべきか？

通知は、正しい人に届くことが最も重要です。基本的には監視・運用を担当しているエンジニアに通知がいきますが、場合によってはサービス責任者にも通知が必要な場合もあるでしょう。

• 担当インフラエンジニア
• 担当開発エンジニア
• サービス責任者（SREやプロダクトマネージャー）

通知内容や緊急度に応じて、通知先を柔軟に切り替える設計が求められます。

適切に伝える：通知の質を高める

通知の「量」だけでなく、「質」も非常に重要です。適切な情報を含めることで、受信者がすぐに状況を把握し、迅速な対応につなげることができます。

含めるべき情報とNew Relicでの設定方法：

• ■ 何が起きたか（アラート名、メトリクス名）

→ アラート条件（Condition）に名前を付けておくことで、通知にその名前が表示されます。${condition_name} や ${metric_name} などの変数を使って、通知テンプレート内に含めることが可能です。

• ■ いつ起きたか（タイムスタンプ）

→ 通知メッセージには自動的に発生日時が含まれます。Slack通知では ${timestamp} を使って明示的に表示可能です。

• ■ どこで起きたか（ホスト名、サービス名）

→ 通知対象のエンティティ（ホスト、アプリケーションなど）に設定されたタグや名前を ${entity.name} や ${tags} で通知に含めることができます。

• ■ どのような影響があるか（ユーザー影響の有無）

→ アラート名やポリシー名に「ユーザー影響あり」などを明示することで、通知上で把握可能となります。

• ■ 次に何をすべきか（Runbookリンク、対応手順）

→ 各アラート条件にRunbook URLを設定できます。通知内にそのリンクが表示され、担当者がすぐに対応手順にアクセスできます。ConfluenceやNotionなどのドキュメントと連携するのが効果的です。

通知の優先度を設定しよう

通知には「レベル」を持たせるのが効果的です。以下は3段階で設定した場合です。必要であれば段階数を増やすとよいでしょう。

レベル	内容	対応
Critical	即時対応が必要	PagerDutyなどで即通知
Warning	注意が必要	Slackで通知、業務時間内に対応
Info	参考情報	メールやレポートに記載

New Relicでは、アラートポリシーや条件ごとに通知レベルを命名・分類することで、優先度の管理が可能です。

通知のレビューと改善

通知は一度作って終わりではありません。

• 定期的にアラートレビュー会を開き、不要な通知や過剰な条件を見直しましょう。
• テスト通知を行い、実際に通知が届くか、内容が正しいかを確認しましょう。
• New RelicのMuting RulesやIncident Intelligenceを使って、通知のノイズを抑えることも可能です。

まとめ

適切な通知設計は、システムの安定運用と開発チームの生産性を守るために不可欠なものです。適切な通知設計は、開発・運用メンバーの生活に安寧をもたらします。

ですので、New Relicの機能を活用しながら、「何を、誰に、どう伝えるか」をしっかり設計しましょう。