New Relicアラートポリシー設定ガイド - 効果的な監視設計と実装 ​

New Relicアラートシステムの中核を担うのがアラートポリシーです。ポリシーは、関連するアラート条件をグループ化し、インシデントの作成方法や通知戦略を統一的に管理する仕組みです。適切に設計されたポリシーは、システムの問題を確実に検知し、重要でない通知によるノイズを最小限に抑えます。この記事では、基本的なポリシー作成から、Issue Creation Preferenceの詳細、NRQL Alert Conditionの実装、Baseline/Outlier Detectionなどの高度な機能まで、実践的なアプローチで解説します。

アラートポリシーの基本概念 ​

アラートポリシーは、単なる設定のコンテナではなく、監視戦略を具現化する重要な設計要素です。

ポリシーの役割と構成要素 ​

アラートポリシーは、以下の3つの主요素で構成されます。

**アラート条件（Alert Conditions）**は、監視対象となるメトリクスとその評価基準を定義します。CPU使用率、レスポンスタイム、エラー率など、具体的な監視項目としきい値を設定します。1つのポリシーに複数の条件を含めることができ、関連する監視項目をまとめて管理できます。

**Issue Creation Preference（インシデント集約設定）**は、アラート条件に違反した場合のインシデント作成とグループ化の方法を制御します。「ポリシー全体で1つのIssue」「条件ごとに1つのIssue」「条件とシグナルごとに1つのIssue」の3つのオプションがあり、運用要件に応じて選択します。

**Workflow（通知ワークフロー）**は、Issue発生時の通知先と通知方法を定義します。メール、Slack、PagerDuty、Webhookなど、チームの運用体制に応じた多様な通知チャネルを設定できます。

ポリシー設計の基本原則 ​

効果的なアラートポリシーは、以下の原則に基づいて設計されます。

目的の明確化では、各ポリシーが監視する対象システムと期待する結果を明確に定義します。「本番環境のWebアプリケーション性能監視」「インフラストラクチャのキャパシティ管理」など、具体的な目的を持たせることで、ポリシーの管理と改善が容易になります。

適切な粒度の選択として、アプリケーション単位、サービス単位、チーム単位など、管理しやすい粒度でポリシーを分割します。1つのポリシーに多すぎる条件を詰め込むと管理が複雑になり、細分化しすぎると全体像の把握が困難になります。通常、1ポリシーあたり5～15個程度の条件が管理しやすい範囲です。

重要度別の階層化により、Critical、Warning、Infoの各レベルに応じた適切な通知設定を行います。ビジネスへの影響度に基づいた優先順位付けが重要で、すべてをCriticalにすると真の緊急事態が埋もれてしまいます。

ノイズ最小化を実現するため、過度に敏感な設定を避け、真に重要な問題のみを検出するように調整します。誤検知による対応コストを最小限に抑えることで、チームの生産性が維持されます。

ポリシーの命名規則とベストプラクティス ​

ポリシーの命名は、運用効率に大きく影響します。New Relic公式では、3つの組織パターンを推奨しています。

アーキテクチャベースの命名 ​

システムの構造に基づいた命名パターンです。環境タイプ（本番/ステージング/開発）やリソースタイプ（アプリサーバー/データベース/ホスト）で分類します。

命名例:

• Production - WebApp - Performance（本番Webアプリ性能監視）
• Production - Database - Capacity（本番データベース容量監視）
• Staging - API - Errors（ステージングAPI エラー監視）
• Production - Hosts - Infrastructure（本番ホストインフラ監視）
• Production - Mobile - iOS（本番iOSアプリ監視）

このパターンは、環境やリソースタイプごとに責任者が異なる場合に特に有効です。

チームベースの命名 ​

特定のチームや組織単位で責任範囲を明確にする命名パターンです。

命名例:

• Team: Site Engineering - Critical（サイトエンジニアリングチーム重要監視）
• Team: DevOps - Infrastructure（DevOpsチームインフラ監視）
• Team: Mobile - App Performance（モバイルチームアプリ性能）
• Team: Data - ETL Jobs（データチームETLジョブ監視）

このパターンは、チームの自律性を重視し、各チームが独自の監視戦略を持つ組織に適しています。

個人ベースの命名 ​

特定の個人が管理する実験的な監視や、個別のメトリクス追跡に使用します。

命名例:

• User: John Doe - API Experiments（John氏のAPI実験監視）
• User: Jane Smith - Performance Tests（Jane氏の性能テスト）

このパターンは、開発者が個別に特定のメトリクスを追跡したい場合に有用ですが、本番環境では推奨されません。

推奨命名フォーマット ​

以下のフォーマットを使用すると、一貫性のある命名が可能です。

[環境] - [対象システム/チーム] - [監視タイプ] - [重要度]

具体例:

• Prod - Ecommerce API - Performance - Critical
• Stg - Payment Service - Errors - Warning
• Prod - Infrastructure - Capacity - Info

このフォーマットにより、ポリシー一覧で素早く目的のポリシーを見つけられます。

Issue Creation Preference の詳細 ​

Issue Creation Preferenceは、アラートポリシーの最も重要な設定の1つです。この設定により、複数のインシデントがどのようにグループ化され、Issueとして管理されるかが決まります。

3つのオプションの詳細 ​

New Relicは3つのIssue Creation Preferenceを提供しており、それぞれ異なるユースケースに適しています。

One Issue per Policy（デフォルト） ​

ポリシー全体で1つのIssueのみが同時にオープンされる設定です。

動作の仕組み

• ポリシー内のいずれかの条件が違反すると、1つのIssueが作成されます
• その後、他の条件が違反しても、既存のIssueに新しいインシデントが追加されます
• 最初のIssueが解決されない限り、新しいIssueは作成されません

メリット

• 通知数が最小限（1つのポリシーから同時に1つのIssueのみ）
• 関連する複数の問題を統合的に把握できる
• 通知疲れを防止

デメリット

• 個別の問題を追跡しにくい
• Issueを速やかにクローズしないと、後続の問題が検出されない

適用シナリオ

• 単一のアプリケーションや緊密に関連するサービスの監視
• 高度に統合されたシステムで、問題が連鎖的に発生することが多い環境
• 通知数を最小限に抑える必要がある小規模チーム

設定例 ECサイトの本番環境監視で、WebサーバーのCPU、メモリ、レスポンスタイム、エラー率を1つのポリシーで管理。いずれかの条件が違反した場合、運用チームは「本番サイトに問題がある」という1つのIssueを受け取り、統合的に対応します。

One Issue per Condition ​

条件ごとに個別のIssueが作成される設定です。

動作の仕組み

• 各アラート条件が違反すると、その条件専用のIssueが作成されます
• 同じ条件で複数のシグナル（エンティティ）が違反した場合、それらは同じIssueにグループ化されます
• 異なる条件の違反は、常に別のIssueとして扱われます

メリット

• 条件ごとに問題を追跡できる
• 複数の異なる問題が同時発生しても、それぞれ独立して管理できる
• 条件ごとの対応履歴を明確に記録できる

デメリット

• 通知数が増加する
• 関連する問題の全体像を把握しにくい場合がある

適用シナリオ

• 同じ役割を持つ複数のエンティティを監視（例: 10台のWebサーバー）
• 異なるメトリクスタイプを独立して追跡したい場合（性能問題とエラー問題を別々に管理）
• 中規模～大規模チームで、問題の種類ごとに担当者が異なる環境

設定例 負荷分散された10台のWebサーバーの監視。「高CPU使用率」「高メモリ使用率」「ディスク容量不足」の3つの条件を設定。CPU問題が3台で発生した場合、「高CPU使用率」の1つのIssueに3つのインシデントがグループ化されます。同時にディスク問題が2台で発生した場合、別のIssue「ディスク容量不足」が作成されます。

One Issue per Condition and Signal ​

最も粒度が細かい設定で、条件とシグナル（エンティティ）の組み合わせごとにIssueが作成されます。

動作の仕組み

• 各条件と各シグナルの組み合わせごとに個別のIssueが作成されます
• 同じ条件・シグナルで複数の違反（例: Warning → Critical へのエスカレーション）が発生した場合のみ、同じIssueにグループ化されます

メリット

• 最も詳細な追跡が可能
• 各エンティティの問題を個別に管理できる
• 外部システムとの統合で、詳細な情報が必要な場合に最適

デメリット

• 通知数が最大（多数のエンティティがある場合、大量のIssueが作成される可能性）
• Issue管理の負荷が増大

適用シナリオ

• マイクロサービスアーキテクチャで、各サービスインスタンスを個別に追跡
• PagerDutyなどの外部インシデント管理システムとの統合
• 大規模なインフラストラクチャで、詳細なレポーティングが必要な環境

設定例 50個のマイクロサービスインスタンスの監視。「レスポンスタイム異常」条件で、サービスA-instance-1が違反すると、そのサービス・インスタンス専用のIssueが作成されます。サービスA-instance-2が違反すると、別のIssueが作成されます。各インシデントを精密に追跡し、PagerDutyで個別に対応します。

Issue Creation Preferenceの比較表 ​

Issue Creation Preferenceの選択フローチャート ​

以下のフローチャートは、適切なIssue Creation Preferenceを選択するための判断基準を示しています。

アラートポリシーの作成手順 ​

New RelicのWebUIを使用したアラートポリシーの作成手順を、詳細に説明します。

ステップ1: ポリシー作成画面へのアクセス ​

1. New Relicにログインし、画面上部のナビゲーションからAlerts & AIを選択します
2. 左側のメニューからAlert Policiesをクリックします
3. New alert policyボタンをクリックして、ポリシー作成ウィザードを開始します

ステップ2: ポリシー名とIssue Preferenceの設定 ​

ポリシー名は、前述の命名規則に従って、目的が明確に分かる名前を入力します（最大64文字）。

例: Production - Payment API - Performance - Critical

次に、Issue Creation Preferenceを選択します。初めて作成する場合は、デフォルトのOne issue per policyから開始し、運用経験に基づいて調整することを推奨します。

ステップ3: 初期設定の完了 ​

2つのオプションがあります:

Option A: Create & close - ポリシーのみを作成し、後でアラート条件と通知を設定します。慎重に設計したい場合や、既存の条件をコピーする予定の場合に適しています。

Option B: Set up notifications - ポリシー作成と同時にWorkflow（通知設定）を構成します。即座に運用を開始したい場合に適しています。

ステップ4: アラート条件の追加 ​

ポリシー作成後、Add a conditionボタンをクリックして、監視条件を追加します。条件タイプは以下から選択できます:

• NRQL Query - 最も柔軟で強力な条件タイプ（次のセクションで詳述）
• APM - アプリケーションパフォーマンス監視
• Browser - フロントエンドユーザー体験監視
• Mobile - モバイルアプリ監視
• Infrastructure - サーバー・クラウドインフラ監視
• Synthetics - 外部からの可用性監視

NRQL Alert Conditionの実装 ​

NRQL（New Relic Query Language）を使用したアラート条件は、最も柔軟で強力な監視を実現します。

NRQL Alertの基本構造 ​

NRQL Alertは以下の要素で構成されます:

1. NRQL Query - 監視対象データを取得するクエリ
2. Window Duration - データを集約する期間（前述の記事で詳述）
3. Aggregation Method - データの集約方法（Event Flow / Event Timer / Cadence）
4. Threshold - しきい値設定（Critical / Warning）
5. Signal Behavior - Gap Filling、Delay、Signal Lossの設定

実践的なNRQLアラートクエリ例 ​

例1: APM - アプリケーションレスポンスタイム監視 ​

目的 本番WebアプリケーションのP95レスポンスタイムが3秒を超える状態を検出

SELECT percentile(duration, 95) AS 'Response Time (P95)'
FROM Transaction
WHERE appName = 'production-web-app'
AND transactionType = 'Web'

設定

• Window Duration: 3分
• Aggregation Method: Event Flow
• Critical Threshold: 3秒以上が5分継続
• Warning Threshold: 2秒以上が5分継続
• Gap Filling: None
• Delay: 1分

解説 P95レスポンスタイムを監視することで、大多数のユーザー体験を代表する指標を追跡できます。平均値ではなくパーセンタイル値を使用することで、外れ値の影響を排除し、より安定した監視が可能です。

例2: Infrastructure - CPU使用率の外れ値検出 ​

目的 複数のWebサーバーのうち、他と異なる高CPU使用率を示すサーバーを検出

SELECT average(cpuPercent) AS 'CPU Usage'
FROM SystemSample
WHERE hostname LIKE 'web-server-%'
FACET hostname

設定

• Window Duration: 5分
• Aggregation Method: Event Flow
• Critical Threshold: 90%以上が10分継続
• Warning Threshold: 75%以上が15分継続
• Gap Filling: None
• Delay: 2分

解説 FACET hostnameにより、各サーバーを個別に評価します。Issue Creation PreferenceをOne issue per condition and signalに設定することで、問題のあるサーバーごとに個別のIssueが作成されます。

例3: カスタムメトリクス - ビジネスKPI監視 ​

目的 1分あたりの注文完了数が通常の50%以下に減少した場合を検出

SELECT count(*) AS 'Orders Completed'
FROM OrderCompleted
WHERE environment = 'production'

設定

• Window Duration: 5分
• Aggregation Method: Event Flow
• Baseline Alert（Anomaly Threshold）を使用
• Critical: 3標準偏差以下が10分継続
• Gap Filling: 0（注文がない場合は問題として扱う）
• Delay: 2分

解説 Baseline Alertを使用することで、時間帯や曜日による変動パターンを学習し、通常の変動範囲から逸脱した場合のみアラートを発火します。ビジネスメトリクスは時間帯で大きく変動するため、固定しきい値よりも効果的です。

例4: エラー率監視 - 比率ベースのアラート ​

目的 全トランザクションに対するエラーの割合が1%を超える状態を検出

SELECT percentage(count(*), WHERE error IS true)
FROM Transaction
WHERE appName = 'payment-service'

設定

• Window Duration: 3分
• Aggregation Method: Event Flow
• Critical Threshold: 1%以上が3分継続
• Warning Threshold: 0.5%以上が5分継続
• Gap Filling: None
• Delay: 1分

解説 percentage()関数を使用することで、トラフィック量に関係なく、エラーの割合を監視できます。絶対数ではなく比率で監視することで、低トラフィック時の誤検知を防げます。

例5: Synthetics - 複数ロケーションからの可用性監視 ​

目的 複数の地理的ロケーションからのSyntheticsチェックが失敗した場合を検出

SELECT percentage(count(*), WHERE result = 'FAILED')
FROM SyntheticCheck
WHERE monitorName = 'API Health Check'
FACET locationLabel

設定

• Window Duration: 15分
• Aggregation Method: Event Timer
• Critical Threshold: 50%以上の失敗率が15分継続
• Gap Filling: None（データがない場合はSignal Lossで検出）
• Delay: 5分
• Signal Loss: 30分（Syntheticsチェック自体が動作していない場合を検出）

解説 複数ロケーションからのチェック結果を集約し、過半数が失敗した場合のみアラートを発火することで、一時的なネットワーク問題による誤検知を防げます。

例6: Browser - フロントエンドパフォーマンス監視 ​

目的 ページロード時間のP75が5秒を超える状態を検出

SELECT percentile(duration, 75) AS 'Page Load Time (P75)'
FROM PageView
WHERE appName = 'ecommerce-frontend'
AND deviceType = 'desktop'

設定

• Window Duration: 5分
• Aggregation Method: Event Flow
• Critical Threshold: 5秒以上が10分継続
• Warning Threshold: 3秒以上が15分継続
• Gap Filling: None
• Delay: 2分

解説 フロントエンドのユーザー体験を直接監視できます。デバイスタイプ別にクエリを分けることで、モバイルとデスクトップで異なるしきい値を設定できます。

例7: データベース - スロークエリ検出 ​

目的 データベースクエリの実行時間が1秒を超えるクエリ数を監視

SELECT count(*)
FROM Span
WHERE category = 'datastore'
AND duration > 1

設定

• Window Duration: 10分
• Aggregation Method: Event Flow
• Critical Threshold: 100個以上が10分継続
• Warning Threshold: 50個以上が15分継続
• Gap Filling: 0
• Delay: 3分

解説 分散トレーシングデータを活用して、スロークエリの発生を監視します。単一のスロークエリではなく、一定数以上の発生を条件とすることで、個別のクエリ最適化ではなく、システムレベルの問題を検出できます。

NRQL Alertのベストプラクティス ​

1. クエリの最適化 できるだけシンプルなクエリを使用し、複雑な計算はアプリケーション側で実施
2. FACET の活用 エンティティごとに個別評価が必要な場合は FACET を使用
3. パーセンタイル値の使用 平均値ではなく、95th や 99th パーセンタイル値で監視
4. 比率ベースの監視 絶対数ではなく、percentage() 関数で比率を監視
5. クエリのテスト Query Builderで事前にクエリをテストし、期待通りのデータが返ることを確認

Baseline（動的）Alertの詳細 ​

Baseline Alert（ベースラインアラート）は、機械学習を活用して、過去のデータパターンから正常範囲を学習し、異常を検出する動的なアラート手法です。

Baselineアラートの仕組み ​

New RelicのBaselineアラートは、過去7日間のデータを分析し、時間帯、曜日、トレンドを考慮した「正常範囲」を自動的に計算します。

学習プロセス

1. 過去7日間の同時間帯データを収集
2. 平均値と標準偏差を計算
3. 時間帯別・曜日別のパターンを学習
4. 季節性やトレンドを考慮した予測範囲を確立

異常検出

• 現在の値が予測範囲から指定した標準偏差以上離れた場合に異常と判定
• 設定可能な標準偏差: 1～10（通常は3～5を使用）

Baseline Alert vs Static Thresholdの使い分け ​

Baselineアラートの設定例 ​

ケース ECサイトのトラフィック監視

平日昼間は低トラフィック（100 RPM）、夜間と週末は高トラフィック（1000 RPM）という変動パターンがあります。

SELECT rate(count(*), 1 minute) AS 'Requests per Minute'
FROM Transaction
WHERE appName = 'ecommerce-web'

Baseline設定

• Baseline Direction: Upper and Lower（上下両方向の異常を検出）
• Deviation: 3標準偏差
• Duration: 10分継続

この設定により、昼間に通常の100 RPMから急激に減少した場合（例: 30 RPMに低下）も、夜間に通常の1000 RPMから急激に減少した場合（例: 300 RPMに低下）も、それぞれの正常範囲を基準に異常として検出されます。

Static Thresholdで同じ監視を実現しようとすると、時間帯別に複数のアラート条件を作成する必要があり、管理が複雑になります。

Baseline Alertの注意点 ​

1. 学習期間の必要性 最低7日間のデータが必要なため、新規サービスには不向き
2. 急激な変化への対応 ビジネスの急成長やキャンペーン時は、過去のパターンが適用できない
3. 標準偏差の調整 最初は3から開始し、誤検知が多ければ4～5に調整
4. Baseline方向の選択 トラフィック監視ではLower only、エラー率ではUpper onlyが一般的

よくある設定ミスとトラブルシューティング ​

アラートポリシー設定における典型的な問題と、その対処法を紹介します。

問題1: アラートが発火しない ​

症状 明らかに問題が発生しているのに、アラートが発火しない。

原因と対処法

1. しきい値が緩すぎる

   • 対処: Query Builderで実際のメトリクス値を確認し、適切なしきい値に調整
   • 例: CPU 99%でアラート設定していたが、実際は95%で問題が発生

2. 継続時間（Duration）が長すぎる

   • 対処: 継続時間を短縮（例: 10分 → 3分）
   • 例: 3分で問題が発生しているのに、10分継続を条件にしていた

3. NRQLクエリが正しくない

   • 対処: Query Builderでクエリをテストし、データが返ることを確認
   • 例: appNameのスペルミス、存在しない属性名の使用

4. Window Durationが不適切

   • 対処: データの送信頻度に合わせてWindow Durationを調整
   • 例: 1分ごとのデータに対して60分のWindow Durationを設定していた

問題2: 誤検知が多すぎる ​

症状 実際には問題がないのに、頻繁にアラートが発火する。

原因と対処法

1. しきい値が厳しすぎる

   • 対処: 95～99パーセンタイル値を基準に、しきい値を緩和
   • 例: 平均値でアラート設定していたため、正常な変動でも発火

2. 継続時間が短すぎる

   • 対処: 継続時間を延長（例: 1分 → 5分）
   • 例: 一時的なスパイクで即座にアラートが発火

3. Gap Fillingの誤設定

   • 対処: データが安定している場合は Gap Filling を None に設定
   • 例: Gap Filling で 0 を設定したため、一時的なデータ欠損で誤検知

4. Baseline Alertの標準偏差が小さすぎる

   • 対処: 標準偏差を3→4または5に拡大
   • 例: 標準偏差1で設定し、正常な変動でも頻繁に発火

問題3: 通知が届かない ​

症状 アラートは発火しているが、通知が届かない。

原因と対処法

1. Workflowが設定されていない

   • 対処: ポリシーにWorkflowを紐付ける
   • 確認: ポリシーの Workflow タブで設定状況を確認

2. Workflow の条件フィルタ

   • 対処: Workflowの条件フィルタを確認し、該当するIssueが除外されていないか確認
   • 例: 特定のタグやポリシー名でフィルタしており、新しいポリシーが対象外

3. 通知チャネルの設定エラー

   • 対処: Email、Slack、PagerDutyなどの各チャネル設定を確認
   • 例: Slack Webhook URLが無効、Email アドレスが間違っている

4. Issue Creation Preferenceの誤解

   • 対処: One issue per policy設定で、既にIssueがオープンしている場合、新しいインシデントは既存Issueに追加されるだけで、新しい通知は送信されない
   • 解決: より粒度の細かいIssue Preference に変更するか、Issueを速やかにクローズする運用を確立

問題4: 大量のIssueが作成される ​

症状 Issue一覧が大量のオープンIssueで埋め尽くされ、管理不能になる。

原因と対処法

1. Issue Creation Preferenceが細かすぎる

   • 対処: One issue per condition and signal から One issue per condition または One issue per policy に変更
   • 例: 100個のサーバーを監視し、per signal設定で100個のIssueが作成

2. 自動クローズ設定の不備

   • 対処: Signal Loss時の自動クローズを有効化（closeViolationsOnExpiration: true）
   • 例: オートスケーリングでインスタンスが終了してもIssueが残り続ける

3. しきい値が不適切で常に違反状態

   • 対処: しきい値を見直し、正常範囲に調整
   • 例: CPU 30%でアラート設定し、常時違反状態

トラブルシューティングフローチャート ​

まとめ ​

New Relicアラートポリシーの効果的な設定には、基本概念の理解、適切なIssue Creation Preferenceの選択、NRQL Alertの活用、そしてBaseline Alertなどの高度な機能の組み合わせが必要です。

重要なポイントとして、ポリシーの命名規則に従い、目的が明確なポリシー設計を行うこと、Issue Creation Preferenceは環境とチーム規模に応じて選択し、小規模ならOne issue per policy、大規模ならOne issue per condition and signalを検討すること、NRQL Alertでパーセンタイル値や比率ベースの監視を実装し、より正確な異常検出を行うこと、時間変動が大きいメトリクスにはBaseline Alertを活用し、固定しきい値の限界を克服すること、トラブルシューティングでは、データ確認→設定値調整→Signal Behavior確認の順で問題を特定することを覚えておいてください。

次のステップとして、データポイント評価の基礎、Signal Loss検知、しきい値設計の詳細について、関連記事で深く学習することをお勧めします。これらの知識を組み合わせることで、真に効果的なアラートシステムを構築できます。

関連記事: New Relicアラート概要関連記事: データポイント評価の基礎関連記事: Signal Loss検知の実装関連記事: しきい値設計とチューニング