Phoenix LLM Observabilidade: Prove Traces Sobreviver Restart

A Fênix pode mostrar um rastro completo enquanto a sua própria camada de evidências ainda é frágil. Uma página acessível prova que o processo web responde agora. Znot prova que um rastro mais antigo sobreviveu a uma reinicialização, que o coletor retomou a ingestão, ou que a política de retenção efetiva cobre o período em que a sua equipa investiga incidentes. O padrão razoável é um exercício de reinicialização de dois canais: 1. Perguntar um rastro sem conteúdo criado antes da reinicialização; 2. Reiniciar o serviço Phoenix sem alterar o código da aplicação; 3. Reinterrogar o mesmo rastro; 4. emitir e consultar um segundo rastro após a reinicialização; 5. Comparar a idade de observação e a retenção efetiva com limites explícitos. O velho canário testa a persistência. Os novos testes canários retomaram a ingestão. Precisas de ambos. Se só houver o rastro antigo, o armazenamento pode estar bem enquanto a coleta está quebrada. Se só houver o novo rastro, o servidor voltou em armazenamento vazio ou inesperado. Tratem o Phoenix como três camadas de evidências . O Documentação de arquitetura de Phoenix separa o sistema em uma interface web, um coletor de vestígios e um backend de banco de dados SQL. Essa distinção é importante durante o diagnóstico: A interface pode responder enquanto a ingestão de OTLP falhar; O coletor pode aceitar uma conexão enquanto um rastro nunca se torna questionável; A base de dados pode ser acessada enquanto o contentor aponta para um novo diretório de trabalho SQLite; Todos os três podem estar em pé enquanto um trabalho de retenção remover provas mais cedo do que o processo de incidente espera. Phoenix suporta SQLite e PostgreSQL. A sua documentação atual posiciona o SQLite para desenvolvimento local e implantações de utilizador único, com dados sob o ~/.phoenix/ ou PHOENIX WORKING DIR . PostgreSQL é a escolha documentada de produção para implementações de vários usuários e de alta disponibilidade. Esta não é uma regra de que o SQLite seja sempre insalubre. Um único desenvolvedor pode executar uma instância local confiável com um volume montado. O fracasso está a deixar a persistência implícita. O Guia oficial do Docker mostra diretamente os dois contratos: Para PostgreSQL, Phoenix lê PHOENIX SQL DATABASE URL ; o guia documenta PostgreSQL 14 ou mais recente. Mantenha o valor da ligação no seu sistema secreto, não num recibo de saúde. O recibo precisa apenas da classe backend, de um identificador de implantação opaco e do resultado das consultas canárias. A fixação da imagem é um controlo separado. O latest pode ser conveniente para um ensaio local descartável, mas faz uma reinicialização capaz de alterar simultaneamente as expectativas do aplicativo e da sua base de dados. Registrar uma imagem imutável ou uma versão explícita antes do exercício. Uma reinicialização bem sucedida contra uma imagem desconhecida não é evidência reprodutível. Crie um recibo de reinicialização sem conteúdo Escolha um caminho canário que exerça o mesmo coletor e roteamento do projeto que o tráfego do agente que lhe interessa. Não coloque um pedido real, resposta modelo, argumento de ferramenta, credencial ou identificador de cliente no canário. Um rótulo de execução aleatória e timestamps são suficientes. O ponto final REST documentado da Phoenix pode lista de traços para um projeto com limites de tempo de início e intervalos opcionais. Use o método de autenticação da sua implementação, mas mantenha o valor de autorização fora do histórico do shell e da saída salvada. Por exemplo, definir valores de roteamento não secretos e solicitar uma janela de tempo estreita: Procure a resposta localmente para a trace id opaca do canário; não exporte o corpo de resposta como telemetria geral. Se você solicitar include spans=true , o tamanho da resposta e a latência da consulta aumentam, então a referência da API Phoenix recomenda buscar detalhes de intervalos preguiçosamente. O exercício de reinicialização precisa de rastrear a identidade e o tempo, não o conteúdo imediato. Um recibo mínimo pode parecer assim: effectiveRetentionDays significa a política associada ao projeto real, e não apenas um padrão de implantação. Phoenix retém dados indefinidamente por padrão, representado como zero dias em sua política de padrão. Um administrador pode atribuir políticas baseadas no tempo ou na contagem de rastreamento a projetos individuais. O padrão de tempo de implantação pode atualizar novos projetos sem alterar as prioridades específicas de projetos existentes. É por isso que a intenção de configuração e o estado efetivo do projeto são evidências diferentes. Compare a retenção com o seu processo operacional. Se um incidente pode ficar despercebido durante 14 dias, uma janela de rastreamento de sete dias é degradada mesmo quando todos os rastreamentos atuais estão presentes. Trinta dias também não é intrinsecamente saudável; é saudável apenas em relação à janela de revisão, orçamento de armazenamento e decisão de governança de dados. Faça o exercício sem esconder a interrupção Use a operação normal de reinicialização do tempo de execução. Não combinar o primeiro exercício com uma atualização Phoenix, migração de armazenamento, reconfiguração do coletor ou lançamento de aplicativos. A questão é isolar a persistência e retomar a ingestão. Imediatamente antes da reinicialização: 1. Registrar a versão fixa ou a digestão da imagem; 2. Confirmar o backend da base de dados pretendido e o volume duradouro ou a identidade da base de dados; 3. registar a política de retenção do projecto efetiva; 4. emitir o primeiro canário através do caminho instrumentado normal; 5. Faça uma consulta e armazene apenas o resultado booleano, ID de rastreamento e timestamps. Após reinicialização: 1. esperar o comportamento de prontidão documentado do serviço em vez de utilizar um sono arbitrário; 2. Perguntar o mesmo rastreamento pré reinicialização; 3. emitir um canário diferente após a reinicialização; 4. Pesquisar o novo rastreamento através da mesma rota do projeto; 5. Marcar o recibo e avaliá lo antes de expirar o seu limite de frescura. O equipamento de acompanhamento para este artigo aplica um limite de observação de cinco minutos e repete nove estados: O resultado é 9/9 cases pass . Duas configurações são classificadas como saudáveis: pinned PostgreSQL para uma implantação de vários usuários, e pinned SQLite com um volume durável para um usuário. Os restantes aparelhos produzem deliberadamente evidence lost , ingestion failed , waiting , needs human , uncertain ou degraded . A decisão é de prioridade: Evidências O veredicto Decisão do operador A migração está a correr como planeado . waiting Observe a operação de manutenção limitada; não a chame uma falha de agente Migração falhou needs human Interromper a recuperação automática e inspecionar o limite da base de dados/versão A observação é mais antiga do que o limite de frescura uncertain Reexamine a consulta antes de agir Há um antigo rastro desaparecido na política. evidence lost Preservar o armazenamento atual e diagnosticar a identidade de montagem/base de dados em primeiro lugar Há vestígios antigos , mas não há vestígios novos . ingestion failed Inspecção da acessibilidade do coletor, do caminho do exportador, da autarquia e do encaminhamento do projeto Ambos os vestígios existem, mas a retenção é curta demais. degraded Alinear a política eficaz do projecto com a revisão dos incidentes Ambos os vestígios existem, as provas são frescas e os controles coincidem. healthy A camada de evidências passou por esta broca limitada Esta ordenação impede que um aviso de configuração masque a perda de dados real. Uma imagem não apontada é importante, mas um rastro desaparecido na política é o primeiro incidente. Colocar as migrações fora da recuperação cega O Phoenix documenta que novas versões principais podem executar migrações de banco de dados durante a inicialização. Ele também adverte que o rolamento de uma imagem de aplicativo para trás faz Znot automaticamente rebaixar o esquema de banco de dados. Isso torna o reiniciar o antigo recipiente uma regra de recuperação genérica insegura após uma atualização importante falhada. Para Kubernetes, o Guia de migração recomenda executar migrações em um initContainer para que sejam concluídas antes que o recipiente principal seja submetido a verificações de vida. Ele também explica que a criação de índice PostgreSQL pode bloquear escrever. O PHOENIX MIGRATE INDEX CONCURRENTLY=true evita manter o bloqueio de escrita, mas a troca documentada é uma migração aproximadamente duas a três vezes mais lenta, e a nova cápsula ainda está esperando para ser concluída. Traduza essas mecânicas em estados: uma migração que corre dentro da janela de manutenção aprovada é waiting ; Uma consulta feita enquanto o estado de migração é desconhecido é uncertain ; uma migração falhada que possa ter avançado o esquema é needs human ; A devolução automática só é permitida quando o plano de compatibilidade com a base de dados o apoie expressamente. Esta é a mesma distinção que as operações de agentes confiáveis precisam noutros lugares: a atividade não é progresso, a espera não está presa e a conclusão do comando não é o resultado pretendido. Saber o que este recibo não prova . Um recibo de reinicialização de passagem protege um caminho de evidências. Não prova que cada rota modelo seja instrumentada, que cada intervalo seja semânticamente correto, que um backup possa ser restaurado ou que um agente tenha dado o resultado pretendido. Não valida também o conteúdo de uma avaliação LLM. São testes separados. O recibo é intencionalmente livre de conteúdo. Isso reduz a exposição, mas também significa que os erros semânticos exigem uma avaliação limitada ou revisão humana. Trate evidências inexistentes como inexistentes; não preencha as com uma suposição saudável. O modelo de saúde previsto do Sidewisp diz respeito à frescura das evidências, à acessibilidade, aos progressos úteis, aos resultados e aos limites de recuperação segura. O padrão operacional aqui corresponde a esse território, mas não se trata de uma reivindicação de integração marítima. O Sidewisp não se conecta atualmente à Phoenix nem monitora esta implantação. A Sidewisp está atualmente em prévia privada. Se estiver a definir o primeiro contrato de saúde para uma pilha de agentes, mantenha este recibo de reinicialização ao lado do recibo de resultado do agente. Uma diz lhe se as provas de diagnóstico sobreviveram. O outro diz te se o trabalho fez.