概要
- New Relic は、エージェントや OpenTelemetry データから NRDB、NRQL アラート条件、異常モデル、相関、通知ワークフローに至る一貫したパスを提供します。これは手動のダッシュボード監視を置き換え、調査を短縮できますが、正しく収集、命名、保持、クエリされたシグナルのみが検出可能です。
- プラットフォーム自身のドキュメントは、通常の運用を複雑にする状況を特定しています。受け入れられたテレメトリリクエストが後続の検証で失敗する可能性、サンプリングされたトレースがスパンを欠く可能性、まばらまたは遅延したデータが誤って評価される可能性、条件を編集するとその評価と異常履歴がリセットされる可能性、そしてミュートやルーティングの選択がオペレーターが期待したページを抑制する可能性があります。
- ベンダーのケーススタディは、アラート量と解決時間の大幅な削減を報告しており、New Relic の 2026 年の分析では、AI 対応アカウントがノイズが少なく、問題クローズが速いと関連付けられています。これらは本番使用の信頼できる兆候ですが、新規顧客が受ける効果の管理された推定値ではありません。計装の品質、チームの成熟度、高度な機能への選択は交絡因子のままです。
- 健全な購入ケースでは、実用的なアラートあたりのコストを使用します。プラットフォームとテレメトリの料金、計装、クエリガバナンス、チューニング、トリアージ、インシデントレビュー、移行コストを、実際の状態を特定し、適切な担当者に時間内に届き、有用なアクションをサポートするページで割ります。顧客に影響を与える見逃された障害は、アラートを生成しなかったとしても、分母で障害として残ります。
アラートはチェーンの終端であり、始まりではない
最も単純な New Relic のデモはチャートから始まります。アプリケーションエージェントが応答時間とエラーを報告し、ラインが上昇し、NRQL 条件がしきい値を超え、Slack または PagerDuty がメッセージを受信します。この一連の流れを自動化された検出として説明するのは簡単です。そのメッセージがアクションに値するために何が真であり続けなければならなかったかを説明するのはより困難です。
アプリケーションは障害の証拠を出力しなければなりませんでした。エージェントまたはコレクターが有用なフィールドを保持し、配信しなければなりませんでした。サービス名やその他の属性は、正しい本番コンポーネントを特定しなければなりませんでした。NRDB はクエリが期待するレコードを保持し、公開しなければなりませんでした。クエリは単なる異常な内部状態ではなく、ユーザーへの害を表現しなければなりませんでした。その集計ウィンドウと遅延または欠落データの扱いは、ソースに適合しなければなりませんでした。静的なしきい値または学習されたベースラインは、通常の変動と問題を区別しなければなりませんでした。相関は、無関係な障害を統合することなく症状をグループ化しなければなりませんでした。ワークフローは結果の問題に一致し、宛先の認証情報とオンコールの所有権が最新でなければなりませんでした。最後に、エンジニアは行動するための十分なコンテキストと権限を必要としました。
New Relic はほぼすべての段階で重要な機構を提供します。それがすべての段階で真実を所有しているわけではありません。顧客のコード、クラウド統合、OpenTelemetry コンポーネント、ネットワーク配信、サードパーティのインシデントツール、人間のサービス知識は、本番システムの一部であり続けます。上流で見逃されたシグナルは、下流のより優れたアラートモデルで回復することはできません。正しく検出されたしきい値は、古くなったルーティングタグを修正できません。説得力のある問題サマリーは、所有者のいないサービスを実用的にすることはできません。
そのため、有用な分母は作成されたアラートイベントではありません。それは実用的なアラートです。つまり、注意を必要とする実際の状態に対応し、結果を改善するのに十分早く到着し、適切な所有者に届き、診断を開始するのに十分な証拠を含み、正当化されたアクションにつながる通知です。この定義は意図的に厳格です。自動化が作業を変える場合にのみ、自動化に対してクレジットを与えます。
また、2 つの異なるエラーを明らかにします。偽陽性または低価値のアラートは、サービスを改善することなく注意を消費します。見逃されたアラートは、ユーザー、別のモニター、またはエンジニアが気付くまで害が進行するのを許します。感度の調整は通常、一方を他方とトレードオフします。継続時間や遅延を増やすと、検出時間は延びますが、過渡的なノイズを抑制できます。異常範囲を狭めると、より小さな偏差を検出できますが、ページ数が増加します。見逃された支払い障害のコストは、一時的なバックグラウンドジョブの遅延のコストとは異なるため、普遍的な設定でこの交換を解決することはできません。
New Relic はプラットフォームを所有するが、顧客のサービスモデルは所有しない
New Relic は新しいアラートのラッパーではなく、長年確立された可観測性企業です。公開企業としての最後の年次報告書では、メトリクス、イベント、ログ、トレースを分析ツールと組み合わせたプラットフォームを説明し、2023 年度の収益を 9 億 2,560 万ドルと報告し、16,000 以上の有料顧客にサービスを提供していると述べています。また、提出書類では Datadog と Dynatrace を直接の統合可観測性競合として挙げ、大企業が独自の機能を構築できることを認めました。2023 年 11 月、Francisco Partners と TPG が 65 億ドルの買収を完了し、その後 New Relic の株式は公開取引を停止しました。
製品の境界は広範ですが、依然として定義可能です。New Relic は、ホストされたデータおよび分析プラットフォーム、NRDB、NRQL、独自のエージェント、アラート、ダッシュボード、インシデントインテリジェンス、通知設定を運用しています。ベンダーニュートラルな OpenTelemetry エコシステムやその他の統合を通じて生成されたテレメトリを受け入れます。OpenTelemetry 自体は、API、SDK、セマンティック規約、OTLP プロトコル、コレクターを備えた CNCF プロジェクトであり、New Relic 製品ではありません。PagerDuty、Slack、ServiceNow、Jira、クラウドサービス、顧客のランブックも、New Relic がデータを送信しても、同様に独立したシステムのままです。
この区別は、成功と失敗の両方を割り当てる際に重要です。New Relic エージェントがサポートされているフレームワークを自動的に計装し、チームが以前は見ることができなかったエラーを公開した場合、エージェントとプラットフォームは真の評価に値します。OpenTelemetry コレクターがキューサイズ不足のためにデータをドロップした場合、検出の失敗を NRDB だけに帰することはできません。New Relic が問題を作成したが、期限切れの webhook シークレットが配信を妨げた場合、ホストされたアラート計算は機能しましたが、運用結果は失敗しました。調達は依然として結果をカウントすべきです。なぜなら、顧客はエンドツーエンドの機能を購入したからですが、エンジニアリングは失敗したレイヤーを正確に特定する必要があります。
法的および商業的な境界も重要です。対象となる Pro および Enterprise 注文に対する New Relic のサービスレベルコミットメントは、ログインして顧客データを表示する能力を中心に可用性を定義し、商業的に合理的な努力ベースで月間 99.8% の可用性を目標とし、顧客のテクノロジー、サードパーティサービス、公衆インターネット伝送などの原因を除外しています。標準プランや一部の使用量ベースの契約では、同じコミットメントは受けられません。これは、「すべての重要なアラートが正確かつ時間通りに届く」というよりも狭い約束です。購入者は、プラットフォームの可用性からアラート結果の保証を推測するのではなく、実際の注文書、サポートプラン、外部通知契約を読む必要があります。
計装が知り得ることを決定する
New Relic は、言語およびインフラストラクチャエージェント、ブラウザーおよびモバイルコンポーネント、クラウド統合、API、Prometheus、OpenTelemetry からテレメトリを取り込むことができます。多くのインシデントがレイヤーを超えるため、この幅広さは価値があります。上昇する HTTP エラー率は、デプロイ、データベース待機、飽和したホスト、または失敗した依存関係に結び付けられると、より有用です。同じ幅広さはガバナンス作業を生み出します。より多くのソースは、より多くの属性、より多くの命名規則、より多くのコスト、そして同等に見える 2 つのシグナルが異なることを意味する可能性を生み出します。
OpenTelemetry はプロプライエタリな計装のロックインを減らしますが、計装設計を取り除くわけではありません。New Relic のOpenTelemetry リソースガイダンスでは、リソース属性がエンティティの合成に使用され、サービスにはservice.nameが必須であり、インスタンスを区別するためにservice.instance.idなどのフィールドが推奨されると説明しています。サービス名が欠落しているか不安定な場合、インターフェースに表示されるものとアラートがファセット化するものが変わります。デプロイに存在しない環境タグは、本番データをステージング向けのクエリにルーティングしたり、両方の外に残したりする可能性があります。
トランスポート応答が成功しても、使用可能なデータが到着したことを証明するわけではありません。New Relic のOTLP エンドポイントドキュメントでは、ペイロードは 1 メガバイト未満に保ち、エクスポーターは適切にバッチ処理し、圧縮を有効にし、一時的な障害を再試行し、レート制限を考慮する必要があると述べています。さらに微妙なことに、エンドポイントは認証、ペイロードサイズ、レート制限を確認した後に応答しますが、コンテンツの検証は非同期で行われます。したがって、成功ステータスは、後でNrIntegrationErrorとして記録される取り込み失敗の前に発生する可能性があります。HTTP の成功のみを確認するオペレーターは、玄関までの配信を検証したにすぎず、クエリ可能なテレメトリを検証したわけではありません。
New Relic エージェントは独自の選択を導入します。イベント上限とサンプリングは、アプリケーションとプラットフォームのオーバーヘッドを制御するために存在します。イベントサンプリングドキュメントは、サンプリングされたイベントデータがサンプリングされていないメトリクスと一致しない可能性があり、切断時間が長くなると、ローカルに保存されたデータからのサンプリングが増えると警告しています。分散トレーシングでは、一般的な構成で適応型サンプリングを使用します。欠落トレースガイドでは、トレースが不完全に見える理由として、エクスポーターの欠如、サンプリング、スパン制限、遅延スパン、クロックスキュー、クロスアカウント権限などを挙げています。
これにより、サンプリングされた可観測性が信頼できなくなるわけではありません。サンプリングは、オーバーヘッドとコストを制御するための合理的な方法であることがよくあります。つまり、クエリ設計者は、どの証拠が完全で、どれが推定であり、どれが選択されたかを知る必要があります。適切に集計されたメトリクスに基づいて構築されたエラー率アラートは、個々のトレースが欠落していても堅牢です。すべての失敗したトランザクションに完全なトレースがあると仮定するフォレンジッククエリはそうはいきません。プラットフォームの基本的な機能は、提供されたデータを保存および評価することです。製品の信頼性には、収集の失敗をどれだけ明確に公開するかが含まれます。展開の信頼性は、顧客がそれらの失敗を監視し、それらを回避する設計を行うかどうかに依存します。
計装は変化するソフトウェアでもあります。エージェントのリリースでは、フレームワークのサポートが追加され、デフォルトが変更され、欠陥が修正されます。OpenTelemetry のセマンティック規約は進化します。New Relic は、ネイティブ計装から OpenTelemetry API に切り替えると、Elasticsearch や RabbitMQ などのシステムで異なるスパン名やメトリクス名が生成され、正確な名前に依存するダッシュボードやアラートが壊れる可能性があると指摘しています。したがって、アップグレードプログラムにはテレメトリ契約テストが必要です。既知のトランザクション、エラー、依存関係呼び出しをデプロイし、予想される属性とエンティティの関連付けを確認し、新しいエージェントまたはコレクター構成をプロモートする前にアラートクエリを比較します。
繰り返し発生する作業は、単にエージェントをインストールすることだけではありません。誰かがバージョンを維持し、エクスポーターとエージェントのエラーを検査し、機密フィールドを制御し、命名規則を維持し、計装されていないサービスを特定し、サンプリングを決定し、変更後にテレメトリをテストする必要があります。自動計装は最初の週を速くすることができますが、次の 3 年間を所有者なしにすることはできません。
NRQL は運用判断を実行可能な条件に変換する
NRQL は、チームが共通のデータストアに対して検出ロジックを表現できるため、New Relic の最も強力な機能の 1 つです。条件は、エラーの割合、レイテンシのパーセンタイル、キューの深さ、ビジネスイベントのカウント、またはテレメトリから導出されるほぼすべての数値結果を監視できます。ファセット化により、1 つの条件を多くのサービス、ホスト、またはテナントに適用できます。これは、固定インフラストラクチャアラームのカタログよりも柔軟であり、技術的な動作をビジネストランザクションに結び付けることができます。
柔軟性は責任をクエリ設計に移します。平均は、深刻な影響を受けた少数のユーザーグループを隠すことができます。パーセンタイルはトラフィックが少ないと不安定になる可能性があります。カウントは、サービスが改善したからではなく、需要がなくなったために低下する可能性があります。エラーをすべてのトランザクションで割ると、分母にヘルスチェックが含まれている場合、障害を過小評価する可能性があります。一時的なポッド識別子でファセット化すると、実際の運用単位がデプロイである場合に、短命なシグナルのストリームが作成される可能性があります。ダッシュボードからコピーされたフィルターは、新しく名前が変更された環境を省略する可能性があります。
NRQL アラートは、単に毎分実行されるチャートでもありません。New Relic のストリーミングアラートドキュメントでは、3 つの集計方法について説明しています。デフォルトのイベントフローは、頻繁でほぼ順序付けられたデータに適しています。イベントタイマーは、不規則にまたはバッチで到着するデータに適しています。ケイデンスは New Relic のウォールクロックを使用し、同社は古くて劣ったオプションと説明しています。データはフィルター処理され、集計ウィンドウに収集され、追加の遅延またはタイマーが許可され、値に折り畳まれ、その後しきい値の継続時間に対してテストされます。
すべての設定が検出器を変更します。ウィンドウが長いとスパイクが平滑化されますが、短く深刻な障害を隠す可能性があります。遅延が長いと、遅れて到着するテレメトリが到着する時間が与えられますが、ページまでの間隔が長くなります。イベントタイマーはバッチ内の静かな期間を待つことができますが、イベントフローは以前のウィンドウを閉じるためにより後のタイムスタンプを必要とします。一貫性のないデータに対してタイマーが短すぎる場合、New Relic は、すべてのポイントが到着する前にウィンドウが評価され、誤った通知が生成される可能性があると警告します。
空のウィンドウには別の決定が必要です。ギャップを空のままにすると、しきい値継続時間タイマーがリセットされる可能性があります。ゼロで埋めると、あるクエリにとっては欠落データが明らかな正常に、別のクエリにとっては明らかな災害に見える可能性があります。最後の値を繰り越すと、古い障害や古い成功が保持される可能性があります。信号喪失検出は役立ちますが、信号が存在していた後にのみアクティブになります。ソースがすでに存在しないときに有効にされた条件は、その不在を遡及して発見することはできません。ファセット化された条件では、各ファセットが独自の信号であり、一時的なエンティティが通常のスケーリングの一部として終了するまでは強力です。
クエリ言語には明示的な境界があります。LIMITは、結果セット全体が評価されるため、NRQL アラートと互換性がありません。サブクエリとサブクエリ結合は、複数のデータパスを必要とするため、ストリーミングアラートと互換性がありません。アカウントと条件の制限も重要です。現在のドキュメントでは、アカウントあたり 4,000 のアラート条件、NRQL 条件あたり 20,000 のファセット、毎分 3 億の一致データポイント、毎分 25 億のクエリスキャン操作がリストされています。スライディングウィンドウは一致ポイントを大幅に増加させる可能性があり、一部のコンピューティングプランでは消費料金が追加されます。
これらは多くの組織にとって寛大な上限ですが、設計上の意味合いはハードリミットよりも早く現れます。何千もの揮発性ディメンションにファセット化された条件は、意図的にスコープが絞られたサービスレベルアラートよりも、所有、テスト、ルーティングが困難です。したがって、クエリガバナンスでは、NRQL が式を受け入れるかどうかだけでなく、それがどの母集団を表すか、その分母がどのように動作するか、トラフィックがゼロの場合に何が起こるか、それが作成する個別の信号の数、およびそれぞれを所有するチームを尋ねる必要があります。
異常検出は履歴を学習し、その曖昧さを継承する
静的なしきい値は説明が簡単ですが、一般化が困難です。5 秒のレイテンシしきい値はチェックアウトでは許容できず、夜間のレポートでは正常な場合があります。正午のトラフィックは深夜のトラフィックとは異なります。New Relic の異常条件は、以前の動作から次の値を予測し、観測値が予測から十分に離れたままの場合にアラートを開くことでこれに対処します。感度は予測値からの距離で表され、方向と継続時間がどの偏差がカウントされるかを制御します。
異常検出のドキュメントは適切に限定されています。新しい信号は履歴が少なく、予測が不安定です。一貫した信号はより狭いバンドを生成し、不規則な信号はより広いバンドを生成します。システムは自動的に季節性を推測するか、時間単位、日単位、週単位、または季節性なしを使用できます。月単位および年単位のパターンはサポートされていません。したがって、週次の販売サイクルはモデル化できますが、年次の更新ピークや月末バッチには別の設計が必要です。
異常は有害な障害と同じではありません。成功したプロモーションは異常なトラフィックサージを引き起こす可能性があります。非効率なエンドポイントを一様に遅くするデプロイは、それが持続すると新しい常態になる可能性があります。少量のセキュリティまたは支払いエラーは、各発生が重要であっても、広いバンド内にとどまる可能性があります。逆に、季節性が間違っていると、予想されるバッチがページを発生させる可能性があります。モデルは学習された動作からの逸脱を検出します。学習された動作が許容可能かどうか、逸脱が中断を必要とするかどうかを決定するのは顧客です。
条件のメンテナンスは、特に重要な信頼性の境界を作り出します。New Relic は、クエリ、集計方法、ウィンドウ、遅延、ギャップフィリング、異常の方向、しきい値、またはスライディング間隔を変更すると、NRQL 条件の評価がリセットされると述べています。継続時間ベースのしきい値の場合、新しいイベントが開く前に少なくとも設定された待機期間が発生します。異常条件の場合、すべての異常学習が失われ、再び開始されます。したがって、リスクの高いリリースの前に行われた善意の編集は、自信が必要なときにブラインドまたは不安定な期間を作り出す可能性があります。
これにより、アラート設定は変更管理された資産となります。編集では、理由、以前の値、予想される効果、所有者を記録する必要があります。チームは履歴信号をプレビューし、可能であれば重要な期間外に変更を適用し、条件がアクティブになった後に既知の障害演習を実行する必要があります。異常アラートの場合、所有者は再学習間隔を信頼性が低下したものとして扱い、リスクが正当化される場合は静的または合成ガードと組み合わせ、モデルをリセットする繰り返しの表面上の編集を避ける必要があります。
New Relic は外れ値検出を追加しました。これは、1 つの信号をその過去と比較するのではなく、エンティティをピアと比較します。これにより、他の点では正常なグループ内で過負荷のサーバーを 1 台見つけることができます。その外れ値ガイダンスは、古いタイムスタンプを報告するエンティティが比較から完全に除外される可能性があるという貴重な警告も提供します。推奨される解決策である、レポート動作による条件の分割やウィンドウの延長は、カバレッジと遅延およびメンテナンスを再びトレードオフします。より高度な検出は、時間を理解する必要性を排除するものではありません。
テレメトリの欠落は、正常、故障、または単に遅延しているように見える可能性がある
テレメトリの喪失は、監視における最も危険な曖昧さの 1 つです。エラーイベントがないことは、何も失敗しなかった、リクエストが到着しなかった、プロセスがレポートを停止した、フィルターがレコードを除外した、または転送が失敗したことを意味する可能性があります。正しい対応は、どの不在が発生したかによって異なります。
New Relic はこのためにいくつかのツールを公開しています。信号喪失条件は、タイマー後にアラートイベントを開いたり閉じたりできます。ギャップフィリングは、静的な値または最後の既知の値を挿入できます。NrIntegrationErrorレコードは、不正なデータ、制限、設定の失敗を明らかにできます。アカウント制限インターフェースは、一部の取り込みおよびクエリインシデントを報告します。これらの制御により、チームは可観測性自体を監視できますが、それらには個別の条件と独立したルートが必要です。同じ失敗したテレメトリパスを使用する欠落アラートに関するアラートは、完全な保護策ではありません。
カーディナリティは問題を複雑にします。メトリック時系列は、その名前と一意の属性の組み合わせによって定義されます。顧客、リクエスト、コンテナ、または無制限の識別子の値を追加すると、系列の数が劇的に増加する可能性があります。New Relic は現在、アカウントあたり 1 日あたり 1,500 万のカーディナリティ予算と、メトリックあたりのデフォルトの 10 万の予算を説明しており、有料の拡張と剪定制御が提供されています。制限に達すると、動作は制限によって異なります。データ制限のドキュメントでは、一部のリクエストレート超過は 429 レスポンスを受け取り、メトリックカーディナリティ制限に達すると、生データは保存される可能性があるにもかかわらず、その日の UTC の残りの間、集計データがオフになる可能性があると述べられています。
カーディナリティは単なるコストの問題ではありません。それはアラートの母集団とクエリパフォーマンスを変えます。高チャーンフィールドでファセット化されたアラートは、何千もの短命な信号を作成し、アラート評価作業を増やし、ルーティングを無意味にします。フィールドを剪定するとコストを制御できますが、1 つのテナントを分離するために必要な次元が削除される可能性があります。適切な単位は通常、運用上所有されているサービス、リージョン、ワークロード、または顧客階層であり、最も簡単に付加できる識別子ではありません。
プラットフォームの 2026 年のステータス履歴は、このレイヤーが想定ではなく測定されなければならない理由を示しています。New Relic の公開インシデントフィードには、遅延または欠落したアラート通知、誤ったアラート、誤った信号喪失通知、テレメトリの不規則性に関するエピソードが記録されています。例えば、2026 年 3 月 20 日、同社は、Azure 統合を使用している一部の米国リージョンの顧客が、エラー、遅延または欠落した通知、および潜在的に回復不可能な影響を受けたデータを受け取った可能性があると述べました。5 月 18 日、サードパーティのクラウドプロバイダー障害により、一部の米国および EU の顧客でデータの遅延、遅延、欠落、または誤った通知が発生したと報告しました。1 月 21 日には、米国の一部の顧客でリアルタイム通知の遅延または欠落が発生する可能性がある 4 時間以上の時間が記録されました。
これらの開示は特定のインシデントの証拠であり、測定された障害率ではありません。フィードは、影響を受けたアカウント数、すべての低下した状態、または成功した評価の分母を開示していません。また、New Relic がサービスの問題を検出、伝達、解決していることも示しています。正しい運用上の結論はより狭いものです。可観測性プロバイダー自体が分散クラウド依存関係であり、深刻なリスクを抱える顧客は、その収集および通知パスに対する外部チェックを必要とします。
その外部チェックは、独立してルーティングされる軽量な合成モニター、最も重要なリソースに対するクラウドネイティブアラーム、New Relic の外部で観測される取り込みハートビート、または別のプロバイダーからのユーザージャーニー信号などです。すべてのアラートを複製すると、ノイズとコストが再現されます。少数の不可欠なパスを保護することで、プラットフォーム全体を再構築することなく有用な制御が作成されます。
相関はファンアウトを減らすが、共通の原因を証明することはできない
大規模なインシデントでは、ホスト、サービス、リージョン、症状ごとに 1 つのアラートが発生する可能性があります。各イベントを個別にページングすると、技術的な障害が注意の障害に変わります。New Relic のインシデントインテリジェンスは、アラートイベントを問題にグループ化し、時間、属性、テキストの類似性、エンティティの関係に基づいて、組み込み、提案、または顧客定義の相関決定を適用できます。アクティブ化する前に、最近のデータに対して提案された決定をシミュレートできます。
これは実際のニーズに対応しています。Google の SRE ガイダンスは、ノイズの多いアラートをインシデントと 1 対 1 の関係に近づけることを推奨し、繰り返される低優先度のページが深刻なアラートへの注意を低下させる可能性があると警告しています。Huawei Cloud の 400 万以上のアラートに関する 2 年間の産業研究でも、不明確な説明、誤解を招く重大度、時代遅れの戦略、トグリング、集合的ストームが同様に発見され、エンジニアはサービスやアラート戦略が変更された後もブロッキング、集計、相関を再設定する必要がありました。
New Relic の相関機構は、プラットフォームスケールでその集計を実行できます。ドキュメント化された決定には、同じ Kubernetes デプロイ、アプリケーション、または合成モニターからのイベントのグループ化、および類似性ベースのルールやトポロジー関係が含まれます。最大 20 分の猶予期間により、通知前にアクティビティを収集して相関させる時間がシステムに与えられます。利点は、断片化された作業項目が減り、1 つの問題ページでより多くのコンテキストが得られることです。
トレードオフは時間と過剰なグループ化の可能性です。時間とトポロジーが近い 2 つのアラートは、デプロイを共有している場合もあれば、独立した障害を表している場合もあります。類似のタイトルは、共通の原因ではなく、共通のテンプレートによって生成される場合があります。猶予期間が長いと、最初のページを遅らせながら、相関により多くの証拠が与えられます。ストームを抑制するのに十分広いルールは、2 番目の問題を、所有者がすでに誤った仮説を追求している問題にマージする可能性があります。
したがって、製品は相関率だけでなく、問題レベルでの適合率と再現率で評価されるべきです。適合率は、グループ化されたイベントが真に同じ運用上の問題に属する頻度を問います。再現率は、1 つの問題からのイベントがどれだけ正常にグループ化されたかを問います。高い相関率だけでは、積極的なグループ化によって作り出される可能性があります。顧客の成果は、グループ化が重複作業を減らしつつ、明確なアクションや所有者を隠さないかどうかです。
提案された決定とシミュレーションは役立ちますが、過去のデータを使用します。新しいアーキテクチャ、名前変更、まれな複合インシデントはその履歴の外にあります。インシデント後のレビューでは、グループ化されたイベントと除外されたイベントの両方を検査する必要があります。決定には、しきい値と同様に所有者と有効期限のレビューが必要です。
ルーティングは検出の信頼性の一部である
条件がアラートイベントを開き、相関が問題を形成すると、New Relic のワークフローは問題イベントをフィルタリングし、選択されたトリガーを宛先に送信します。通知を NRQL の結果で強化し、メール、Slack、PagerDuty、ServiceNow、Jira、webhook、その他の統合を対象にすることができます。タグはサービスをそのチームに誘導できます。通知トリガーは、アクティブ化、確認応答、調査、クローズ、優先度の変更、およびその後の更新で異なる場合があります。
これが強力なのは、所有権のない検出は単なる記録に過ぎないからです。それはまた、別の設定面でもあります。ポリシーやタグが変更された後、ワークフローフィルターが一致しなくなる可能性があります。宛先の認証情報が期限切れになる可能性があります。メール受信者がアドレスを確認しない可能性があります。webhook ペイロードが変更される可能性があります。強化クエリが空のデータを返す可能性があります。New Relic のワークフローテストは既存の一致する問題を使用するため、関連する履歴のない設定では、将来のルートが機能するかどうかを証明することなく、一致が見つからなかったと表示される可能性があります。
ミュートルールは、メンテナンスや既知の中断に関する必要な制御を追加します。それらはアラートライフサイクルの終わり近くに適用されます。評価は継続され、アラートイベントは依然として存在しますが、通知は抑制される可能性があります。ミュートのドキュメントでは、ミュート終了後にアクティブな問題が残っている場合の通知と、その後の通知を抑制することを区別しています。間違ったタイムゾーン、フィルター、または終了動作による繰り返しのミュートは、設定上は意図的に見えるが運用上は有害な無音状態を作り出す可能性があります。
チームは条件だけでなく、ルートをテストする必要があります。安全な環境での合成ブリーチは、条件の開始、問題のグループ化、ワークフローの一致、宛先への配信、オンコールの確認応答、クローズを検証する必要があります。重要なルートは定期的なチェックが必要です。なぜなら、最近のページがないことは健全なパスを証明しないからです。チェックでは、New Relic の評価タイムスタンプだけでなく、エンドツーエンドの時間を記録する必要があります。同社のドキュメントでは、表示されるアラートイベント時間と最初の通知時間は、顧客が設定したウィンドウ、遅延、猶予期間、外部配信が追加される前に、データ処理のために最大 3 分異なる可能性があると述べています。
顧客の成果は有望だが、選ばれたものである
New Relic は、アラートの負担を軽減したチームの詳細な名前付きの例を公開しています。PicPay の顧客アカウントでは、アラート基準を設定し、ログを一元化した後、インシデント量を 65%、平均解決時間を 30%、年間ダウンタイムを 51% 削減したと述べています。Viewpointは、毎週のアラートノイズを 3,500 以上から 600 未満に減らし、以前の監視ソリューションと比較して 57% 節約したと述べています。The Access Groupは、アラートノイズを 99% 削減して 1 日あたり約 9 件のアラートにし、チューニングと統合後、調査に約 10 分かかると説明しています。
これらのアカウントは重要です。顧客、ワークロード、前後の数値、実務者を特定しています。New Relic が大規模な本番運用に組み込まれ、アラートの合理化が大きな利益を生み出すことができることを示しています。また、結果が異常モデルによってフリップされたスイッチではなかったことも示しています。PicPay はプラットフォームのアラート基準を設定し、ログを一元化しました。Viewpoint は Kubernetes アプリケーションを計装し、機能全体にアクセスを広げました。The Access Group はアラートを微調整し、ミュートを使用し、ビジネス計装を追加しました。組織的な作業は結果の一部です。
証拠はベンダーが選択したものであり、重要な分母が欠けています。ページには、契約価格、エンジニアリング実装時間、一致した対照群、信頼区間、逃れたインシデント、偽陰性の数、統合やプロセス再設計ではなく New Relic によって引き起こされた改善の割合は示されていません。「アラートノイズ」も顧客によって異なる定義をされる場合があります。3,500 件から 600 件の通知への減少は素晴らしいことですが、顧客が検出した障害も減少したかどうかを知らなければ不完全です。
New Relic の2026 AI インパクトレポートは、はるかに大規模な観測的視点を提供します。分析は、2025 年中の約 660 万人のアクティブユーザーの集計された匿名化された使用状況をカバーしていると述べています。AI 対応アカウントではノイズアラートが約 46% であるのに対し、非対応アカウントでは 63%、問題相関率は約 2 倍、平均クローズ時間は約 25% 短くなっています。5 月の報告された平均はそれぞれ 26.75 分と 50.23 分でした。
規模が大きいため、関連性は興味深いものですが、因果関係ではありません。レポートは、「New Relic AI」の下に生成、機械学習、決定論的機能をグループ化しています。ランダム割り当て、各コホートのアカウント数、マッチング方法、サービスの複雑さ、チームの成熟度、重大度の混合、クローズの慣例、偽陰性の結果は公開されていません。高度な機能を有効にするチームは、計装とインシデントプラクティスにもより多くの投資をする可能性があります。平均クローズ時間は必ずしも回復時間ではありません。問題は、ユーザーが回復したことを証明することなく、自動的、手動、またはポリシーによって閉じることができます。
適切な解釈は、統合された相関と支援が運用努力の低下に寄与するもっともらしい要因であり、New Relic は自身のエステートで持続的な関連性を確認しているということです。購入者は、25% を保証された節約として投資収益率モデルに入れるべきではありません。信号の開始、イベントの開始、通知の配信、確認応答、調査の開始、緩和、サービスの回復、問題のクローズという同じ段階をローカルで測定する必要があります。そうして初めて、New Relic がどの時間を削除したかを判断できます。
実用的なアラートあたりのコストが、作業がどこに移動したかを明らかにする
New Relic の商用モデルでは、テレメトリの量とユーザーアクセスが可視化されています。現在の公開リスト条件には、月間 100 GB の無料取り込みが含まれ、その後、ユーザー料金と高度なコンピューティング料金に加えて、オリジナルデータが 1 GB あたり $0.40、Data Plus が 1 GB あたり $0.60 と記載されています。公開価格は変更される可能性があり、エンタープライズ契約は異なるため、これらの数値は見積もりではなく参照ポイントです。Data Plus は保持期間とクエリ制限も変更するため、コストは調査で調査できる履歴の量に結びついています。
直接の請求書はアラート経済の一部にすぎません。有用な月次方程式は次のとおりです。
実用的なアラートあたりのコスト = (プラットフォーム + 取り込み + 保持 + コンピューティング + 計装 + 収集運用 + クエリガバナンス + アラートチューニング + ルーティングメンテナンス + トリアージ + インシデントレビュー + トレーニング + 移行償却) / 実用的なアラート
この分母には、運用上の受け入れルールを満たしたアラートのみを含める必要があります。誤ったチームに届いたページは、そのルートでは実用的ではありません。ユーザーがすでに停止を報告した後に到着した正しいアラートは、検出を改善しませんでしたが、診断には役立つ可能性があります。重複したページは価値の別の単位ではありません。レビュー前に自動的にクローズされたイベントは有用な証拠である可能性がありますが、チームが抑制が安全であったことを確認しない限り、回避された人間のアクションとしてカウントすべきではありません。
見逃された障害は分母に項目を生成しないため、コンパニオンメトリックが必要です。New Relic、別のモニター、従業員、顧客によって最初に検出された顧客に影響を与えるインシデントを追跡します。有用な New Relic 通知を生成しなかったカバーされたインシデントを追跡します。次に、コストとともにアラートの精度、実用的なカバレッジ、最初の検出者のシェアを計算します。高額なインシデントを見逃す安価なアラートシステムは安価ではありません。
分子は金銭とエンジニア時間の両方で測定する必要があります。計装には、サービスとビジネス属性の追加、アップグレードのテスト、コレクターのメンテナンスが含まれます。収集運用には、キュー、再試行、カーディナリティ制御が含まれます。クエリガバナンスには、レビュー、バージョン管理、所有権が含まれます。チューニングには、感度、ウィンドウ、季節性、ギャップ処理、ミュートが含まれます。トリアージには、最終的な解決者だけでなく、通知を見たすべての受信者が含まれます。インシデントレビューには、サービス修復後のアラートの修復が含まれます。
取り込み価格は重要なインセンティブを生み出します。より多くのテレメトリは診断とカバレッジを向上させる可能性がありますが、その多くは有用な決定に寄与しない可能性があります。積極的なドロップやサンプリングはお金を節約しますが、インシデントを説明するまれなトレースを削除する可能性があります。経済的な目標は最小 GB ではありません。合意されたリスクに対して検出と診断を維持する最も安価な証拠セットです。それは一般的に、高品質なサービスレベルおよびビジネスシグナル、調査のための選択的な詳細、およびすべてを無期限に収集するのではなく、ユースケースごとの明示的な保持を意味します。
シートとアクセスも労働を形成します。開発者に直接のコンテキストを与えることでハンドオフをなくすことができますが、高価なフルアクセスは調査を小さなプラットフォームチームに集中させる可能性があります。購入者は、各ロールが実際に必要とする機能、基本アクセスで十分かどうか、ページ受信者が異なるライセンスやアカウント権限を持つ誰かを待たずにリンクされた証拠を検査できるかどうかをマッピングする必要があります。
OpenTelemetry が移植性を向上させても、移行コストは計算に含まれます。オープン API に対して記述された計装は別のバックエンドにデータを送信できますが、NRQL 条件、ダッシュボード、問題の決定、ミュートルール、ワークフローフィルター、履歴ベースライン、調査習慣は New Relic 固有の資産です。エクスポートされたテレメトリは、それらに埋め込まれた運用上の意味を自動的に変換しません。将来の出口では、並行実行、ルール変換、再トレーニング、および代替品が同じ障害を検出することの証明が必要です。
真剣な評価は通常の障害を使用し、すべての試行を保持する
デモンストレーションが受け入れテストであってはなりません。評価は、オンコール時間を消費する見栄えのしないケースを含め、繰り返される通常のサービスとデプロイをカバーする必要があります。代表的なサービスセットを選択します。安定した高トラフィック、低トラフィック、スケジュールされたバッチ作業、オートスケーリングされたサービス、クラウドポーリングされたメトリック、1 つの OpenTelemetry サービス、1 つのネイティブエージェントサービスです。アラートを設定する前に、ビジネス症状と予想される所有者を定義します。
ステージングまたは制御された本番演習で、承認された可逆的な障害のみを注入します。例には、既知のエラー率の増加、テスト依存関係に追加されたレイテンシ、停止したテレメトリエクスポーター、遅延したバッチ、サービス名を変更するデプロイ、期限切れのテスト webhook、予想されるオートスケーリングの終了が含まれます。トラフィックプロモーションや計画されたメンテナンスなどの正常だが異常なイベントを含めます。目的は検出を最大化することではなく、有害な変更と無害な変更を区別することです。
イベントを生成しないものも含め、スケジュールされたすべてのケースを記録します。各繰り返しについて、テレメトリ放出時間、クエリ可能時間、アラートイベント時間、問題時間、通知配信、確認応答、正しい所有者への到着、診断、緩和、サービス回復をキャプチャします。結果を、真に実用的、真だが遅延、重複、所有者間違い、非実用的、偽陽性、見逃し、未解決に分類します。最初の試行を保持します。条件が編集されて再テストされたために見逃した通知を合格に変えてはなりません。
定期的な変更を越えるのに十分な繰り返しを実行します。エージェントのアップグレード、デプロイ、トラフィックサイクルの境界、週末、コレクターの再起動、条件の編集です。異常条件は学習に時間が必要なため、テストではコールド期間と成熟期間を比較する必要があります。テレメトリが遅延し、部分的に欠落している場合を繰り返します。相関については、いくつかの症状を伴う 1 つの障害と、2 つの同時の無関係な障害を作成します。グループ化と有害なマージの両方を測定します。ルーティングについては、確認応答とクローズの更新、および最初のアクティブ化をテストします。
実際の代替品と比較します。それは、以前のプラットフォーム、クラウドネイティブアラーム、Prometheus と Alertmanager のルート、または手動のダッシュボードプロセスです。サービスと障害を一定に保ちます。エンドツーエンドの検出、有用なコンテキスト、エンジニア時間、見逃したケース、月額コストを比較します。洗練された問題ページは、それらの結果のいずれかを改善する場合にのみ価値があります。
運用ダッシュボードは調達後も継続する必要があります。有用な指標には、実用的なアラート率、カバーされたインシデントの再現率、顧客最初の検出率、インシデントあたりの重複通知、所有者間違い率、中央値およびテール通知時間、診断までのエンジニア時間の中央値、所有者またはランブックのないアラート、6 か月間レビューされていない条件、最近リセットされた異常条件、テレメトリエラー率、カーディナリティ制限イベント、サービスごとの実用的なアラートあたりのコストが含まれます。単一のグローバルスコアは、修復が必要なサービスを隠します。
代替手段は、New Relic が何に対して支払われているのかを明確にする
New Relic は、Datadog、Dynatrace、Splunk Observability、Elastic などの統合商用プラットフォーム、およびクラウドネイティブサービスやオープンソースコンポーネントと競合します。関連する比較は機能の一覧ではありません。誰がデータストア、統合、アップグレード、スケーリング、クエリシステム、アラート評価、相関、サポートを運用するのか、そしてエンジニアにどれだけのコンテキストが届くのかです。
Prometheus はアラート評価をAlertmanagerから分離し、Alertmanager はアラートのグループ化、ルーティング、抑制、サイレンスを行います。Grafana はデータソース全体でダッシュボードとアラートを提供できます。Loki と Tempo はログとトレースをカバーします。OpenTelemetry は収集を標準化できます。このスタックは効果的で、透過的で、移植性があります。また、管理プロバイダーが引き受けない限り、容量、高可用性、保持、アップグレード、クロスシグナル相関、コンポーネント間のインターフェースに対する責任を顧客に残します。
クラウドネイティブアラームは、AWS、Azure、Google Cloud に集中したワークロードではよりシンプルです。別のエージェントなしでプラットフォームメトリクスを確認でき、独立したフォールバックを提供します。複数のクラウド、アプリケーション、ビジネスイベントにまたがると一貫性が低下します。専門のエラートラッカーは、開発者の例外ワークフローにおいて、インフラストラクチャやサービスレベルの証拠を他に残しながら、幅広いプラットフォームよりも優れている場合があります。
合理的なアーキテクチャはハイブリッドにすることができます。幅広いアプリケーションとクロススタック分析には New Relic を使用し、移植性と制御が重要な場合は OpenTelemetry を使用し、いくつかの重要なパスには独立したアラームを使用します。ビジネスレベルの合成チェックを内部の症状アラートから分離します。大量の詳細をすべてエクスポートしても増分価値がほとんどない場合は、ローカルまたはクラウドネイティブのメトリクスを使用します。目的はツールの純粋性ではなく、理解可能な所有権とコストを伴う信頼性の高い検出です。
New Relic が最も魅力的なのは、チームに十分な異種サービスがあり、1 つのホストされたデータおよびクエリレイヤーが実際の統合作業を削減するが、可観測性の規律があまりにも少なすぎてプラットフォームが所有されていない信号の倉庫になるわけではない場合です。小規模なエステートがネイティブクラウドアラームで十分に機能する場合、データエグレスやレジデンシの制約が支配的な場合、チームが計装の所有権に資金を提供できない場合、または既存のオープンソース運用が持続可能なコストで信頼できる結果をすでに提供している場合には、魅力が低下します。
判断を変える可能性のある証拠
最も不足している証拠は、繰り返され開示されたタスクに対する条件レベルの信頼性です。New Relic は、コールドスタート期間、遅延データ、欠落データ、季節性の変更、編集を含む、バージョン管理されたデータセット全体での静的、異常、外れ値条件の適合率、再現率、検出時間分布を公開することで、ケースを実質的に強化できます。相関結果は、相関されたイベントの割合だけでなく、有害なマージと見逃されたグループを報告する必要があります。
顧客の証拠は、前後の条件数、インシデントの分母、顧客最初の検出、エンジニアリング時間、契約と取り込みの範囲、実装期間、偽陰性、ノイズの定義があれば、より移転可能になります。ページの減少は、有害なインシデントのカバレッジが安定しているか改善している場合に説得力があります。その指標がなければ、無音は効率か盲目のどちらかです。
プラットフォームの信頼性レポートは、影響を受けたアカウントの割合や、取り込み、評価、通知のコンポーネント固有の成功率から恩恵を受けるでしょう。公開ステータスフィードは有用ですが、アラート配信率を生み出すことはできません。購入者は、自身の履歴サービスレポート、サポート対応コミットメント、注文書の正確な可用性の定義を要求する必要があります。
New Relic AI については、管理されたまたは注意深くマッチングされたコホート作業が、製品効果を顧客の成熟度から分離するのに役立ちます。アカウント数、採用基準、重大度とアーキテクチャの制御、クローズメカニズム、信頼区間を公開します。平均クローズ時間を独立したサービス回復タイムスタンプとリンクさせます。提案された根本原因やクエリが受け入れられ、修正され、無視された頻度を開示します。これらの指標は、広範な関連性を、チームがキャパシティプランニングに使用できる証拠に変えるでしょう。
そのような証拠が、高い実用的なカバレッジ、低い有害相関率、計装とチューニングの労力を含めた後のエンジニア時間の持続的な削減を示した場合、判断はより肯定的になるでしょう。利益が大規模な専門家チームに依存している場合、異常の再学習が意味のあるブラインド期間を生み出した場合、ルート障害が一般的であった場合、またはコスト管理が診断に必要な証拠を繰り返し削除した場合、判断はより否定的になるでしょう。
評決：検出システムを購入し、その世話人の予算を組む
New Relic は、技術的に充実した可観測性プラットフォームを提供します。共有データレイヤー、表現力豊かな NRQL、広範な計装、ストリーミング評価、異常検出、インシデント相関、ワークフローは、手動監視や断片化されたツール検索を置き換えることができます。名前の挙がった顧客は、ノイズと解決時間の大幅な削減を報告しています。OpenTelemetry のサポートは、ロックインの重要な原因の 1 つを減らし、ドキュメントは遅延データ、リセット、制限、欠落信号について異常に率直です。
プラットフォームは、ビジネスが何を有害と見なすかを決定したり、顧客の計装がそれを表現することを保証したり、サービスが変化してもすべてのクエリとルートを正しく維持したりすることはできません。より高度なモデルは、テレメトリと注意の間の機構を改善します。機構を監督する必要性を取り除くわけではありません。繰り返し発生する人間の作業は、ダッシュボードを見つめることから、信号の設計、クエリの管理、例外のレビュー、ルートのテスト、インシデント後の条件の修復に移行します。
それは優れたトレードオフになり得ます。数時間の規律あるアラートエンジニアリングは、何時間もの重複したトリアージを節約し、顧客への害を減らすことができます。チームが取り込まれたデータと通知数のみを測定し、所有者なしで条件を蓄積させたり、アラート量の低下をより高い信頼性の証明として扱ったりすると、それは悪いトレードオフになる可能性もあります。
したがって、New Relic は神託としてではなく、検出システムとして購入および運用されるべきです。発せられた証拠から正当化されたアクションまでの完全なパスを測定します。見逃された障害を見えるようにしておきます。計装とチューニングを、それらに依存するアラートに課します。最も重要なパスを独立したチェックで保護します。決定的な数字は、NRDB が保持できる信号の数やアルゴリズムがグループ化できるイベントの数ではありません。システムが、適切な人物に、十分に早く、問題になる前に、真実を伝え、それが防止する障害と労働よりも低い総コストで、どれだけの頻度で行うかです。