New Relic LLM 可観測性：各呼び出しに対して1つのルートが割り当てられていることを証明する

New Relic LLM の可観測性機能では、モデルのレイテンシ、トークン数、エラー、トレース、および AI レスポンスデータを表示できます。ただし、この機能だけでは、2 つのコレクターが同じモデル呼び出しをカウントしたかどうか、あるいはエージェントが要求された外部結果を生成したかどうかをオペレーターに判断させることはできません。実務上のデフォルトとしては、 各モデル呼び出し境界ごとに1つの計測責任者を指定 し、すべてのレコードを内容のない呼び出しIDに関連付け、成果物については別途記録を残すことが一般的です。 そのルールが重要なのは、New Relicがいくつかの正当なパスを記載しているからです。そのネイティブ AIによる監視 APMエージェントを使用します。New Relicについても記載されています。OpenLIT 対 OTLP トレースやメトリクス、および OpenLLMetry 対 OTLP トレース用。LiteLLMには別の New Relicの統合 そのコールバックと、New RelicおよびPythonエージェントを中心に構築されています。 これらの方法はあくまで選択肢であり、すべてのシステムが同じ境界を実装すべきだという証拠ではありません。所有権の設定が間違っていたり、証拠が古かったり、必須フィールドが欠けていたり、完了したモデル呼び出しに検証済みの結果がなかったりする場合でも、ダッシュボードにデータが表示されることはあり得ます。 海図を信頼する前に、航路を確定しておくこと クエリではなく、デプロイメントマニフェストから始めましょう。そこには、サービス、監視対象となる境界、その境界について報告を許可された唯一のオーナー、そのオーナーが発信できるシグナルの種類、相関フィールド、および最新性の有効期限を明記する必要があります。 所有者 と シグナル種別 を区別することで、単純な重複排除のミスを防ぐことができます。1つの宣言されたオーナーは、同じコールに対して意図的にAPMスパンとAIメッセージイベントを送信することがあります。これらのレコードは、同じコールIDを共有し、デプロイメント契約で両方が期待されている場合、互いに補完的な関係にあります。同じ境界に対するOpenLITレコードとOpenLLMetryレコードは、たとえフィールドが似ていても、2つの異なるオーナーによるものです。 マニフェストは、計測機能を有効にしたデプロイメントによって生成される必要があります。UI にたまたま表示されているエンティティから推測してはいけません。セットアップパスによって、識別方法は異なります： New Relic AIモニタリングは、APMエージェントと、対応するライブラリまたはフレームワークから始まります。 OpenLITは、New RelicのOTLPエンドポイントにトレースとメトリクスを送信します。 OpenLLMetryはそのエンドポイントにトレースを送信し、New RelicはOpenTelemetryの service.name リソース属性からサービスエンティティを導出します。 LiteLLM は newrelic のコールバックを有効にし、APM のテレメトリには New Relic および Python エージェントを使用します。そのドキュメントによると、このコールバックは初期化メッセージをログに記録し、トレースの詳細が表示されるまで 2～3 分かかる場合があります。 これだけで、明示的なルートレコードが必要となる。これは、特定のペアが常に呼び出しを重複させるという証拠ではない。安全な運用上の主張は、それよりも限定的なものである。すなわち、マニフェストで1つしか許可されていない境界に対して2つの所有者が確認された場合、デプロイメントの整合性が取られるまでは、合計値および健全性判定は曖昧なままである。 プロンプトハッシュではなく、不透明なコール識別子を使用してください。実用的なオブザーベーションエンベロープは、内容を空のままにしておくことができます： 所有権、最新性、トークンフィールドの存在、または送信先の検証については、プロンプトや応答の内容は不要です。LiteLLM は、New Relic 固有の turn off message logging 設定と、AI モニタリングによるコンテンツ記録を無効にする環境スイッチの両方を記述しています。コンテンツの保存については、プライバシーに関する別の判断として扱ってください。所有権監査を機能させるためだけに、この機能を有効にしないでください。 緑色のビューが隠している8つの状態を再生する 付属の監査では、8つの合成コールが使用されています。この監査では、以下の優先順位が適用されます： 1. 観測なし； 2. 所有者の不在が予想される； 3. 複数の所有者； 4. 予期しないシグナルの種類、または必須フィールドの欠落； 5. 古くなった証拠； 6. 正当な待機； 7. 結果通知書なしでの完了； 8. 完了と結果の受領。 優先順位は重要です。正しい所有者による古いレコードは健全ではありません。間違った所有者による新しいレコードも同様に健全ではありません。「待機」は、所有権、形状、鮮度がすべて条件を満たした後にのみ評価されるため、承認の保留によって、破損したコレクションを隠蔽することはできません。 この完全なフィクスチャには、プロンプトも応答も含まれていません。これを実行すると、8種類の異なる判定結果が得られます： この分類器は意図的に小型に設計されています： 「正常ではない」という判定が出るたびに、それぞれ異なる修復作業が必要となります： 結論 その内容 制限付き次のアクション NO TELEMETRY 予定されていた通話に関する記録は見つかりませんでした 計測機能の初期化、エクスポーターへの接続状況、およびクエリウィンドウを確認してください ROUTE DRIFT データは届いたが、申告された所有者からのものではなかった デプロイメントマニフェストと実行中のプロセスを比較し、意図しないパスを無効にしてください MULTIPLE OWNERS 複数の計測機器の所有者が、その境界を観察した。 合計値からその呼び出しを分離し、所有者を1つ選択するか、時間制限付きの移行例外を記録する SCHEMA GAP 所有権については正しいが、証拠は利用できないか、不完全である アラートを発する前に、フィールドのマッピングまたはシグナル・カインドの契約を修正してください STALE 最新の証拠は、許容される年代を上回っている エクスポーターの遅延、キューイング、クロックの同期、およびクエリ時間を確認する WAITING コレクションの状態は良好であり、指定された依存関係は維持されています 所有者に通知するか、記録された期限まで待つこと。エージェントを再起動してはならない。 OUTCOME UNVERIFIED モデル呼び出しは、要求された効果の証明なしに完了しました 決定論的な宛先チェックを実行する HEALTHY 所有権、証拠、作業状況、および結果はすべて一致している 領収書を保管し、通常の安定性期間を適用してください MULTIPLE OWNERS は、レコードを自動的に削除または統合してはなりません。計画的な移行の際には、デュアル収集が有用な場合があります。開始時刻、終了時刻、所有者、および照合ルールを明示して、この例外を明確に定義してください。2つの経路を比較するまでは、移行に関する観測値を本番環境のコストおよび信頼性の分母から除外してください。そうしないと、一見トークン数の急増に見えても、実際には動作の変化ではなく、計測方法の変更によるものかもしれないからです。 このフィクスチャは、一般的な「赤状態」がなぜ脆弱なのかも示しています。 ROUTE DRIFT はデプロイメントの問題であり、 STALE はデータ取り込みまたはクエリウィンドウの問題である可能性があります。 WAITING は障害ではなく、 OUTCOME UNVERIFIED については、別のトレースクエリを実行するのではなく、宛先の確認が必要です。 アウトカム受領書にオブザーバビリティを関連付ける New RelicのAIモニタリングに関するドキュメントには、パフォーマンス、コスト、トークン、応答、トレース、およびユーザーフィードバックに関する情報が記載されています。これらは、AIレイヤーに関する有用な指標となります。モデルの応答の後でも、ツールの呼び出しが失敗したり、ファイルがコミットされなかったり、メールが送信されなかったり、ジョブが承認待ちになったりすることがあり得ます。 そのため、宛先レシートはモデルコールテレメトリの外に保持してください： 宛先と検証方法は、作業内容によって異なります。ファイルのアップロードにはオブジェクトのバージョン、コードの変更にはコミットハッシュとチェック、配信にはプロバイダーのメッセージID、設定の変更にはAPIによる読み取り結果を使用します。約束された結果が別の場所に存在する場合、コマンドの終了コードは信頼性が低くなります。 リプレイにおいて、 false complete と healthy は、New Relic側の信号の種類、所有者、フィールド、および鮮度において同一である。異なるのは宛先のレシートのみである。これが操作上の境界となる。すなわち、LLMの観測可能性がモデル呼び出しの証拠を説明し、レシートがエージェントの意図した結果が存在することを証明する。 実用的な導入規模は小さい： 1. 実際のモデル・コール境界を1つ選択してください。 2. その展開において、想定される計測機器の所有者と許可される信号の種類を記録してください。 3. 1つの合成コールIDを生成し、それに関連するすべてのNew Relicイベントタイプを照会します。 4. 想定された所有者が不在の場合、または宣言されていない所有者が現れた場合は、ロールアウトを失敗とする。 5. 必須項目と、範囲が指定された有効期間を確認してください。 6. レコード「 working 」（名前付き待機依存関係）または「 complete 」を個別に記録してください。 7. complete を「正常」状態に移行する前に、確定的な宛先受領を必須とする。 8. SDK、コールバック、エクスポーター、またはエージェントのアップグレード後に、この手順を繰り返してください。 この手順には制限があります。すなわち、New Relicがサポートするすべての統合において、あらゆるフレームワークの組み合わせでダブルインストルメンテーションが行われることを証明するものではありません。これは、 実際に確認されたデプロイメント が、宣言された所有権契約と一致しているかどうかを証明するものです。また、New Relicの互換性チェックや、OpenTelemetryスキーマへの完全な適合性テストに代わるものでもありません。 Sidewispの意図する役割は、この区別に隣接するものです。すなわち、到達可能性、有意義な進捗、ツール、成果、時間、および予算に関する証拠を統合し、エージェントの健全性を示すビューとしてまとめることです。Sidewisp は現在プライベートプレビュー段階です。 現在公開されている製品は、早期アクセス版のウェブサイトおよびデモであり、本番環境向けのNew Relicアダプター、監視エンジン、および自動復旧実行機能は提供されていません。Sidewispが現在、これらのデータを収集または修正していると想定するのではなく、上記の監査を現在のテレメトリおよび宛先システムと組み合わせて使用してください。 この解決策は、実施する上で十分に単純です。モデル呼び出しの境界ごとに1つの宣言済み計測所有者を設定し、マニフェストで許可されている場合にのみ複数のシグナル種別を許可し、コンテンツを含まない新しい証拠、明示的な待機状態、そして独立した結果受領を定めます。エージェントの操作において、緑色のNew Relicビューが信頼できるものとなるのは、これらの境界が一致して初めてです。