New Relicアラート概要 - 統合アラートシステムの全体像と実践ガイド ​

システムの運用において、問題が発生する前に異常を検知し、素早く対応することは極めて重要です。New Relicのアラート機能は、アプリケーション、インフラストラクチャ、ブラウザ、モバイル、Syntheticsなど、あらゆる監視データを統合して動作する包括的なアラートシステムです。従来の静的な数値監視に加えて、機械学習とパターン分析を活用した予測的なアラート機能も提供しており、ビジネスの中断を未然に防ぎます。この記事では、New Relicアラートの全体像を把握し、効果的な監視戦略を構築するための基礎知識と実践的なアプローチを解説します。

New Relicアラートシステムの全体像 ​

New Relicアラートは、単なる通知システムではなく、データ収集から評価、インシデント管理、通知、解決まで、一連のライフサイクル全体を管理する統合プラットフォームです。

アラートライフサイクルの5つのフェーズ ​

New Relicアラートシステムは、以下の5つのフェーズで動作します。

Phase 1: データ収集では、APMエージェント、Infrastructureエージェント、Browser監視、Mobile SDK、Syntheticsチェックなど、さまざまなソースから継続的にテレメトリデータが収集されます。このデータは、メトリクス、イベント、ログ、トレースの形式でNew Relicプラットフォームに送信され、リアルタイムで処理されます。

Phase 2: 条件評価では、収集されたデータがアラート条件と照合されます。Window Duration（集約期間）に基づいてデータがグループ化され、設定されたしきい値と比較されます。この評価は秒単位で継続的に実行され、問題の早期検出を実現します。

Phase 3: インシデント作成として、アラート条件に違反した状態が検出されると、インシデント（Incident）が作成されます。インシデントには、違反した条件、対象エンティティ、発生時刻、重要度（Critical/Warning）などの情報が含まれます。

Phase 4: Issue集約・通知では、関連するインシデントがIssueとしてグループ化されます。Issue Creation Preferenceの設定に基づいて、複数のインシデントが統合され、設定された通知チャネル（Email、Slack、PagerDutyなど）を通じて担当者に配信されます。

Phase 5: 対応・解決として、担当者がIssueを確認し、問題に対処します。問題が解決すると、インシデントが自動的にクローズされ、対応履歴が記録されます。この履歴は、将来の問題解決やアラート設定の改善に活用されます。

アラートシステムの中核的価値 ​

New Relicアラートシステムが提供する主要な価値は以下の通りです。

予防的問題検知により、システムに異常が発生する前に、パフォーマンスの劣化やリソース不足の兆候を検出します。Baseline Alert（異常検知アラート）を活用することで、通常のパターンから逸脱した初期段階で警告を受け取れます。

ノイズ削減とスマート通知では、関連するアラートを自動的にグループ化し、重要度に応じて通知を調整します。Incident Intelligenceの機械学習機能により、類似パターンのインシデントが統合され、アラート疲れを回避できます。

豊富なコンテキスト情報として、アラート発生時に関連するメトリクス、ログ、トレースデータが自動的に収集され、問題の根本原因分析を迅速に進められます。

柔軟な通知戦略により、役割に応じた通知とエスカレーション機能で、適切な担当者に適切なタイミングで情報を届けます。開発者には詳細な技術情報を、マネージャーにはビジネス影響度を中心とした情報を配信できます。

アラートタイプと監視戦略 ​

New Relicでは、監視対象とアラートの特性に応じて、複数のアラートタイプを提供しています。

Static Alert（静的アラート） ​

事前に定義されたしきい値に基づいて動作する従来型のアラートです。

特徴

  • 固定されたしきい値（例: CPU 80%、レスポンスタイム3秒）
  • 予測可能で理解しやすい
  • 設定が直感的

適用場面

  • 物理的な制約がある場合（ディスク使用率90%、メモリ使用率95%）
  • SLAで明確な基準が定義されている場合（APIレスポンス3秒以内）
  • 業界標準がある場合（Webページロード3秒以内）

設定例

sql
SELECT average(cpuPercent)
FROM SystemSample
WHERE hostname = 'prod-web-01'
  • Critical: 90%以上が5分継続
  • Warning: 75%以上が10分継続

Baseline Alert（動的アラート） ​

過去のデータからパターンを学習し、通常の振る舞いから逸脱した場合に発火するアラートです。

特徴

  • 過去7日間のデータから正常範囲を学習
  • 時間帯・曜日による変動を自動考慮
  • トレンドの変化に適応

適用場面

  • トラフィックが時間帯で大きく変動するサービス
  • 季節性のあるビジネスメトリクス
  • 新しいサービスで正常範囲が不明

設定例

sql
SELECT rate(count(*), 1 minute)
FROM Transaction
WHERE appName = 'ecommerce-web'
  • Baseline: 3標準偏差（上下両方向）
  • Duration: 10分継続

平日昼間の100 RPMも、夜間の1000 RPMも、それぞれの時間帯の正常範囲として学習され、異常な減少を検出できます。

Outlier Detection（外れ値検知） ​

複数のインスタンスやサーバー群の中で、他と異なる振る舞いを示すものを検出します。

特徴

  • 複数エンティティ間の比較
  • 絶対値ではなく相対的な異常を検出
  • オートスケーリング環境に最適

適用場面

  • 負荷分散された複数サーバーの監視
  • マイクロサービスの複数インスタンス監視
  • 特定インスタンスのみの問題検出

設定例

sql
SELECT average(duration)
FROM Transaction
WHERE appName = 'api-service'
FACET host
  • 設定: 他のホストと2標準偏差以上の差
  • Duration: 5分継続

10台のサーバーのうち、1台だけレスポンスタイムが遅い場合を検出できます。

Signal Loss Alert（データ欠損検知） ​

データの送信が停止した場合に発火するアラートです。

特徴

  • エージェント停止やネットワーク障害を検出
  • 監視システム自体の健全性を保証
  • 沈黙の失敗を防止

適用場面

  • APM/Infrastructureエージェントの動作監視
  • Syntheticsチェックの実行確認
  • 日次バッチジョブの実行確認

設定詳細 Signal Loss検知については、専用の記事で詳しく解説しています（Signal Loss検知の実装）。

アラートタイプ選択の比較表 ​

アラートタイプ学習時間変動対応複雑度適用場面
Static Alert不要非対応低物理制約、SLA基準
Baseline Alert自動（7日間）対応中時間変動大、季節性
Outlier Detection自動（リアルタイム）対応中複数インスタンス比較
Signal Loss不要-低エージェント監視

Golden Signals に基づく監視戦略 ​

Google SREが提唱するGolden Signalsは、システムの健全性を包括的に表現する4つの主要指標です。New Relicアラートでは、これらのシグナルを効果的に監視できます。

1. Latency（レイテンシ） ​

リクエストの処理に要する時間です。ユーザー体験に直接影響します。

監視すべきメトリクス

  • APMトランザクション時間（P95、P99）
  • データベースクエリ時間
  • 外部API呼び出し時間
  • ページロード時間（Browser）

NRQL例

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

推奨しきい値

  • Warning: P95が通常の1.5倍
  • Critical: P95が通常の2倍、またはSLA違反

2. Traffic（トラフィック） ​

システムへの需要の大きさです。異常な増減はいずれも問題を示す可能性があります。

監視すべきメトリクス

  • リクエスト数（RPM: Requests Per Minute）
  • アクティブユーザー数
  • データベース接続数
  • キュー内メッセージ数

NRQL例

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

推奨アラート

  • Baseline Alert（上下両方向）
  • 突然のトラフィック減少は障害の兆候
  • 突然のトラフィック増加はDDoS攻撃の可能性

3. Errors（エラー） ​

失敗したリクエストの割合です。ビジネスに直接的な影響を与えます。

監視すべきメトリクス

  • HTTPエラー率（4xx、5xx）
  • アプリケーション例外率
  • トランザクションエラー率
  • データベースエラー数

NRQL例

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

推奨しきい値

  • Warning: 0.5%以上
  • Critical: 1%以上（決済など重要サービスはさらに厳格に）

4. Saturation（飽和度） ​

システムリソースの使用状況です。キャパシティの限界に近づいている状態を検出します。

監視すべきメトリクス

  • CPU使用率
  • メモリ使用率
  • ディスク使用率/I/O
  • ネットワーク帯域幅
  • データベース接続プール使用率

NRQL例

sql
SELECT average(cpuPercent) AS 'CPU Usage',
       average(memoryUsedPercent) AS 'Memory Usage'
FROM SystemSample
WHERE hostname LIKE 'prod-app-%'
FACET hostname

推奨しきい値

  • Warning: 75%（キャパシティ計画の開始）
  • Critical: 90%（即座の対応が必要）

Golden Signals 監視の統合例 ​

以下は、1つのアプリケーションに対してGolden Signalsを統合したアラートポリシー設計例です。

ポリシー名 Production - WebApp - Golden Signals

アラート条件

  1. Latency P95レスポンスタイム > 3秒が5分継続
  2. Traffic Baseline Alert（3標準偏差、上下両方向）
  3. Errors エラー率 > 1%が3分継続
  4. Saturation - CPU CPU使用率 > 90%が10分継続
  5. Saturation - Memory メモリ使用率 > 95%が5分継続

Issue Creation Preference One issue per condition（問題の種類ごとに追跡）

Workflow

  • Critical → PagerDuty（即座のオンコール対応）
  • Warning → Slack #ops-alerts（チーム確認）

環境別のアラート戦略 ​

本番環境、ステージング環境、開発環境では、異なるアラート戦略が必要です。

本番環境（Production） ​

目的 ユーザー影響を最小化し、SLAを維持

特徴

  • 最も厳格なしきい値
  • 24時間365日の監視
  • 複数の通知チャネル
  • 迅速なエスカレーション

推奨設定

  • しきい値: SLA基準または95パーセンタイル値
  • 継続時間: 3～5分（迅速な検知）
  • Issue Preference: One issue per condition（詳細追跡）
  • 通知: PagerDuty（Critical）、Slack（Warning）

ポリシー例

Production - WebApp - Performance - Critical
Production - WebApp - Availability - Critical
Production - Infrastructure - Capacity - Warning
Production - Database - Performance - Critical

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

目的 本番環境と同様の監視で、デプロイ前の問題検出

特徴

  • 本番に準じた設定
  • テスト活動による一時的な負荷を考慮
  • 通知は開発チーム中心

推奨設定

  • しきい値: 本番の1.2～1.5倍（やや緩和）
  • 継続時間: 5～10分
  • Issue Preference: One issue per policy（ノイズ削減）
  • 通知: Slack（Warningのみ、Critical は Email）

ポリシー例

Staging - WebApp - Performance - Warning
Staging - Integration Tests - Errors - Info

開発環境（Development） ​

目的 開発者の作業を妨げず、重大な問題のみ検出

特徴

  • 緩いしきい値
  • 重大な問題（クラッシュ、完全停止）のみアラート
  • 通知は最小限

推奨設定

  • しきい値: 本番の2～3倍
  • 継続時間: 15分以上
  • Issue Preference: One issue per policy
  • 通知: Email のみ、または通知なし（ダッシュボードで確認）

ポリシー例

Dev - Critical Errors Only
Dev - Infrastructure - Extreme Usage

環境別設定の比較表 ​

設定項目本番環境ステージング開発環境
しきい値の厳格さ最も厳格中程度緩い
継続時間3～5分5～10分15分以上
監視範囲全メトリクス主要メトリクス重大問題のみ
通知チャネルPagerDuty+Slack+EmailSlack+EmailEmail のみ
エスカレーション即座営業時間内なし
24時間監視✅ あり⚠️ 営業時間のみ❌ なし

アラート成熟度モデル ​

組織のアラートシステムは、段階的に成熟していきます。以下のモデルに基づいて、継続的な改善を進めることができます。

レベル1: 基本監視（始めの1～2ヶ月） ​

特徴

  • 基本的なしきい値アラート（CPU、メモリ、ディスク）
  • メール通知のみ
  • 手動でのインシデント管理

目標

  • 壊滅的な障害を検出
  • アラート設定の基礎を確立

成功指標

  • 重大な障害は100%検出
  • 誤検知率: 30%以下

次のステップ 誤検知の分析としきい値の調整

レベル2: 統合監視（3～6ヶ月） ​

特徴

  • APM、Infrastructure、Browserの統合監視
  • Slackなど複数の通知チャネル
  • アラートポリシーの体系化

目標

  • アプリケーション層からインフラ層まで包括的監視
  • チーム連携の強化

成功指標

  • 問題検出までの平均時間: 5分以内
  • 誤検知率: 20%以下
  • アラート対応率: 70%以上

次のステップ データドドリブンなしきい値調整

レベル3: 最適化監視（6～12ヶ月） ​

特徴

  • データ分析に基づくしきい値設定
  • Baseline AlertとOutlier Detectionの活用
  • Issue Creation Preferenceの最適化

目標

  • 誤検知の最小化
  • 予防的な問題検出

成功指標

  • 問題検出までの平均時間: 3分以内
  • 誤検知率: 10%以下
  • アラート対応率: 80%以上
  • 予防的検出率: 30%以上（問題が深刻化する前に検出）

次のステップ AI/ML機能の導入

レベル4: インテリジェント監視（12ヶ月以降） ​

特徴

  • Incident Intelligenceによる自動相関
  • 予測的異常検知
  • 外部システムとの完全統合（PagerDuty、ServiceNow等）

目標

  • 自律的な問題検出と初期対応
  • 継続的な学習と改善

成功指標

  • 問題検出までの平均時間: 1分以内
  • 誤検知率: 5%以下
  • アラート対応率: 90%以上
  • 予防的検出率: 50%以上
  • 自動解決率: 20%以上

成熟度レベルの進化図 ​

学習パスと関連記事ガイド ​

New Relicアラートを効果的に活用するための推奨学習順序を示します。

ステップ1: 基礎概念の理解（この記事） ​

まず、この概要記事でアラートシステム全体像を把握します。

  • ✅ アラートライフサイクルの5フェーズ
  • ✅ アラートタイプ（Static/Baseline/Outlier/Signal Loss）
  • ✅ Golden Signals による監視戦略
  • ✅ 環境別アラート戦略

ステップ2: データ評価の仕組みを理解 ​

次に、アラートがどのようにデータを評価するかの詳細を学びます。

推奨記事 データポイント評価の基礎

学習内容:

  • Window Duration（集約期間）の設定
  • Aggregation Method（Event Flow/Event Timer）の使い分け
  • Sliding Window Aggregationでノイズ削減
  • Gap FillingとDelayの最適化

ステップ3: しきい値設計の習得 ​

データ分析に基づいた効果的なしきい値設定を学びます。

推奨記事 しきい値設計とチューニング

学習内容:

  • Static vs Anomaly Thresholdの使い分け
  • パーセンタイル分析に基づくしきい値決定
  • Critical/Warning 2段階設定
  • ノイズ削減のチューニング戦略

ステップ4: Signal Loss検知の実装 ​

監視システム自体の健全性を保証する方法を学びます。

推奨記事 Signal Loss検知の実装

学習内容:

  • Expiration Durationの決め方
  • Open/Close Violationsの使い分け
  • 想定される終了への対応
  • 実践的なユースケース（APM/Infrastructure/Batch）

ステップ5: アラートポリシーの実装 ​

実際にアラートポリシーを作成し、運用を開始します。

推奨記事 アラートポリシー設定ガイド

学習内容:

  • Issue Creation Preferenceの選択
  • NRQL Alert Conditionの作成（7つの実例）
  • Baseline Alertの活用
  • トラブルシューティング

ステップ6: 通知戦略の最適化 ​

適切な人に適切なタイミングで通知を届ける方法を学びます。

推奨記事 通知チャネル設定

学習内容:

  • 各種通知チャネルの設定（Email/Slack/PagerDuty/Webhook）
  • Workflow機能の活用
  • 役割別通知戦略
  • 通知効果の測定

ステップ7: 高度な機能の活用 ​

AI/ML機能でアラートシステムをさらに進化させます。

推奨記事 インシデントインテリジェンス

学習内容:

  • 自動相関とノイズ削減
  • 予測的異常検知
  • インシデント管理ワークフローの自動化

まとめ ​

New Relicアラートシステムは、包括的な監視から予防的な問題検出、効率的なインシデント管理まで、現代のシステム運用に必要なすべての機能を提供します。

重要なポイントとして、アラートライフサイクル全体（データ収集→評価→インシデント→Issue→通知→解決）を理解することで、効果的な設計が可能になること、Golden Signals（Latency/Traffic/Errors/Saturation）に基づく監視で、システムの健全性を包括的に把握できること、環境別（本番/ステージング/開発）に適切なしきい値と通知戦略を設定すること、アラート成熟度モデルに沿って、段階的にシステムを進化させることを覚えておいてください。

次のステップとして、この記事で概要を把握した後は、推奨学習パスに従って、データ評価の仕組み、しきい値設計、Signal Loss検知など、各トピックを深く学習していきましょう。実践的な知識を積み重ねることで、ビジネスに真に貢献するアラートシステムを構築できます。

関連記事: データポイント評価の基礎関連記事: しきい値設計とチューニング関連記事: Signal Loss検知の実装関連記事: アラートポリシー設定ガイド関連記事: 通知チャネル設定関連記事: インシデントインテリジェンス