Phoenix LLM Observabilidad: Prueba de huellas sobrevivir Reinicio

Phoenix puede mostrar un rastro completo mientras su propia capa de evidencia es aún frágil. Una página accesible demuestra que el proceso web responde ahora. Znot prueba que un rastro más antiguo sobrevivió a un reinicio, que el colector reanudó la ingestión, o que la política de retención efectiva cubre el período en que su equipo investiga incidentes. El defecto razonable es un simulacro de reinicio de dos canales: 1. consultar un rastro libre de contenido creado antes del reinicio; 2. reiniciar el servicio Phoenix sin cambiar el código de aplicación; 3. Buscar de nuevo el mismo rastro; 4. emitir y consultar un segundo rastro después del reinicio; 5. comparar la edad de observación y la retención efectiva con límites explícitos. El viejo canario pone a prueba la persistencia. Las nuevas pruebas canarias reanudaron la ingestión. Necesitas las dos cosas. Si solo existe el rastro antiguo, el almacenamiento puede estar bien mientras la colección está rota. Si solo existe el nuevo rastro, el servidor ha vuelto en almacenamiento vacío o inesperado. Trate a Phoenix como tres capas de evidencia . Documentación de arquitectura de Phoenix separa el sistema en una interfaz web, un colector de rastro y un backend de base de datos SQL. Esa distinción importa durante el diagnóstico: la interfaz puede responder mientras la ingestión de OTLP falla; el colector puede aceptar una conexión mientras que un rastro nunca se vuelve consultable; la base de datos puede ser accesible mientras el contenedor apunta a un nuevo directorio de trabajo SQLite; Todos los tres pueden estar en pie mientras un trabajo de retención elimina la evidencia antes de lo que espera el proceso del incidente. Phoenix admite SQLite y PostgreSQL. Su documentación actual posiciona SQLite para el desarrollo local y las implementaciones de un solo usuario, con datos bajo ~/.phoenix/ o PHOENIX WORKING DIR . PostgreSQL es la opción de producción documentada para implementaciones de múltiples usuarios y de alta disponibilidad. Esta no es una regla de que SQLite siempre sea poco saludable. Un solo desarrollador puede ejecutar una instancia local confiable con un volumen montado. El fracaso está dejando la persistencia implícita. El Guía oficial de Docker muestra directamente los dos contratos: Para PostgreSQL, Phoenix lee PHOENIX SQL DATABASE URL ; la guía documenta PostgreSQL 14 o más reciente. Mantenga el valor de la conexión en su sistema secreto, no en un recibo de salud. El recibo solo necesita la clase de backend, un identificador de despliegue opaco y el resultado de las consultas canarias. Pinar la imagen es un control separado. latest puede ser conveniente para una prueba local desechable, pero hace un reinicio capaz de cambiar las expectativas de la aplicación y su base de datos al mismo tiempo. Antes de realizar el simulacro, grabará una digestión de imagen inmutable o una versión explícita. Un reinicio exitoso contra una imagen desconocida no es evidencia reproducible. Construir un recibo de reinicio sin contenido Elige un camino canario que ejerza el mismo colector y el mismo enrutamiento del proyecto que el tráfico de agentes que te importa. No ponga un mensaje real, un modelo de respuesta, un argumento de herramienta, una credencial o un identificador de cliente en el canario. Una etiqueta de ejecución aleatoria y sellos de tiempo son suficientes. El punto final REST documentado de Phoenix puede lista de rastros para un proyecto con límites de tiempo de inicio y intervalos opcionales. Utilice el método de autenticación de su implementación, pero mantenga el valor de autorización fuera del historial del shell y la salida guardada. Por ejemplo, establecer valores de enrutamiento no secretos y solicitar una ventana de tiempo estrecha: Busque la respuesta localmente en busca del opaco trace id del canario; no exporte el cuerpo de respuesta como telemetría general. Si solicita include spans=true , el tamaño de la respuesta y la latencia de la consulta aumentan, por lo que la referencia de la API Phoenix recomienda obtener detalles de alcance perezosamente. El simulacro de reinicio necesita rastrear la identidad y el tiempo, no el contenido inmediato. Un recibo mínimo puede verse así: effectiveRetentionDays se refiere a la política adjunta al proyecto real, no simplemente a un despliegue por defecto. Phoenix conserva los datos indefinidamente por defecto, representado como cero días en su póliza por defecto. Un administrador puede asignar políticas basadas en el tiempo o el recuento de rastreo a proyectos individuales. El tiempo de implementación por defecto puede actualizar nuevos proyectos sin cambiar las prioridades específicas de los proyectos existentes. Es por eso que la intención de configuración y el estado efectivo del proyecto son pruebas diferentes. Compare la retención con su proceso operativo. Si un incidente puede permanecer desapercibido durante 14 días, una ventana de rastreo de siete días se degrada incluso cuando todos los rastros actuales están presentes. Los 30 días tampoco son intrínsecamente saludables; son saludables sólo en relación con la ventana de revisión, el presupuesto de almacenamiento y la decisión de administración de datos. Ejecutar el simulacro sin ocultar la interrupción Utilice la operación de reinicio normal del tiempo de ejecución. No combine el primer ejercicio con una actualización de Phoenix, migración de almacenamiento, reconfiguración del colector o liberación de la aplicación. El punto es aislar la persistencia y reanudar la ingestión. Inmediatamente antes de reiniciar: 1. registrar la versión o la digestión de la imagen fijada; 2. confirmar el backend de base de datos previsto y el volumen duradero o la identidad de la base de datos; 3. registrar la política efectiva de retención del proyecto; 4. emitir el primer canario a través de la vía instrumental normal; 5. la consulta y almacenar sólo el resultado booleano, ID de rastreo y timestamps. Después del reinicio: 1. esperar el comportamiento documentado de preparación del servicio en lugar de utilizar un sueño arbitrario; 2. consultar el mismo rastro previo al reinicio; 3. emitir un canario diferente después del reinicio; 4. consultar la nueva pista a través de la misma ruta del proyecto; 5. sellar el recibo y evaluarlo antes de que expire su límite de frescura. El dispositivo de acompañamiento para este artículo aplica un límite de observación de cinco minutos y repite nueve estados: El resultado es 9/9 cases pass . Dos configuraciones se clasifican como saludables: pinned PostgreSQL para un despliegue de múltiples usuarios, y pinned SQLite con un volumen duradero para un usuario. Los demás aparatos producen deliberadamente evidence lost , ingestion failed , waiting , needs human , uncertain o degraded . La prioridad de la decisión es: Pruebas El veredicto Decisión del operador La migración está funcionando como estaba planeado . waiting Observe la operación de mantenimiento limitada; no lo llamen falla de agente Migración fallida needs human Detener la recuperación automática e inspeccionar el límite de la base de datos/versión La observación es más antigua que el límite de frescura uncertain Reexamine la consulta antes de actuar. En la política, un viejo rastro desapareció. evidence lost Preservar el almacenamiento actual y diagnosticar primero la identidad de montaje/base de datos Los restos antiguos permanecen pero los nuevos no están presentes. ingestion failed Inspeccionar la accesibilidad del colector, la ruta del exportador, el autor y el enrutamiento del proyecto Ambos rastros existen pero la retención es demasiado corta degraded Alinear la política efectiva del proyecto con la revisión de incidentes Ambos rastros existen, la evidencia es fresca, y los controles coinciden healthy La capa de evidencia pasó este simulacro limitado Este ordenamiento evita que una advertencia de configuración enmasque la pérdida de datos real. Una imagen sin pieza es importante, pero un rastro perdido en la política es el primer incidente. Colocar las migraciones fuera de la recuperación ciega Phoenix documenta que las nuevas versiones principales pueden ejecutar migraciones de base de datos durante la puesta en marcha. También advierte que al volver a rodar una imagen de aplicación, not degrada automáticamente el esquema de base de datos. Eso hace que "reiniciar el viejo contenedor" sea una regla de recuperación genérica insegura después de una actualización importante fallida. Para Kubernetes, el Guía de migración recomienda ejecutar migraciones en un initContainer para que se completen antes de que el contenedor principal sea sometido a controles de vida. También explica que la creación del índice PostgreSQL puede bloquear las escrituras. PHOENIX MIGRATE INDEX CONCURRENTLY=true evita sostener esa cerradura de escritura, pero el compromiso documentado es una migración aproximadamente dos o tres veces más lenta, y la nueva cápsula todavía espera su finalización. Traducir esas mecánicas en estados: una migración que se ejecuta dentro de su ventana de mantenimiento aprobada es waiting ; una consulta tomada mientras el estado de migración es desconocido es uncertain ; una migración fallida que pueda haber avanzado el esquema es needs human ; El retroceso automático solo se permitirá cuando el plan de compatibilidad de la base de datos lo respalde explícitamente. Esta es la misma distinción que las operaciones de agentes fiables necesitan en otros lugares: la actividad no es progreso, la espera no está atascada y la finalización del comando no es el resultado previsto. Saber lo que este recibo no demuestra Un recibo de reinicio de paso protege una vía de evidencia. No demuestra que cada ruta modelo esté instrumentada, que cada período sea semánticamente correcto, que se pueda restaurar una copia de seguridad o que un agente haya entregado el resultado previsto. Tampoco valida el contenido de una evaluación de LLM. Esas son pruebas separadas. El recibo es intencionalmente libre de contenido. Esto reduce la exposición, pero también significa que los errores semánticos requieren una evaluación limitada o revisión humana. Tratar la evidencia no disponible como no disponible; no llene con una conjetura saludable. El modelo de salud previsto de Sidewisp se refiere a la actualidad de la evidencia, la accesibilidad, los avances útiles, los resultados y los límites de recuperación segura. El patrón operativo aquí se ajusta a ese territorio, pero no es una reivindicación de una integración embarcada. Sidewisp no se conecta actualmente a Phoenix ni monitorea este despliegue. Sidewisp se encuentra actualmente en versión preliminar privada. Si está definiendo el primer contrato de salud para una pila de agentes, guarde este recibo de reinicio junto al recibo de resultado del agente. Uno le dice si la evidencia de diagnóstico sobrevivió. El otro le dice si el trabajo lo hizo.