Phoenix LLM 可観測性:痕跡が再始動で生き残ることを証明

フェニックスは、自身の証拠層がまだ脆弱な状態で完全な痕跡を示すことができます。アクセス可能なページがあれば、ウェブプロセスが今や答えを出していることが証明されています。そうです そんなことはない 古い痕跡が再起動を経ても生き残ったこと、収集業者が取り込みを再開したこと、または効果的な保持ポリシーがチームがインシデント調査期間をカバーしていることを証明してください。 合理的なデフォルトは、2回のカナリア再起動ドリルです: 1. 再開前に作成されたコンテンツのないトレースを1つ問い合わせます。 2. アプリケーションコードを変更しずにフェニックスサービスを再起動すること; 3. 同じトレースをもう一度問い合わせる; 4. 再起動後に2回目のトレースを発し、クエリを行います。 5. 観察年齢と有効保持率を明示的な制限と比較してください。 古いカナリアは持続力を試します。新しいカナリア検査が再開されました。両方必要です。古いトレースだけが存在する場合は、収集が壊れている間は保存で問題ないかもしれません。もし新しいトレースだけが存在するなら、サーバーは空か予期しないストレージで戻ってきたことになります。 フェニックスを三つの証拠層として扱いましょう フェニックスのアーキテクチャドキュメントシステムをウェブインターフェース、トレースコレクタ、SQLデータベースのバックエンドに分離します。その区別は診断時に重要です: インターフェースはOTLPの取り込みが失敗しても応答できます。 コレクタは接続を受け入れることができ、トレースは問い合わせ可能にならなくなります。 コンテナが新しいSQLiteワーキングディレクトリを指している間、データベースにアクセス可能であることもあります。 3つすべてが稼働している一方で、リテンションジョブはインシデントプロセスの予想よりも早く証拠を除去します。 フェニックスはSQLiteとPostgreSQLをサポートしています。現在のドキュメントでは、SQLiteはローカル開発およびシングルユーザー展開のために位置づけられており、データは以下の通りです ~/.phoenix/ または PHOENIX WORKING DIR .PostgreSQLは、マルチユーザーおよび高可用性展開における文書化された本番環境の選択肢です。これはSQLiteが常に不健康であるというルールではありません。単一の開発者がマウントされたボリュームを持つ信頼性の高いローカルインスタンスを実行できます。失敗は、粘り強さを暗黙のままにしておくことです。 その公式Dockerガイド2つの契約を直接示す: PostgreSQLの場合、Phoenixは PHOENIX SQL DATABASE URL ;ガイドはPostgreSQL 14以降のものを扱っています。接続値は健康証明書ではなく秘密のシステムに保管してください。レシートにはバックエンドクラス、不透明なデプロイ識別子、そしてカナリアクエリの結果のみが必要です。 画像のピン留めは別のコントロールです。 latest 使い捨てのローカルトライアルには便利かもしれませんが、リスタートをアプリケーションとデータベースの期待値の両方を同時に変更できるようにします。ドリル前に、不変画像ダイジェストまたは明示的なバージョンを録音してください。未知の画像に対して成功した再スタートは再現可能な証拠にはなりません。 内容のないリスタートレシートを1つ作成する エージェントトラフィックと同じコレクターおよびプロジェクトルーティングを行うカナリアパスを選びましょう。実際のプロンプト、モデルレスポンス、ツールの引数、認証情報、顧客識別子などをカナリアに入れないでください。ランダムなランラベルとタイムスタンプで十分です。 Phoenixのドキュメント化されたRESTエンドポイントはプロジェクトのためのリストトレース開始時間の制限と任意のスパンがあります。デプロイメントの認証方法を使い、承認値はシェル履歴や保存された出力には含まないようにしてください。 例えば、非秘密のルーティング値を設定し、狭い時間帯を要求します: ローカルでカナリアの不透明度を検索できます trace id ;応答体を一般テレメトリとしてエクスポートしないでください。もしあなたが望むなら include spans=true 応答サイズとクエリ遅延が増加するため、Phoenix APIリファレンスではスパンの詳細を怠慢に取得することを推奨しています。再起動ドリルは、プロンプトの内容ではなく、traceの識別と時間を必要とします。 最小限の領収書は次のようなものがあります。 effectiveRetentionDays これは単なるデプロイメントのデフォルトではなく、実際のプロジェクトに付随するポリシーを指します。フェニックスデフォルトでデータを無期限に保持しますはデフォルトポリシーでゼロ日として表されます。管理者は個々のプロジェクトに時間またはトレースカウントに基づくポリシーを割り当てることができます。デプロイ時のデフォルトは、既存のプロジェクト固有のオーバーライドを変更することなく新しいプロジェクトを更新できます。だからこそ、設定意図と効果的なプロジェクト状態は異なる証拠です。 リテンションとあなたの運営プロセスを比較してください。もしインシデントが14日間気づかれずに放置できるなら、現在のすべての痕跡が存在しても7日間のトレースウィンドウは劣化します。30日間も本質的に健康的ではありません。健全なのは、レビューウィンドウ、ストレージ予算、データガバナンスの決定に関してのみです。 中断を隠さずにドリルを進めてください ランタイムの通常の再起動操作を使いましょう。最初のドリルをPhoenixアップグレード、ストレージ移行、コレクタ再構成、アプリケーションリリースと組み合わせてはいけません。目的は持続と再摂取を隔離することです。 再起動直前: 1. 固定されたバージョンや画像ダイジェストを録画し、 2. 意図されたデータベースバックエンドと耐久ボリュームまたはデータベースの識別を確認し、 3. 効果的なプロジェクト保持方針を記録すること; 4. 通常の計測経路を通じて最初のカナリアを放出します。 5. クエリを行い、ブール値の結果、trace ID、タイムスタンプのみを保存します。 再起動後: 1. 任意のスリープを使うのではなく、サービスの文書化された準備動作を待ちます。 2. 同じ再起動前のトレースを照会します。 3. 再起動後に別のカナリアを放つ; 4. 同じプロジェクトルートで新しいトレースを照会します。 5. レシートにスタンプを押して、鮮度の期限が切れる前に評価してください。 この記事の補完試合は5分間の観測制限を適用し、9つの州をリプレイします。 その結果は次の通りです 9/9 cases pass .健全な構成として分類されるのは2つで、マルチユーザー展開用のピン留めPostgreSQLと、1ユーザー用の持続ボリューム付きのピン留めSQLiteです。残りの備品は意図的に生産しています evidence lost , ingestion failed , waiting , needs human , uncertain 、または degraded . 判決の優先順位が重要です: 証拠 結論 オペレーターの判断 移行は予定通り進めています waiting 有界保守操作を観察してください;エージェントの失敗とは呼ばないでください 移住は失敗に終わった needs human 自動回復を停止し、データベースとバージョンの境界を確認しましょう 観察は新鮮度の限界よりも古い uncertain 行動する前にクエリを再度実行してください ポリシー内の古い痕跡が消えた evidence lost まず現在のストレージを保持し、マウントやデータベースの識別を診断してください 古い痕跡は残りますが、新しい痕跡は欠けています ingestion failed コレクタの到達可能性、エクスポーターパス、認証、プロジェクトルーティングの検査 両方の痕跡は存在しますが、保持期間が短すぎます degraded 効果的なプロジェクト方針をインシデントレビューと整合させる 両方の痕跡が存在し、証拠も新鮮で、コントロールも一致しています healthy 証拠層はこの有界ドリルを通過しました この順序により、設定警告が実際のデータ損失を隠すのを防ぎます。ピン留めされていない画像は重要ですが、ポリシー内のトレースが欠けていると最初のインシデントが発生します。 移行を盲目の回復の外に置く Phoenixは、新しいメジャーバージョンが起動時にデータベース移行を実行する可能性があることを文書化しています。また、アプリケーションの画像を巻き戻すと警告が出ます そんなことはない 自動的にデータベーススキーマをダウングレードします。そのため、「古いコンテナを再起動する」というのは、失敗した大規模なアップグレード後の安全でない一般的な復旧ルールになってしまいます。 Kubernetesの場合、渡りガイド移行を推奨しています initContainer つまり、メインコンテナがライブネスチェックを受ける前に完了します。また、PostgreSQLのインデックス作成が書き込みをブロックすることもあると説明しています。 PHOENIX MIGRATE INDEX CONCURRENTLY=true 書き込みロックを保持せずに済みますが、文書化されたトレードオフとしては移行が約2〜3倍遅くなり、新しいポッドは完了を待ち続けます。 これらのメカニクスを状態に変換します: 承認されたメンテナンスウィンドウ内に進行中の移行は waiting ; 移動状態が不明な状態で行われるクエリは次のようになります。 uncertain ; 失敗した移行がスキーマを進めた可能性がある場合 needs human ; 自動ロールバックは、データベース互換計画が明示的にサポートしている場合にのみ許可されます。 これは他の信頼できるエージェント操作に必要な違いと同じです。活動は進行ではなく、待機は止まらず、コマンド完了は意図された結果ではありません。 この領収書が証明できないことを知りましょう 再開レシートは一つの証拠を守ります。すべてのモデルルートに計測されていること、すべてのスパンが意味的に正確であること、バックアップが復元可能であること、エージェントが意図した結果を達成したことを証明するものではありません。また、LLM評価の内容を検証するものではありません。それらは別々のテストです。 レシートは意図的に内容を含みません。これにより露出は減りますが、意味の誤りには限定的な評価や人間のレビューが必要になります。利用できない証拠は利用不可とみなす。健全な推測で埋めないでください。 Sidewispの意図する健康モデルは、証拠の新鮮さ、到達可能性、有用な進展、結果、安全な回復境界に焦点を当てています。ここでの運用パターンはその領域に合致しますが、出荷された統合の主張ではありません。Sidewispは現在Phoenixに接続しておらず、この展開も監視していません。 Sidewisp は現在プライベートプレビュー段階です。 エージェントスタックの最初の健康契約を定義する場合は、この再履歴領収書を代理店の成果領収書の隣に置いてください。1つは診断証拠が残っているかどうかを示しています。もう一方は、その作品がそうだったかどうかを教えてくれます。