New Relic通知チャネル設定 - 効果的なアラート配信戦略と実装ガイド

アラートシステムの真の価値は、適切な人に適切なタイミングで適切な形式で情報が届くかどうかによって決まります。どれほど精緻なアラート条件を設定しても、通知が運用チームに確実に届かなければ意味がありません。New Relicの通知チャネルとWorkflow機能は、多様な配信方法、条件分岐ロジック、カスタマイズオプションを提供し、チームの働き方と責任体制に最適化された通知戦略を実現します。この記事では、基本的な通知設定から、役割別・重要度別の高度な配信戦略、トラブルシューティングまで、実践的なアプローチで解説します。

通知チャネルとWorkflowの概要

New Relicの通知システムは、通知チャネル（Notification Channels）とWorkflowの2つの要素で構成されます。

通知チャネルとWorkflowの違い

**通知チャネル（Notification Channels）**は、通知の配信先を定義します。Email、Slack、PagerDuty、Webhookなど、具体的な配信方法と接続情報を設定します。

Workflowは、どのIssueをどの通知チャネルに配信するかのロジックを定義します。Issue Creation Preferenceやタグに基づいた条件分岐、複数チャネルへの配信、通知内容のカスタマイズなどを設定できます。

比喩で説明すると:

通知チャネル = 配送先住所（どこに送るか）
Workflow = 配送ルール（どの荷物をどの住所に送るか）

通知戦略の基本原則

効果的な通知戦略は、以下の4つの原則に基づいて設計されます。

**1. 適切性（Relevance）**では、受信者の役割と責任に応じて、必要な情報を必要な詳細度で配信します。技術者には詳細なデバッグ情報とNRQLクエリ、マネージャーには影響範囲とビジネスインパクトの要約を提供します。

**2. タイムリー性（Timeliness）**により、問題の重要度に応じた迅速な通知配信を実現します。Critical問題は即座にPagerDutyで、Warning問題は5分以内にSlackで、Info問題は1時間ごとのサマリーメールで配信するなど、緊急度に応じた配信速度を設定します。

**3. ノイズ削減（Noise Reduction）**によって、重要でない通知による中断を最小限に抑制します。通知頻度の制御、重複排除、条件付き配信により、受信者の集中力と生産性を保護します。

**4. 冗長性（Redundancy）**として、複数の通知経路を設定し、単一点障害による通知失敗を防止します。主要な通知チャネル（例: PagerDuty）と補完的なチャネル（例: Email、Slack）を組み合わせた多層的な配信体制を構築します。

主要な通知チャネルタイプと設定方法

New Relicは、組織の多様な通信環境に対応した豊富な通知チャネルを提供しています。

1. Email通知

最も基本的で汎用性の高い通知方法です。

メリット

設定が極めて簡単（メールアドレスのみで設定完了）
すべてのチームメンバーがアクセス可能
詳細な情報を含む通知を配信可能
記録として残るため、監査や分析に活用可能
モバイルデバイスで通知を受け取れる

デメリット

リアルタイム性が低い（メールチェック頻度に依存）
大量のメールに埋もれる可能性
チーム内での情報共有が困難

設定手順

Alerts & AI → Destinationsに移動
Add destinationをクリック
Emailを選択
受信者のメールアドレスを入力（個人アドレスまたはディストリビューションリスト）
Save destinationをクリック

推奨設定

個人アドレスではなく、チームのディストリビューションリスト（[email protected]）を使用
Critical アラートは即座配信、Warning は1時間ごとの集約配信
件名に[${severity}] ${conditionName}形式でタグを含める

カスタマイズ例（Workflow設定）

件名テンプレート:
[${severity}] ${policyName} - ${conditionName}
例: [CRITICAL] Production WebApp - High Response Time

本文テンプレート:
Issue: ${issueTitle}
Severity: ${severity}
Opened: ${openedAt}
Policy: ${policyName}

Affected Entities:
${entities}

View Details: ${issuePageUrl}

2. Slack統合

リアルタイムコミュニケーションプラットフォームとの統合により、即座のチーム連携を促進します。

メリット

リアルタイム通知で迅速な対応
専用チャネルでの通知共有によりチーム全体が状況把握
スレッド機能で対応状況を追跡
絵文字リアクションで確認・対応表明
モバイルアプリでどこでも通知受信

デメリット

Slackワークスペースのメンバーのみ
過去の通知が流れやすい（履歴管理が弱い）
通知過多になりやすい

詳細設定手順

ステップ1: Slackアプリのインストール

SlackワークスペースでAppsを開く
New Relic Alertsを検索してインストール
通知を送信するチャネルに New Relic Alerts アプリを追加

ステップ2: Webhook URL の取得

SlackのApps → New Relic Alerts → Configuration
Incoming Webhooksを有効化
通知先チャネルを選択（例: #ops-alerts）
生成されたWebhook URLをコピー

ステップ3: New Relic での設定

Alerts & AI → Destinations → Add destination
Slackを選択
Webhook URLをペースト
チャネル名を設定（例: #ops-alerts-critical）
Test connectionで動作確認
Save destination

推奨チャネル構成

#ops-alerts-critical  - Critical アラートのみ（@channel メンション）
#ops-alerts-warning   - Warning アラート（メンションなし）
#ops-alerts-resolved  - 解決通知（Infoレベル）
#ops-alerts-[service] - サービス別チャネル（例: #ops-alerts-api）

高度なカスタマイズ

Slack通知のフォーマットをカスタマイズ可能:

json

{
  "channel": "#ops-alerts-critical",
  "username": "New Relic Alerts",
  "icon_emoji": ":rotating_light:",
  "attachments": [
    {
      "fallback": "${issueTitle}",
      "color": "#FF0000",
      "title": "${issueTitle}",
      "title_link": "${issuePageUrl}",
      "fields": [
        {
          "title": "Severity",
          "value": "${severity}",
          "short": true
        },
        {
          "title": "Policy",
          "value": "${policyName}",
          "short": true
        },
        {
          "title": "Condition",
          "value": "${conditionName}",
          "short": false
        },
        {
          "title": "Affected Entities",
          "value": "${entity.names}",
          "short": false
        }
      ],
      "footer": "New Relic Alerts",
      "ts": "${timestamp}"
    }
  ]
}

3. PagerDuty連携

インシデント管理プラットフォームとの統合により、専門的なエスカレーション機能を活用できます。

メリット

24/7オンコール担当者への自動通知
多段階エスカレーション（1次対応者→2次対応者→マネージャー）
対応状況の追跡とSLA管理
音声通話、SMS、プッシュ通知など多様な通知方法
インシデントライフサイクル全体の管理

設定手順

ステップ1: PagerDutyでIntegration Keyを取得

PagerDutyにログイン
Services → 対象サービスを選択
Integrationsタブ → Add Integration
New Relicを選択
生成されたIntegration Keyをコピー

ステップ2: New Relicでの設定

Alerts & AI → Destinations → Add destination
PagerDutyを選択
Integration Keyをペースト
サービス名を設定
Test connectionで動作確認
Save destination

エスカレーション戦略

PagerDuty側で設定するエスカレーションポリシー例:

レベル1（即座）: オンコールエンジニア（モバイルプッシュ + SMS）
  ↓ 5分以内に応答なし
レベル2（5分後）: シニアエンジニア（音声通話 + SMS）
  ↓ 10分以内に応答なし
レベル3（15分後）: マネージャー（音声通話 + Email）
  ↓ 15分以内に応答なし
レベル4（30分後）: エグゼクティブチーム

New Relic Workflow設定例

IF severity == "CRITICAL" AND policyName LIKE "Production%"
THEN send to PagerDuty (High Urgency)

IF severity == "WARNING" AND policyName LIKE "Production%"
THEN send to PagerDuty (Low Urgency)

4. Webhook統合

カスタムアプリケーションやワークフローとの統合により、組織固有の通知要件に対応します。

メリット

任意の外部システムとの統合が可能
カスタムロジックによる高度な処理
社内システム（チケットシステム、ダッシュボード）との連携
自動レメディエーションのトリガー

デメリット

技術的な実装が必要
エンドポイントの可用性管理が必要
セキュリティ考慮事項（認証、暗号化）

設定手順

Alerts & AI → Destinations → Add destination
Webhookを選択
エンドポイントURLを入力（HTTPS推奨）
HTTPメソッドを選択（通常はPOST）
認証情報を設定（Basic Auth、Bearer Token、Custom Headers）
カスタムペイロードを定義
Test connectionで動作確認
Save destination

カスタムペイロード例（JSON）

json

{
  "alert_type": "new_relic",
  "severity": "{{severity}}",
  "timestamp": "{{timestamp}}",
  "issue": {
    "id": "{{issueId}}",
    "title": "{{issueTitle}}",
    "state": "{{state}}",
    "url": "{{issuePageUrl}}"
  },
  "policy": {
    "name": "{{policyName}}",
    "id": "{{policyId}}"
  },
  "condition": {
    "name": "{{conditionName}}",
    "type": "{{conditionType}}"
  },
  "entities": [
    {{#each entities}}
    {
      "name": "{{name}}",
      "type": "{{type}}",
      "url": "{{url}}"
    }{{#unless @last}},{{/unless}}
    {{/each}}
  ],
  "metadata": {
    "environment": "production",
    "team": "platform-engineering",
    "escalation_required": {{#if (eq severity "CRITICAL")}}true{{else}}false{{/if}}
  }
}

実装例: Jira自動チケット作成

Webhook エンドポイント（AWS Lambda など）で以下の処理:

New RelicからのWebhookを受信
Severityが"CRITICAL"の場合のみ処理
Jira APIを呼び出してチケット作成
チケットURLをSlackに通知
New Relic Issueにチケット番号を紐付け（カスタムタグ）

5. モバイル通知（New Relicアプリ）

New Relicモバイルアプリを通じたプッシュ通知により、場所を問わない迅速な問題認識を実現します。

メリット

どこでも即座に通知受信
アプリ内で詳細確認・対応可能
オフライン時の通知蓄積
生体認証でセキュアなアクセス

設定手順

New Relicモバイルアプリをインストール（iOS/Android）
ログイン後、Settings → Notifications
受信したい通知レベルを設定（Critical のみ、全て、など）
プッシュ通知を有効化

推奨設定

オンコール担当者はCritical アラートのみモバイル通知
営業時間外はモバイル通知を無効化（ワークライフバランス）

Workflow機能の活用

Workflowは、通知の配信ロジックを柔軟に制御する強力な機能です。

Workflowの基本構造

Workflowは3つの要素で構成されます:

Trigger（トリガー） どのIssueを対象とするか
Filter（フィルタ） 条件分岐ロジック
Destination（配信先） どの通知チャネルに送信するか

実践的なWorkflow設定例

例1: 重要度別の配信戦略

目的 Critical/Warning/Infoで異なる配信先と配信方法を設定

Workflow設定

Workflow 1: Critical アラート

Trigger: All Issues
Filter: 
  - severity == "CRITICAL"
  - policyName LIKE "Production%"

Destinations:
  1. PagerDuty (High Urgency) - 即座
  2. Slack #ops-critical (@channel) - 即座
  3. Email [email protected] - 即座

Workflow 2: Warning アラート

Trigger: All Issues
Filter:
  - severity == "WARNING"
  - policyName LIKE "Production%"

Destinations:
  1. Slack #ops-warning（メンションなし）- 即座
  2. Email [email protected]（1時間集約）- 1時間ごと

Workflow 3: Info / 解決通知

Trigger: Issues Closed
Filter:
  - state == "CLOSED"

Destinations:
  1. Slack #ops-resolved - 即座

例2: サービス別・チーム別の配信

目的サービスごとに担当チームに通知を振り分け

Workflow設定

Workflow: Payment Service Team

Trigger: All Issues
Filter:
  - tags.service == "payment"
  - OR conditionName LIKE "%payment%"

Destinations:
  1. Slack #team-payment-alerts
  2. Email [email protected]
  3. PagerDuty (Payment Service Integration)

Workflow: Infrastructure Team

Trigger: All Issues
Filter:
  - tags.team == "infrastructure"
  - OR policyName LIKE "%Infrastructure%"

Destinations:
  1. Slack #team-infra-alerts
  2. PagerDuty (Infrastructure On-Call)

例3: 時間帯別の配信制御

目的営業時間外の低優先度アラートを抑制

Workflow設定

Trigger: All Issues
Filter:
  - severity == "WARNING"
  - tags.environment == "staging"
  - AND time >= "09:00" AND time <= "18:00"  # 営業時間のみ
  - AND day NOT IN ["Saturday", "Sunday"]      # 平日のみ

Destinations:
  1. Slack #ops-staging-alerts
  2. Email [email protected]

営業時間外・週末のWarningは通知しない → 翌営業日の朝に日次サマリーで報告

例4: エスカレーション戦略

目的問題の継続時間に応じて段階的に通知先を拡大

これはWorkflow単独では完全実装できないため、PagerDutyのエスカレーションポリシーと組み合わせます。

Workflow設定

Trigger: All Issues
Filter:
  - severity == "CRITICAL"
  - duration > 900  # 15分以上継続

Destinations:
  1. Email [email protected]
  2. Slack #leadership (経営層への通知)

Workflow設定のフロー図

役割別・環境別の通知戦略

受信者の役割と環境に応じて、通知内容と配信方法を最適化します。

役割別の通知設計

1. 開発者・SREエンジニア向け

必要な情報

詳細なエラーログとスタックトレース
関連するNRQLクエリ
対象エンティティの識別情報（hostname、instance ID）
リンク（New Relic詳細ページ、ダッシュボード、Runbook）

推奨チャネル

Slack（即座の確認と対応）
PagerDuty（Critical のみ）
Email（詳細情報の保存）

通知テンプレート例

🚨 [CRITICAL] Production API - High Error Rate

Summary:
Transaction error rate exceeded 1% threshold
Current: 2.5% (150 errors in last 5 minutes)

Affected Service:
- payment-api-prod
- Instances: api-prod-01, api-prod-02, api-prod-03

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

Actions:
1. Check recent deployments
2. Review error logs: [Link]
3. View traces: [Link]
4. Runbook: [Link]

Details: [New Relic Issue URL]

2. マネージャー・リーダー向け

必要な情報

ビジネスへの影響度（影響ユーザー数、売上影響）
問題の重要度と緊急度
対応状況とETA（解決見込み時刻）
エスカレーションの要否

推奨チャネル

Email（営業時間内）
Slack（Criticalのみ）
音声通話（重大障害のみ）

通知テンプレート例

[CRITICAL] Production Payment Service Issue

Business Impact:
- Affected Users: ~5,000 customers
- Estimated Revenue Impact: $50,000/hour
- SLA Status: At risk of breach

Issue Summary:
Payment processing errors increased to 2.5%
Started: 14:32 JST
Duration: 15 minutes

Team Status:
- Assigned: Platform Engineering Team
- On-call: John Doe (responding)
- ETA: Under investigation

Actions Required:
- Monitor for 30 minutes
- Executive notification if not resolved

Dashboard: [Link]
Status Page: [Link]

3. ビジネスステークホルダー向け

必要な情報

顧客への影響（サービス停止、性能劣化）
ビジネスメトリクスへの影響（売上、コンバージョン率）
対応状況の概要
顧客コミュニケーションの要否

推奨チャネル

Email（重大問題のみ）
専用ダッシュボード（常時アクセス可能）

通知テンプレート例

Service Status Alert - Payment System

Status: Degraded Performance
Impact: Payment processing delays (2-5 minutes)
Affected: Approximately 10% of transactions

Customer Impact:
- Service remains available
- Some customers experiencing delays
- No data loss or security issues

Team Response:
- Issue identified and being resolved
- Expected resolution: Within 30 minutes
- Customer communication: Not required at this time

Next Update: In 15 minutes or upon resolution

Real-time Status: [Status Dashboard]

環境別の通知設計

本番環境（Production）

特徴

最も積極的な通知
複数チャネルの冗長性
24/7監視体制

推奨設定

Critical:
  - PagerDuty (即座)
  - Slack #ops-critical (@channel)
  - Email (即座)
  - モバイルプッシュ (オンコール担当者)

Warning:
  - Slack #ops-warning
  - Email (1時間集約)

Info:
  - Slack #ops-info

ステージング環境（Staging）

特徴

開発チーム中心の通知
営業時間内の通知のみ
テスト活動を考慮

推奨設定

Critical:
  - Slack #staging-alerts
  - Email dev-team@ (営業時間のみ)

Warning:
  - Email dev-team@ (日次サマリー)

Info:
  - 通知なし (ダッシュボードで確認)

開発環境（Development）

特徴

最小限の通知
開発者の作業を妨げない

推奨設定

Critical のみ:
  - Email dev-team@ (日次サマリー)

Warning, Info:
  - 通知なし

よくある通知問題とトラブルシューティング

通知が期待通りに動作しない場合の診断と解決方法を紹介します。

問題1: 通知が届かない

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

診断手順

Issueが作成されているか確認
- Alerts & AI → Issues & Activityで Issue一覧を確認
- Issueが作成されていない場合 → アラート条件またはポリシーの問題
WorkflowがIssueに一致しているかを確認
- 該当 Issue の詳細ページを開く
- WorkflowsタブでマッチしたWorkflowを確認
- マッチしていない場合 → Workflowのフィルタ条件を見直し
通知チャネルの設定を確認
- Destinationsで各チャネルの設定を確認
- Test connectionで接続テスト
通知履歴を確認
- IssueのActivityタブで通知送信履歴を確認
- エラーメッセージがあれば詳細を確認

よくある原因と対処法

原因	症状	対処法
Workflow フィルタが厳しすぎる	一部のIssueのみ通知なし	フィルタ条件を緩和または削除
通知チャネルの認証エラー	全く通知が届かない	認証情報（Webhook URL、API Key）を再設定
Email アドレスの誤り	特定の人に届かない	Email アドレスを確認・修正
Slack チャネルの権限不足	Slack通知のみ失敗	New Relic Appをチャネルに招待

問題2: 通知が重複する

症状同じIssueに対して複数回通知が届く。

原因と対処法

複数のWorkflowがマッチしている
- 対処: Workflow のフィルタ条件を見直し、排他的にする
- 例: Workflow AはpolicyName == "Production-API"、Workflow BはpolicyName != "Production-API"
Issue Creation Preferenceが細かすぎる
- 対処: One issue per condition and signalからOne issue per conditionに変更
- 詳細: 各エンティティごとにIssueが作成され、それぞれに通知が送信されている
アラート条件が重複している
- 対処: 類似の条件を統合または削除
- 例: 同じメトリクスを監視する条件が複数のポリシーに存在

問題3: 通知内容が不明瞭

症状通知を受け取っても、何をすべきかわからない。

改善策

通知テンプレートをカスタマイズ
- 明確なタイトル: [CRITICAL] ${policyName} - ${conditionName}
- 影響範囲: 影響を受けるエンティティ数、ユーザー数
- アクションアイテム: 確認すべきダッシュボード、Runbookリンク
コンテキスト情報を追加
- 関連するNRQLクエリ
- 過去の類似インシデントへのリンク
- 推奨される対応手順
役割別にテンプレートを分ける
- 技術者向け: 詳細な技術情報
- マネージャー向け: ビジネス影響の要約

問題4: 営業時間外に不要な通知が大量に届く

症状深夜や週末に低優先度の通知が頻繁に届き、オンコール担当者を疲弊させる。

対処法

時間帯別Workflowを設定

Workflow: Business Hours Warning Alerts

Filter:
  - severity == "WARNING"
  - time >= "09:00" AND time <= "18:00"
  - day NOT IN ["Saturday", "Sunday"]

Destinations:
  - Slack #ops-warning
  - Email (営業時間内のみ)

営業時間外は日次サマリーに集約

Workflow: After Hours Summary

Schedule: Daily at 09:00 (営業時間開始時)

Filter:
  - severity == "WARNING" OR severity == "INFO"
  - createdAt BETWEEN "yesterday 18:00" AND "today 09:00"

Destinations:
  - Email (前日夜間～当日朝の全Warning/Infoをまとめて配信)

Critical のみ24/7通知

Workflow: Critical 24/7

Filter:
  - severity == "CRITICAL"

Destinations:
  - PagerDuty (always)
  - Slack #ops-critical (always)

まとめ

New Relic通知チャネルとWorkflowの効果的な設定は、技術的な配信機能の実装だけでなく、チームの働き方、責任体制、ビジネス要件への深い理解が必要です。適切な通知戦略により、問題の早期発見と迅速な対応を実現し、システムの可用性向上とチームの生産性向上を両立できます。

重要なポイントとして、役割別（開発者/マネージャー/ビジネス）に通知内容と配信チャネルを最適化すること、重要度別（Critical/Warning/Info）に配信速度と集約方法を調整すること、環境別（本番/ステージング/開発）に通知の積極性を調整すること、複数チャネルの冗長性で通知の確実性を高めること、時間帯別の配信制御でワークライフバランスを保護することを覚えておいてください。

次のステップとして、インシデントインテリジェンス機能と通知システムを統合し、自動相関とノイズ削減により、通知の精度と効果性をさらに向上させていきましょう。

New Relic通知チャネル設定 - 効果的なアラート配信戦略と実装ガイド ​

通知チャネルとWorkflowの概要 ​

通知チャネルとWorkflowの違い ​

通知戦略の基本原則 ​

主要な通知チャネルタイプと設定方法 ​

1. Email通知 ​

2. Slack統合 ​

3. PagerDuty連携 ​

4. Webhook統合 ​

5. モバイル通知（New Relicアプリ） ​

Workflow機能の活用 ​

Workflowの基本構造 ​

実践的なWorkflow設定例 ​

例1: 重要度別の配信戦略 ​

例2: サービス別・チーム別の配信 ​

例3: 時間帯別の配信制御 ​

例4: エスカレーション戦略 ​

Workflow設定のフロー図 ​

役割別・環境別の通知戦略 ​

役割別の通知設計 ​

1. 開発者・SREエンジニア向け ​

2. マネージャー・リーダー向け ​

3. ビジネスステークホルダー向け ​

環境別の通知設計 ​

本番環境（Production） ​

ステージング環境（Staging） ​

開発環境（Development） ​

よくある通知問題とトラブルシューティング ​

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

問題2: 通知が重複する ​

問題3: 通知内容が不明瞭 ​

問題4: 営業時間外に不要な通知が大量に届く ​

まとめ ​

New Relic通知チャネル設定 - 効果的なアラート配信戦略と実装ガイド

通知チャネルとWorkflowの概要

通知チャネルとWorkflowの違い

通知戦略の基本原則

主要な通知チャネルタイプと設定方法

1. Email通知

2. Slack統合

3. PagerDuty連携

4. Webhook統合

5. モバイル通知（New Relicアプリ）

Workflow機能の活用

Workflowの基本構造

実践的なWorkflow設定例

例1: 重要度別の配信戦略

例2: サービス別・チーム別の配信

例3: 時間帯別の配信制御

例4: エスカレーション戦略

Workflow設定のフロー図

役割別・環境別の通知戦略

役割別の通知設計

1. 開発者・SREエンジニア向け

2. マネージャー・リーダー向け

3. ビジネスステークホルダー向け

環境別の通知設計

本番環境（Production）

ステージング環境（Staging）

開発環境（Development）

よくある通知問題とトラブルシューティング

問題1: 通知が届かない

問題2: 通知が重複する

問題3: 通知内容が不明瞭

問題4: 営業時間外に不要な通知が大量に届く

まとめ