はじめに
New Relic Alert は、異常を検知して通知するだけでなく、関連するイベントを集約し、適切な担当者へ通知するための仕組みを提供します。アラート設計では、監視条件設定、異常判定基準、Issue(インシデント)の集約方法、通知先の制御など、複数の要素を適切に設計する必要があります。
本記事では、New Relic Alertの基本構造を理解したうえで、アラート条件の設計、ノイズ削減の考え方、Issueの集約方法、通知設計について説明します。これにより、運用に必要なアラートのみを適切な担当者へ通知し、アラート疲れを防ぎながら効率的な運用を実現することを目的とします。具体的な設定については、別の記事にて紹介します。
New Relic Alertの全体像
New Relic Alertは、単にしきい値を超えたら通知する仕組みではありません。監視対象のデータを評価し、異常を検知し、その結果をIssueとして集約したうえで、適切な担当者へ通知する仕組みになっています。これにより、同じ障害に起因する大量のアラートを整理しながら、対応が必要な問題を迅速に把握できます。各機能を説明する前にまずは全体像を確認します。
アラートの処理フロー
New Relicでは、まず監視対象ごとにAlert Policyを作成します。Alert Policy配下には複数のAlert Conditionを定義でき、それぞれがレスポンスタイムやエラー率などの異常判定を行います。Conditionのしきい値違反が発生すると Alert Eventが生成され、関連イベントはIssueとして集約されます。その後、Workflowにより通知先を判定し、PagerDutyやTeamsなどへ通知します。
Telemetry Data
監視対象から収集したデータです。以降のアラート判定は、この監視データを基に実施されます。
・Metric（CPU、メモリ、レスポンス時間など）
・Event（アプリケーションイベント）
・Log（ログ）
・Trace（トレース情報）
Alert Policy
Alert Policyは監視設定を管理する単位です。
まず監視対象ごとにAlert Policyを作成し、その配下に複数のAlert Conditionを定義します。Alert Policyが異常を判定するのではなく、配下のAlert Conditionが異常判定を実施します。
Alert Condition
Alert Conditionは実際に異常判定を行うルールです。
監視対象、異常判定基準（Threshold）、重要度（Critical / Warning）、評価期間（Window Duration）などを設定し、どの状態を異常とみなすかを定義します。設定した条件に一致するとAlert Eventが生成されます。
Alert Event
Alert Conditionで設定した基準を超えた場合に生成されるイベントです。この段階ではまだ担当者への通知は行われず、異常が発生したというイベントを生成する段階です。
Issue（関連イベントを集約）
Issueは、複数のAlert Eventをまとめて管理する単位です。同じ障害に起因する複数のAlert Eventが発生した場合、個別に通知するのではなく1つのIssueとして集約できます。これにより不要な通知を削減し、運用担当者が障害全体を把握しやすくなります。
WorkFlow（通知先ルーティング）
Workflowは、発生したIssueをどこに通知するかを判定する仕組みです。Issueの内容や重要度に応じて通知先を振り分けます。監視設定とは独立して管理できるため、通知先を変更する場合でもAlert PolicyやAlert Conditionを変更する必要はありません。
Destination(通知先定義)
Destinationは、PagerDutyやMicrosoft Teams、Email、Jira、Webhookなどの通知先サービスとの接続情報を定義する仕組みです。通知先のURLや認証情報、送信先チャネルなどを管理し、Workflowから参照されます。
Notificaiton（担当者へ通知）
Notificationは、Workflowで選択されたDestinationに対して実際に通知を送信する処理です。通知を受信した運用担当者やオンコール担当者はIssueの内容を確認し、障害対応や原因調査を開始します。PagerDuty、Microsoft Teams、Email、Jira、Webhookなどのさまざまな通知チャネルを利用できます。
アラート条件設計
アラート条件は、「どの値が」「どの程度」「どれくらい継続したら」異常と判断するかを設定する機能です。条件を設定することで、誤検知を減らしながら重要な障害を検知できます。どのような設計ができるのかを見ていきます。
監視対象の選定
New Relicではサーバ、アプリケーション、クラウドサービス、ネットワークなど、さまざまな対象を監視できます。まずは監視したい対象を選択し、その対象に対するアラート条件を設定します。
| 監視対象 | 監視例 |
| Hosts | CPU、メモリ、ディスク |
| Services(APM) | 応答時間、エラー率 |
| Browser | 表示速度、JavaScriptエラー |
| AWS / Azure | クラウドリソースの状態 |
| Synthetics | Webサイトの疎通確認 |
| Workloads | サービス全体の状態把握 |
監視方針の設計(Alert Policy)
アラート発生時に、どの単位でIssueを作成し通知するか、方針の設計をします。New Relicでは、One issue per policy、One issue per condition、One issue per condition and signal を選択でき、通知数と切り分け粒度のバランスを調整できます。
| 設定 | 適したシーン | メリット(一例) | デメリット(一例) |
| One issue per policy | サービス全体を1つの障害として管理したい場合 例：ECサイト全体の障害監視 |
・通知数を最小限にできる | ・原因の切り分けに時間がかかる ・どの監視項目やホストが問題か分かりにくい |
| One issue per condition | CPU、メモリ、応答時間など原因別に管理したい場合 例：インフラ運用チーム |
・原因別に調査を進めやすい | ・ホスト単位では識別できない ・サーバ台数が多い環境では影響範囲が分かりづらい |
| One issue per condition and signal | ホスト単位やサービス単位で担当を分けたい場合 例：PagerDuty連携、大規模運用 |
・障害箇所をすぐ特定できる ・担当チームへ振り分けしやすい ・Jiraチケット化しやすい |
・Issue数が増える ・通知が多くなりやすい |
監視方針の設計(Alert Condition)
Alert Policyで通知の管理単位を定義した後は、どのような条件で異常と判断するかを設計します。Alert Conditionでは監視対象のメトリクスやイベントに対して、しきい値や評価方法を設定し、アラート発報のルールを定義します。以下は一例です。
| アラートポリシー観点例 | アラートコンディション例 | 使用対象 | 目的・利点 |
| サービス単位(ユーザー視点) | レスポンスタイム、エラーレート、スループット | Webアプリ、APIサービス | サービス全体の健全性を総合的に監視 |
| インフラ単位(システム視点) | CPU使用率、メモリ使用率、ディスクI/O | ホスト、VM、コンテナ | リソースの過負荷や障害の予兆を検知 |
| チーム単位(運用体制視点) | Webエラー率、DB接続エラー、バッチ異常終了 | 開発チーム、DBAチーム、運用チーム | チームの責任範囲ごとにIssueを集約し、通知先を最適化して初動対応を迅速化 |
| 環境別(開発・本番分離) | 本番環境のエラー率、ステージングのデプロイ後の異常 | 環境ごとのアプリやDB | 環境ごとの安定性と品質管理 |
| ビジネス機能別(業務影響) | 決済失敗率、注文処理遅延、ログインエラー | 特定の業務機能 | ビジネスへの影響を最小化するための監視 |
| ユーザー体験別 | ページロード時間、JSエラー数、ブラウザ互換性 | フロントエンド | UXの品質維持と改善 |
| セキュリティ関連 | 異常なログイン試行、DDoS疑いのトラフィック急増 | 認証サービス、ネットワーク | セキュリティインシデントの早期検知 |
ノイズを減らす設計
アラートが多すぎると、重要な障害を見逃してしまう可能性があります。New Relicでは、Window Duration、Sliding Window、Gap Fillingを利用してデータを平滑化し、一時的な変動やデータ欠損による不要なアラートを減らすことができます。ここでは一つ一つ機能についてみていきます。
Windows Duration
Window durationは「何分間のデータをまとめて評価するか」を決める設定です。短くすると異常を早く検知でき、長くすると一時的な変動による不要なアラートを減らすことができます。通知が多ければ、期間を長くし、検知が遅ければ短くすることで、誤検知を抑えながらチューニングする項目です。
| 設定方針例 | 適したシーン | メリット(一例) | デメリット(一例) |
| 短め（1～3分） | Webサービス、APM監視、障害を早く検知したい場合 | ・異常を素早く検知できる ・ユーザー影響を早期に把握できる |
・一時的なスパイクで誤検知しやすい ・通知数が増えやすい |
| 中程度（5～10分） | 一般的なサーバ監視、CPU・メモリ監視 | ・短時間のノイズを吸収できる ・誤検知と検知速度のバランスが良い |
・短時間の障害は検知が遅れる場合がある |
| 長め（10分以上） | バッチ処理監視、周期性のあるシステム、通知ノイズを抑えたい場合 | ・一時的な変動を平滑化できる ・不要なアラートを削減できる |
・障害検知が遅くなる ・短時間障害を見逃す可能性がある |
Slide Window
Sliding Windowは評価区間の境界にまたがる障害や性能劣化を見逃さないための機能です。特に短時間の性能劣化を確実に検知したい場合に有効な設定です。
10:01から10:03の間だけレスポンスタイムが 1,500ms に悪化しています。しかし、Sliding Windowを使用しない場合は 10:00〜10:02 と 10:02〜10:04 のように固定の区間で評価するため、どちらの区間も平均値が 900ms となり、閾値の 1,000ms を超えません。その結果、実際には性能劣化が発生しているにもかかわらずアラートは発生しません。
| 設定方針 | 適したシーン | メリット(一例) | デメリット(一例) |
| 未使用（OFF） | CPU・メモリ監視など安定したメトリクス | ・設定がシンプル ・評価回数が少ない ・不要な計算を増やさない |
・ウィンドウ境界で異常を見逃す可能性がある ・データの変動が大きい場合は検知精度が下がる |
| 使用（ON） | Response Time、Error Rate、トラフィック監視など変動が大きいメトリクス | ・短時間の異常を検知しやすい ・ウィンドウ境界での見逃しを防止できる |
・設定がやや複雑になる |
Gap Filling
監視データは本来一定間隔で収集されますが、通信障害やエージェント停止などにより、一部のデータが取得できない場合があります。この「欠損データ」をどのように扱うかを決めるのが Gap fillingです。
| 機能 | 説明 |
| 欠損のまま（None） | 欠損データがある場合に違反のアクションを起こしたくないケースに適しています。 欠損データはそのまま 欠損データ（Null）として扱われます。 例：エラー数、リクエスト数などのカウント系メトリクス |
| 固定値（Custom static value） | 妥当な固定値はケースによる。欠損した場合に違反の方に倒す、安全サイドに倒す、もしくは対象メトリクスに応じた値。 例：スループット |
| 前出の値（Last known value） | 値の変化が予測可能なもので、短時間で大きく変化しないもの。 例：CPU使用率、レスポンスタイム、DBコネクション数 |
データ到着遅延対策する設計
クラウドサービスやログ監視では、実際の発生時刻とNew Relicへの到着時刻に差がある場合があります。Evaluation Delayを設定することで、遅れて到着するデータを待ってから評価できます。どのような機能があるのかを見ていきます。
Evaluation delay
新しく現れた監視対象を落ち着くまでアラート評価を行わない設定です。システム起動直後や監視対象追加直後に発生する一時的な変動による誤検知を防止できます。設定期間中に閾値を超過してもインシデントは作成されず、期間終了後から通常のアラート評価が開始されます。
設定期間中は実際の障害も検知できなくなるため、CPUやメモリなど起動直後に変動しやすい監視項目に限定して利用することが推奨されます。サービスの応答時間やエラー率など、お客様影響につながる監視は別途リアルタイムで監視します。
| 利用シーン | メリット(一例) | デメリット(一例) |
| オートスケール環境で新規サーバーが起動する場合 | 起動直後のCPU・メモリ高騰による誤通知を防げる | 実際の障害が発生していても設定期間中は通知されない |
| Kubernetesで新しいPod/Containerが作成される場合 | ウォームアップ中の一時的な異常値を無視できる | 障害検知開始まで時間がかかる |
| アプリケーションデプロイ直後 | キャッシュ生成や初期化処理による一時的な負荷上昇を除外できる | デプロイ直後の不具合検知が遅れる可能性がある |
| 新規監視対象を追加した場合 | 初期データのばらつきによる不要なIncidentを防げる | 長く設定しすぎると監視の意味が薄れる |
データ特性に応じたアラート設計
New Relicのアラートは、受信したデータをそのまま判定するのではなく、一定期間のデータを集計した結果をもとにしきい値を評価します。このとき、「どのタイミングで集計区間を確定し、評価を実行するか」を決める仕組みが集計方式です。
例えば、CPU使用率のように継続的に届くメトリクスと、ERRORログのように不規則に届くイベントでは、データの到着パターンが異なります。そのため、データ特性に合わせて適切な集計方式を選択しないと、アラートの遅延や検知漏れ、誤検知につながる可能性があります。
New Relicでは主にEvent Flow、Event Timer、Cadenceの3種類の集計方式が提供されており、継続的なデータにはEvent Flow、不規則なデータにはEvent Timer の利用が推奨されています。この2種類についてみていきます。
Event Flow
監視データは本来一定間隔で収集されますが、通信障害やエージェント停止などにより、一部のデータが取得できない場合があります。この「欠損データ」をどのように扱うかを決めるのがGap fillingです。Event Flowは主にレスポンスタイムやCPU使用率など、継続的に届くデータ向けの集計方式です。データを一定期間まとめて保持し、次のデータが届いた時点で前の集計を確定してアラート評価を行います。そのため、定期的にデータが到着する監視に適しています。
| 利用シーン | 具体例 | メリット(一例) | デメリット(一例) | 選定の目安 |
| データが頻繁かつ安定して届く監視 | APM、CPU使用率、メモリ使用率、応答時間、スループット、AWS Metric Streams | 不必要に長く待たず、比較的早く評価できる。一般的なメトリクス監視に適している | 後続データが来ないと集計が進まない。散発的なデータでは評価が大きく遅れる可能性がある | データが継続的に流れ続ける場合に選択 |
Event Timer
| 利用シーン | 具体例 | メリット(一例) | デメリット(一例) | 選定の目安 |
| データが不定期、散発的、またはバッチで届く監視 | エラーログ、低頻度ログ、バッチ実行結果など | 後続ウィンドウのデータを待たず、1件だけ届くデータや不規則なデータでも評価できる | Timerが満了するまで検知が遅れる。Timerが短すぎると、遅れて届いたデータを集計できない場合がある | 次のデータがいつ届くか分からない場合に選択 |
異常判定条件する設計(thresholds)
Thresholdsは、システムの正常状態と異常状態の境界を定義する重要な設定です。利用者影響の大きい指標を選定し、運用で対応が必要となるレベルでしきい値を設定することで、有効なアラートを実現します。どのような設定方法があるのかを見ていきます。
閾値の判定方法(Static / Anomaly)
Static Threshold は、あらかじめ設定した固定値を基準として異常を判定する方式です。例えば、CPU使用率が 80%を超えた場合にアラートを発生させる といったように、明確な閾値を設定します。監視対象の正常値と異常値の境界が明確な場合に適しており、CPU使用率、メモリ使用率、ディスク使用率などのインフラ監視で広く利用されます。
Anomaly Detectionは、過去のデータ傾向を学習し、通常とは異なる動きを検知した場合に異常と判定する方式です。アクセス数やトランザクション数など、時間帯や曜日によって大きく変動する指標の監視に適しています。固定の閾値を設定する必要はなく、システムが通常時の振る舞いを基準として判断します。
Severity
アラートの重要度（深刻度）を定義する設定です。アラートが発生した際に、その事象が「注意が必要な状態」なのか、「即時対応が必要な重大障害」なのかを区別するために利用します。一般的にはWarningとCriticalの2段階で設定し、それぞれ異なる閾値を定義できます。
When a query returns a value(閾値設定)
NRQLクエリの実行結果を評価し、その値が設定した閾値条件を満たした場合にアラートを発生させる設定です。監視対象から収集したデータを集計した結果に対して、「以上」「以下」「等しい」などの条件を設定し、異常を検知します。
| 設定項目 | 内容 |
| Above | 閾値を超えた場合 |
| Below | 閾値を下回った場合 |
| For at least | 一定時間継続した場合 |
| At least once in | 指定時間内に1回でも発生した場合 |
Predictive Alerts(予測アラート)
Predictive Alertsは、過去の実績データをもとに将来の値を予測し、予測値が設定した閾値を超えると判断された場合にアラートを発生させる機能です。通常のアラートが実際に閾値を超過した後に通知するのに対し、Predictive Alertsは将来的な閾値超過を事前に検知できるため、障害やリソース不足が発生する前に対策を実施できます。
| 設定項目 | 説明 | 利用例 |
| Predict future behavior
(Static選択時のみ) |
過去のデータ傾向をもとに将来の値を予測し、将来的に閾値を超えると予測された場合にアラートを発生させます。 | ディスク使用率が数日後に閾値に到達すると予測された場合に事前通知する。 |
| Open an alert event when the forecasted signal crosses your threshold | 予測値が設定した静的閾値を超えると判断された時点でアラートイベントを生成します。実際に閾値を超える前に通知できます。 | メモリ使用量が増加傾向にあり、数時間後に閾値超過すると予測された場合に通知する。 |
| Ignore this threshold when determining health | この閾値によるアラートは Entity Health に反映しません。監視対象を異常状態として扱わず、予兆検知専用として利用できます。 | 将来予測の参考通知は行うが、システム状態は正常のままにする。 |
| Don’t create alert events | 予測結果を評価するだけで、アラートイベントやインシデントを作成しません。通知も行われません。 | 予測精度の確認やチューニング期間中に利用 |
Loss of Signal
Loss of Signalは、監視対象から一定時間データが送信されなくなったことを検知する機能です。通常のアラートは「CPU使用率が高い」「エラーが増加した」といったデータ値の異常を検知しますが、Loss of Signalは データそのものが届かなくなった状態 を異常として検知します。例えば、監視エージェントの停止やサーバ停止によりメトリクスが送信されなくなった場合でも、通知を行うことができます。エラー検知系のアラートでは “一定時間エラーが発生していない＝事象が収束した” とみなし、アラートを自動クローズする用途にも利用できます。
| 設定項目 | 説明 | 有効にした場合の動作 |
| Close all current open alert events | Signal Lost が発生した際に、現在オープン中のアラートイベントを自動でクローズします。 | CPU高騰など既存アラートが発生中でも、Signal Lost検知時に既存イベントを終了します。 |
| Open new “lost signal” alert event | Signal Lost 専用のアラートイベントを新規作成します。 | データ未受信を独立したインシデントとして管理し、設定された通知ルールに従って通知します。 |
| Do not open “lost signal” alert event on expected termination | 想定済みの停止時は Signal Lost アラートを発生させません。 | オートスケールによるサーバ削除や計画停止など、正常な終了時の不要な通知を防止できます。 |
通知先の設計
アラートを検知できるようになったら、次に考えるべきは「誰に、どのように通知するか」です。New Relicでは、通知設定を Workflow、Destination、Notification(Channel) に分けて管理します。一見すると少し複雑に見えますが、それぞれの役割を理解すると、通知先の変更や運用ルールの見直しを柔軟に行えるようになります。
Workflow
Workflowは、発生したIssueをどこへ通知するかを決める設定です。まず通知対象となるIssueを絞り込み（Filter data）、必要に応じて関連情報を追加し（Enrich your data）、ミュート中Issueの扱いを設定します（Mute issues）。最後に通知先（Destination）やメッセージを指定して通知を送信します（Notify）。Workflowではどこに接続(PagerDuty、Jira、Slack等)するかは作成しません。作成済みのDesitinationをNotifyで選択します。WorkflowからDestinationへ一貫して作成できますが、設定としては独立して管理されます。
Workflowは、Issueの状態変化（Issueイベント）をきっかけに実行されます。通知するタイミングは「Notify when」で設定でき、障害発生時（Activated）や障害復旧時（Closed）など、通知したいイベントを選択できます。
| Notification trigger | 説明 | 具体例 | デフォルト通知先 |
| Activated | 新しいIssueが発生した時に通知 | サーバ障害が発生し、Issueが作成された | すべてのDestination |
| Acknowledged | 担当者がIssueの対応開始を宣言した時に通知 | オンコール担当者がIssueを確認し対応開始した | Webhook、PagerDuty、Slack、Email、Mobile App |
| Investigating | 原因調査を開始した時に通知 | Issueの状態が Investigating に変更された | Webhook、PagerDuty、Slack、Email、Mobile App |
| Closed | Issueが解消された時に通知 | 障害が復旧しIssueがクローズされた | すべてのDestination |
| Priority changed | Issueの重要度が上がった時に通知 | High から Critical に変更された | Webhook、Event Bridge、ServiceNow、Jira |
| Other updates | Issueに変更があった時に通知 | Alert追加、Issue統合、Alert解消など | Webhook、Event Bridge、ServiceNow、Jira、PagerDuty |
Destination
Destinationは、PagerDuty・Microsoft Teams・Emailなどの通知先サービスとの接続情報を登録する機能です。Workflowから参照され、Issue通知をどのサービスへ送信するかを決定します。Workflowで本番環境のCriticalアラートは通知する、DestinationでJiraへ送る接続情報を管理する関係になります。
Notification(Channels)
Notificationは、Workflowで設定した条件に一致したIssueを、Destinationで登録された通知先へ実際に送信する処理です。Workflowで通知対象と通知タイミングを決定し、Destinationで接続先を指定した後、NotificationによってPagerDutyのインシデント作成やJiraのチケット作成、Microsoft Teamsへの投稿などが実行されます。
ここまででWorkflow、Destionation、Notificationについて見てきました。一見、Workflowですべてを担っているように思えますが、機能としては独立しています。
アラート設計のベストプラクティス
効果的な監視を実現するためには、単にアラートを増やすのではなく、対応が必要な問題だけを担当者へ通知することです。New Relicでは、Alert Eventの集約方法やWorkflowによる通知制御を活用することで、不要な通知を削減しながら、重要な障害を通知できます。
ユーザー影響のある指標を監視する
CPUやメモリだけでなく、レスポンスタイムやエラー率など、ユーザー体験に直結する指標を優先して監視します。
適切なしきい値を選択する
明確な基準値がある場合は固定しきい値（Static Threshold）、通常パターンからの逸脱を検知したい場合はベースライン異常検知（Baseline Threshold）を利用します。
ノイズを減らす
一時的な増加でアラートが発生しないよう、評価期間（Window Duration）や継続時間を調整します。変動が大きい指標には Sliding Window が有効です。
データ特性に合わせて評価する
メトリクス、ログ、バッチ処理などデータ到着パターンは異なります。監視対象に応じて Streaming Method や Gap Filling を適切に設定し、誤検知を防ぎます。
通知設計を分離する
アラート検知条件（Alert Condition）と通知先（Workflow）を分離し、障害検知と通知ルーティングを独立して管理します。これにより運用変更時の影響を最小化できます。
関連アラートを集約する
同一障害で大量の通知が発生しないよう、Issue集約機能を活用してアラート疲れを防ぎます。
定期的に見直す
発報頻度や対応実績を確認し、不要なアラートの削除やしきい値の調整を継続的に実施します。
さいごに
この記事では、New Relicのアラート機能の説明と設計の仕方について紹介しました。重要なのは、本当に対応が必要な問題だけを適切な担当者へ通知することです。ユーザー影響を意識した指標選定、適切なしきい値設定、ノイズ抑制、Issue集約、そしてWorkflowとDestinationを活用した通知設計により、アラート疲れを防ぎながら迅速な障害対応を実現できます。
とはいえ、アラート設計は一度作ったら終わりではありません。実際には「通知が多すぎる」「逆に検知できていなかった」といった問題が必ず出てくるので、発報状況を見ながらしきい値や通知ルールを少しずつ調整していくことになります。私自身も毎回試行錯誤の連続ですが、アラート運用は完璧な設定を最初から作るのではなく、運用しながら育てていくものだと感じています。
SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。
