New Relic Signal Loss（シグナルロス）検知の実装 - データ送信停止の確実な検出 ​

システム監視において、メトリクスの値がしきい値を超えることを検知するだけでは不十分です。監視エージェントの停止、ネットワーク障害、アプリケーションのクラッシュなどにより、データ送信そのものが停止してしまう状況を検出することも同様に重要です。New RelicのSignal Loss（シグナルロス）検知機能は、このようなデータ送信の停止を自動的に検出し、システムの健全性を包括的に監視します。この記事では、Signal Lossの概念から具体的な設定方法、実践的なユースケースまでを詳しく解説します。

Signal Lossとは何か ​

Signal Lossは、監視対象からのデータ送信が一定期間途絶えた状態を指します。通常のアラート条件が「メトリクス値の異常」を検出するのに対し、Signal Loss検知は「データそのものの欠落」を検出する機能です。

Signal Lossが発生する主な原因 ​

Signal Lossは、さまざまな理由で発生する可能性があります。最も一般的なのは、監視エージェントの停止です。New Relic APMエージェントやInfrastructureエージェントがクラッシュしたり、意図せず停止したりすると、データ送信が途絶えます。

ネットワーク障害もSignal Lossの主要な原因です。監視対象サーバーとNew Relicプラットフォーム間のネットワーク接続が切断されると、エージェントは正常に動作していてもデータが届きません。ファイアウォール設定の変更や、クラウド環境でのネットワーク構成ミスなども該当します。

アプリケーションのクラッシュやサーバーのダウンも、Signal Lossとして検出されます。Webアプリケーションが完全に停止した場合、APMデータの送信も停止します。インフラストラクチャ全体がダウンした場合は、すべての監視データが停止します。

さらに、データソース自体の終了もSignal Lossの原因となります。例えば、オートスケーリング環境でインスタンスが正常に終了した場合や、コンテナがスケールダウンした場合も、そのデータソースからの送信は停止します。

Signal Loss検知の重要性 ​

従来のしきい値ベースのアラートだけでは、データが送信されていない状態を検出できません。例えば、CPU使用率が90%を超えたらアラートという設定では、サーバーがダウンしてCPUデータが送信されなくなっても、アラートは発火しません。これは「沈黙の失敗」とも呼ばれる危険な状態です。

Signal Loss検知を設定することで、監視システム自体の健全性を保証できます。エージェントが動作していることを確認し、データ収集パイプライン全体が機能していることを検証できます。これにより、いざという時にアラートシステムが機能しないという最悪の事態を防ぐことができます。

Signal Loss検知はまた、インシデントのライフサイクル管理にも役立ちます。問題が解決してデータ送信が再開された際に、自動的にインシデントをクローズする設定も可能です。これにより、手動でのインシデント管理負荷を軽減できます。

Signal Loss検知の仕組み ​

New RelicのSignal Loss検知は、最後のデータポイントを受信してからの経過時間を追跡することで動作します。設定された期間内に新しいデータポイントが到着しない場合、Signal Lossと判定されます。

評価の基本メカニズム ​

Signal Loss検知は、データポイントの到着時刻に基づいて動作します。重要なのは、データのタイムスタンプではなく、New Relicプラットフォームにデータが到着した実際の時刻を基準にしているという点です。これにより、遅延したデータが後から到着した場合でも、適切にSignal Loss判定がリセットされます。

評価サイクルとして、New Relicは継続的にデータの到着を監視しており、最後のデータポイント受信時刻から設定された「Expiration Duration（有効期限）」が経過すると、Signal Lossアクションがトリガーされます。例えば、Expiration Durationを120秒に設定した場合、最後のデータポイントから2分間新しいデータが到着しなければ、Signal Lossと判定されます。

このメカニズムは、データ送信の頻度に関係なく動作します。1秒ごとにデータを送信するメトリクスでも、1時間ごとのバッチジョブでも、適切なExpiration Durationを設定することで正確に検知できます。

Signal Loss検知のフロー図 ​

以下の図は、Signal Loss検知の動作フローを示しています。

このフローからわかるように、データの送信と停止を継続的に監視し、設定に応じて適切なアクションが自動的に実行されます。

Signal Loss検知の設定方法 ​

New RelicでSignal Loss検知を設定するには、アラート条件作成時または既存条件の編集時に、Expiration設定を行います。

基本的な設定パラメータ ​

Signal Loss検知には3つの主要なパラメータがあります。

**Expiration Duration（有効期限）**は、最後のデータポイント受信後、どれだけの時間（秒単位）待ってからSignal Lossと判定するかを指定します。例えば、120秒に設定すると、2分間データが届かない場合にSignal Lossとなります。デフォルト値はnull（無効）で、明示的に設定する必要があります。

**Open violation on expiration（期限切れ時にインシデント作成）**は、Signal Loss発生時に新しいインシデントを作成するかどうかを指定します。trueに設定すると、データ送信が停止した際に新規インシデントが作成され、通知が送信されます。デフォルトはfalseです。

**Close violations on expiration（期限切れ時にインシデントクローズ）**は、Signal Loss発生時に、関連する既存のオープンインシデントをクローズするかどうかを指定します。trueに設定すると、データ送信が停止した際に、そのエンティティに関連する既存のインシデントが自動的にクローズされます。デフォルトはfalseです。

これらのパラメータを組み合わせることで、さまざまなシナリオに対応できます。

UI での設定手順 ​

New RelicのWebインターフェースからSignal Loss検知を設定する手順は以下の通りです。

まず、New Relicにログインし、「Alerts & AI」メニューから「Alert conditions」を選 択します。新規のNRQLアラート条件を作成するか、既存の条件を編集します。

アラート条件の設定画面で、「Advanced signal settings」セクションまでスクロールします。ここに「Loss of signal」または「Expiration」という設定項目があります。

「Expiration duration」フィールドに、Signal Lossと判定するまでの秒数を入力します。例えば、300と入力すれば5分間データが届かない場合にSignal Lossと判定されます。

次に、Signal Loss発生時のアクションを選択します。「Open new incident when signal is lost」をオンにすると、データ停止時に新規インシデントが作成されます。「Close all current open incidents when signal is lost」をオンにすると、既存インシデントがクローズされます。

設定を保存してアラート条件を有効化すれば、Signal Loss検知が動作開始します。

NerdGraph API での設定 ​

より高度な設定や、自動化されたアラート管理には、New RelicのNerdGraph APIを使用できます。

以下は、Signal Loss検知を含むNRQLアラート条件を作成するGraphQLミューテーション例です。

graphql
mutation {
  alertsNrqlConditionStaticCreate(
    accountId: YOUR_ACCOUNT_ID
    policyId: YOUR_POLICY_ID
    condition: {
      name: "Host Monitor - Signal Loss Detection"
      enabled: true
      nrql: {
        query: "SELECT uniqueCount(host) FROM Transaction WHERE appName='production-app'"
      }
      signal: {
        aggregationWindow: 60
        aggregationMethod: EVENT_FLOW
        aggregationDelay: 120
      }
      terms: [{
        threshold: 1
        thresholdOccurrences: AT_LEAST_ONCE
        thresholdDuration: 300
        operator: BELOW
        priority: CRITICAL
      }]
      expiration: {
        expirationDuration: 300
        openViolationOnExpiration: true
        closeViolationsOnExpiration: false
      }
    }
  ) {
    id
    name
  }
}

この例では、expirationDurationを300秒（5分）に設定し、openViolationOnExpirationをtrueにしているため、5分間データが届かない場合に新規インシデントが作成されます。

既存のアラート条件のSignal Loss設定を更新する場合は、以下のようなミューテーションを使用します。

graphql
mutation {
  alertsNrqlConditionStaticUpdate(
    accountId: YOUR_ACCOUNT_ID
    id: CONDITION_ID
    condition: {
      expiration: {
        expirationDuration: 600
        openViolationOnExpiration: true
        closeViolationsOnExpiration: false
      }
    }
  ) {
    id
    expiration {
      expirationDuration
      openViolationOnExpiration
      closeViolationsOnExpiration
    }
  }
}

この更新により、Expiration Durationが10分に変更されます。

Expiration Duration（有効期限）の決め方 ​

適切なExpiration Durationの設定は、Signal Loss検知の精度に直接影響します。短すぎると誤検知が増え、長すぎると検知が遅れてしまいます。

データ送信頻度に基づく設定 ​

基本的な考え方として、Expiration Durationはデータ送信間隔の2～3倍に設定するのが推奨されます。

APMメトリクスの場合、通常は1分ごとにデータが送信されます。この場合、Expiration Durationを120～180秒（2～3分）に設定することで、一時的なネットワーク遅延による誤検知を防ぎつつ、真のSignal Lossを迅速に検出できます。

Infrastructureメトリクスも同様に1分間隔でデータが送信されますが、サーバーの負荷状況によって若干の遅延が発生することがあります。そのため、180～300秒（3～5分）程度の設定が適切です。

Syntheticsモニタリングは、通常5分～15分間隔で実行されます。Syntheticsチェックが1回失敗しただけでSignal Lossとするか、複数回連続で失敗してからSignal Lossとするかを検討し、適切な値を設定します。例えば、5分間隔のSyntheticsなら、Expiration Durationを600秒（10分）に設定すれば、1回の失敗では反応せず、2回連続失敗で検知されます。

低頻度データでの考慮事項 ​

日次バッチジョブなど、低頻度でデータが送信されるケースでは、特別な考慮が必要です。

バッチジョブが毎日深夜2時に実行され、実行時にのみデータを送信する場合を考えてみましょう。この場合、Expiration Durationを24時間30分（87,000秒）程度に設定します。24時間ぴったりではなく、30分のバッファを持たせることで、バッチの実行時刻が若干ずれても誤検知しないようにします。

週次レポート生成など、さらに低頻度のジョブでは、ジョブのスケジュール間隔に応じてExpiration Durationを設定します。ただし、あまりにも長い期間に設定すると、問題の検出が大幅に遅れるため、ビジネス要件とのバランスを考慮する必要があります。

環境別の推奨設定値 ​

以下の表は、各種データソースと環境別の推奨Expiration Duration設定をまとめたものです。

データソース送信頻度本番環境ステージング環境開発環境
APM メトリクス1分180秒（3分）300秒（5分）600秒（10分）
Infrastructure1分300秒（5分）600秒（10分）900秒（15分）
Browserリアルタイム120秒（2分）180秒（3分）300秒（5分）
Synthetics（5分間隔）5分600秒（10分）900秒（15分）1200秒（20分）
日次バッチ24時間87000秒（24.2時間）90000秒（25時間）-

本番環境では迅速な検知が重要なため短めに、開発環境では誤検知を避けるため長めに設定しています。

Signal Loss時のアクション設定 ​

Signal Lossが検出された際に、どのようなアクションを取るかは、監視対象の性質とビジネス要件によって異なります。

新規インシデント作成（Open Violation） ​

openViolationOnExpirationをtrueに設定すると、Signal Loss発生時に新しいインシデントが作成されます。これは、データ送信の停止を積極的に検出し、アラートを発報したい場合に使用します。

この設定が適しているのは、常時稼働すべきサービスの監視です。本番環境のWebアプリケーション、APIサーバー、データベースなど、24時間365日稼働が期待されるシステムでは、データ送信が停止したこと自体が重大な問題を示している可能性が高いため、即座にインシデントを作成して担当者に通知すべきです。

また、クリティカルなインフラストラクチャの監視にも適しています。ロードバランサー、ファイアウォール、ストレージシステムなど、システムの基盤となるコンポーネントの監視データが途絶えた場合、迅速な対応が必要です。

一方、開発環境やテスト環境では、意図的にシステムを停止することが頻繁にあるため、openViolationOnExpirationをfalseにするか、後述する「想定される終了」の設定を併用します。

既存インシデントクローズ（Close Violations） ​

closeViolationsOnExpirationをtrueに設定すると、Signal Loss発生時に、そのエンティティに関連する既存のオープンインシデントが自動的にクローズされます。これは一見奇妙に思えるかもしれませんが、特定のシナリオで非常に有用です。

この設定が役立つのは、オートスケーリング環境です。クラウド環境で、負荷に応じてインスタンスが自動的にスケールアウト/スケールインする場合、インスタンスが終了してもインシデントが残り続けると、ノイズが増加します。インスタンスの終了と同時にそのインシデントをクローズすることで、現在アクティブな問題のみに焦点を当てられます。

一時的な問題の自動解決にも使えます。例えば、一時的なネットワーク問題で監視データが途絶え、その後サービスが完全にダウンした場合、ネットワーク問題のインシデントは自動的にクローズされ、より重大な問題（サービスダウン）に集中できます。

ただし、この設定を使う際は注意が必要です。真の問題が発生している際にデータが途絶えた場合、インシデントが自動クローズされてしまい、問題を見逃す可能性があります。そのため、openViolationOnExpirationとcloseViolationsOnExpirationの両方をtrueにする設定は、慎重に検討する必要があります。

アクション設定の組み合わせパターン ​

以下の表は、一般的なアクション設定パターンとその使用ケースをまとめたものです。

openViolationcloseViolations使用ケース動作
truefalse本番環境の常時監視Signal Loss時に新規インシデント作成のみ
falsetrueオートスケーリング環境Signal Loss時に既存インシデントをクローズのみ
truetrue一時的リソースの監視Signal Loss時に既存クローズ＆新規作成
falsefalse開発環境Signal Lossを記録するが通知しない

最も一般的なのは、openViolation: true, closeViolations: falseの組み合わせで、Signal Lossを確実に検出しつつ、既存インシデントには影響を与えません。

想定される終了への対応 ​

システムの正常なメンテナンスやスケールダウンなど、意図的にデータ送信を停止する場合、不要なSignal Lossインシデントが作成されてしまうことがあります。New Relicでは、これを防ぐための機能が提供されています。

Ignore On Expected Termination設定 ​

ignoreOnExpectedTerminationパラメータをtrueに設定すると、エンティティが「想定される終了」をマークされている場合、Signal Loss時にインシデントが作成されなくなります。

この機能を有効にするには、監視対象エンティティに特定のタグを付与する必要があります。termination: expectedというタグが存在する場合、そのエンティティからのSignal Lossはインシデントを生成しません。

Infrastructureホストエンティティの場合、hostStatus: shutdownというタグも認識されます。これにより、サーバーのグレースフルシャットダウン時にSignal Lossインシデントが作成されるのを防げます。

タグの付与方法 ​

エンティティにタグを付与する方法はいくつかあります。

New Relic UIからの手動タグ付けでは、対象エンティティのページを開き、「Tags」セクションでtermination: expectedタグを追加します。計画的なメンテナンス前に手動でタグを追加し、メンテナンス完了後に削除するという運用が可能です。

自動タグ付けでは、Infrastructure エージェントの設定ファイルやAPMエージェントの設定で、カスタムタグを定義できます。例えば、環境変数や設定ファイルでtermination: expectedを設定することで、特定の条件下で自動的にタグが付与されます。

API経由でのタグ管理では、NerdGraph APIを使用して、プログラマティックにタグを追加・削除できます。CI/CDパイプラインやオーケストレーションツールと統合し、デプロイメント時に自動的にタグを管理することが可能です。

実装例 ​

以下は、NerdGraph APIを使用してエンティティにタグを追加する例です。

graphql
mutation {
  taggingAddTagsToEntity(
    guid: "ENTITY_GUID"
    tags: [
      {
        key: "termination"
        values: ["expected"]
      }
    ]
  ) {
    errors {
      message
    }
  }
}

このミューテーションを実行することで、指定したエンティティにtermination: expectedタグが追加され、Signal Lossインシデントの作成が抑制されます。

実践的なユースケース ​

ここでは、異なる監視シナリオにおけるSignal Loss検知の具体的な実装例を紹介します。

APMアプリケーション監視 ​

本番環境のWebアプリケーションに対して、APMデータの停止を検出する設定例です。

シナリオ ECサイトのWebアプリケーションが24時間365日稼働している。APMエージェントからのデータが途絶えた場合、アプリケーションクラッシュまたはエージェント停止の可能性があるため、即座に検知したい。

設定内容

  • Expiration Duration: 180秒（3分）
  • Open Violation On Expiration: true（インシデント作成）
  • Close Violations On Expiration: false
  • Ignore On Expected Termination: false

NRQLクエリ例:

sql
SELECT count(*)
FROM Transaction
WHERE appName = 'production-ecommerce'

この設定では、3分間Transactionデータが到着しない場合、Signal Lossインシデントが作成され、オンコール担当者に通知されます。

Infrastructure監視 ​

複数のサーバーで構成されるインフラストラクチャの監視例です。

シナリオ 10台のWebサーバーで負荷分散されているシステム。個々のサーバーからのInfrastructureデータが途絶えた場合を検出したい。オートスケーリングによる正常な終了は除外したい。

設定内容

  • Expiration Duration: 300秒（5分）
  • Open Violation On Expiration: true
  • Close Violations On Expiration: true（正常終了時の既存インシデントをクリーンアップ）
  • Ignore On Expected Termination: true（オートスケーリングによる終了を除外）

NRQL クエリ例:

sql
SELECT latest(cpuPercent)
FROM SystemSample
WHERE hostname LIKE 'web-server-%'
FACET hostname

この設定では、各サーバーを個別に監視し、Signal Loss時にインシデントを作成します。オートスケーリングでサーバーが正常終了する際は、hostStatus: shutdownタグが自動的に付与されるため、不要なインシデントは作成されません。

Synthetics監視 ​

外部からのSyntheticsモニタリングでSignal Lossを検出する例です。

シナリオ 重要なAPIエンドポイントを5分ごとにSyntheticsでチェックしている。Syntheticsモニター自体が動作しなくなった場合を検出したい。

設定内容

  • Expiration Duration: 900秒（15分） - 3回連続失敗相当
  • Open Violation On Expiration: true
  • Close Violations On Expiration: false
  • Ignore On Expected Termination: false

NRQLクエリ例:

sql
SELECT count(*)
FROM SyntheticCheck
WHERE monitorName = 'API Health Check'

この設定では、15分間Syntheticsチェックの結果データが届かない場合、モニター自体に問題があると判断してインシデントを作成します。

日次バッチジョブ監視 ​

定期的に実行されるバッチジョブの実行確認例です。

シナリオ 毎日深夜2時に実行されるデータ集計バッチジョブ。ジョブが実行されるとカスタムイベントが送信される。ジョブが24時間以上実行されていない場合を検出したい。

設定内容

  • Expiration Duration: 87000秒（24時間10分） - 24時間＋バッファ
  • Open Violation On Expiration: true
  • Close Violations On Expiration: false
  • Ignore On Expected Termination: false

NRQLクエリ例:

sql
SELECT count(*)
FROM BatchJobEvent
WHERE jobName = 'daily-aggregation'

この設定では、24時間10分以内にバッチジョブの実行イベントが到着しない場合、ジョブが実行されなかったと判断してインシデントを作成します。10分のバッファにより、実行時刻の若干のずれを許容します。

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

Signal Loss検知を運用する中で遭遇する可能性のある問題と、その対処法を紹介します。

誤検知が多い場合 ​

症状 Signal Lossインシデントが頻繁に作成されるが、実際にはデータは送信されている。

原因と対処法

Expiration Durationが短すぎる可能性があります。データ送信間隔と比較して、Expiration Durationが適切か確認してください。送信間隔の2～3倍に延長することを検討します。

ネットワーク遅延が発生している可能性もあります。データのタイムスタンプと実際の到着時刻を比較し、大幅な遅延が常態化している場合は、Expiration Durationを延長するか、ネットワーク問題を解決してください。

Aggregation Delayとの関係も確認が必要です。Aggregation Delayが長い場合、データの評価自体が遅れるため、Expiration DurationもそれNを考慮した値に設定する必要があります。

Signal Lossが検知されない場合 ​

症状 データ送信が実際に停止しているのに、Signal Lossインシデントが作成されない。

原因と対処法

Expiration Durationが設定されていない可能性があります。アラート条件の設定を確認し、Expiration Durationが明示的に設定されているか確認してください。デフォルトはnull（無効）です。

openViolationOnExpirationがfalseになっている可能性もあります。Signal Loss検出時にインシデントを作成する設定になっているか確認してください。

ignoreOnExpectedTerminationがtrueで、エンティティにtermination: expectedタグが付与されている場合も、インシデントは作成されません。意図しないタグ付与がないか確認してください。

データが完全に停止しておらず、散発的に送信されている可能性もあります。クエリビルダーでデータの到着パターンを分析し、実際の動作を確認してください。

インシデントが自動クローズする問題 ​

症状 Signal Lossインシデントが意図せず自動的にクローズされてしまう。

原因と対処法

closeViolationsOnExpirationがtrueになっている可能性があります。この設定が意図的なものか確認し、不要であればfalseに変更してください。

データが一時的に復旧した後、再び停止している可能性もあります。Signal Lossの履歴を確認し、データ送信パターンを分析してください。

別のアラート条件やワークフローが、インシデントを自動クローズしている可能性も考えられます。インシデントのアクティビティログを確認し、クローズの理由を特定してください。

まとめ ​

Signal Loss（シグナルロス）検知は、New Relicアラートシステムにおいて、メトリクス値の監視と並ぶ重要な機能です。データ送信そのものの停止を検出することで、監視システムの盲点をなくし、システムの健全性を包括的に保証できます。

重要なポイントとして、Expiration Durationはデータ送信頻度の2～3倍を目安に設定すること、常時稼働すべきシステムではopenViolationOnExpiration: trueでインシデントを確実に作成すること、オートスケーリング環境ではignoreOnExpectedTerminationを活用して誤検知を防ぐこと、低頻度データ（バッチジョブなど）でもSignal Loss検知が有効であることを覚えておいてください。

Signal Loss検知を適切に設定することで、エージェントの停止、ネットワーク障害、アプリケーションクラッシュなど、さまざまな問題を早期に検出し、システムの可用性を高めることができます。次のステップとして、しきい値の設計とチューニングについて学習し、より精度の高いアラートシステムを構築していきましょう。

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