Como saber se um erro do Immich vem do cliente ou do servidor

Determine se um erro do Immich ocorre do lado do cliente ou do servidor, reproduzindo a mesma ação com uma variável alterada e seguindo o pedido falhado ao longo do percurso.

Um banner móvel que diz “erro do servidor” pode, ainda assim, ter origem no estado do cliente, no TLS, num proxy inverso ou num pedido que o servidor rejeitou corretamente. Da mesma forma, uma falha exclusiva do navegador não prova que o navegador está avariado. Mantenha a conta, o recurso e a ação; compare clientes e rotas; depois utilize os códigos de estado e registos sincronizados para localizar a primeira camada que falha.

Reproduza a Mesma Ação num Segundo Cliente

Escolha uma ação determinística, como iniciar sessão, abrir um recurso conhecido, carregar a mesma fotografia pequena ou executar a mesma pesquisa. Repita-a com a mesma conta num navegador e num cliente móvel, mantendo a rota de rede inalterada. Registe a hora exata e o resultado de ambas as tentativas.

Um relatório recente do Immich em que um cliente Android falhou enquanto eram testadas outras vias de acesso ilustra o valor da comparação entre clientes. A causa de um tópico não é generalizável, mas um resultado específico de um cliente reduz significativamente o âmbito da próxima inspeção.

Se todos os clientes falharem na mesma ação ao mesmo tempo, o servidor, a base de dados, o armazenamento ou o percurso de rede partilhado sobem na lista de possibilidades. Se apenas um cliente falhar enquanto outro funciona através do mesmo endpoint, verifique a versão do cliente, o estado em cache, as permissões, a confiança local no certificado e o pedido exato que é diferente.

Altere a Rota sem Alterar a Conta ou o Recurso

Em seguida, compare uma rota local de confiança com a rota normal através do proxy inverso, VPN, túnel ou acesso remoto. Utilize a mesma conta e ação. Um sucesso local acompanhado de uma falha remota aponta para longe do próprio registo multimédia e na direção das camadas de DNS, TLS, proxy, firewall ou encaminhamento a montante.

O guia da ZimaSpace sobre o diagnóstico de percursos locais e remotos explica por que motivo o sucesso na LAN e o sucesso através da Internet são provas diferentes. Aplique essa distinção ao Immich antes de reinstalar uma aplicação móvel ou reconstruir o servidor.

Se ambas as rotas falharem de forma idêntica, pare de alterar as definições do proxy e inspecione o pedido do lado da aplicação. Se apenas a rota através do proxy falhar, capture o estado do proxy, o resultado do TLS, a resposta a montante e o tempo limite. Esta comparação de uma única variável impede que uma mensagem do cliente conduza a investigação para a camada errada.

Use os Códigos de Estado como Pistas, Não como Vereditos Finais

As classes de estado HTTP ajudam a determinar onde procurar, mas não identificam automaticamente o componente que causou a condição. Um 4xx significa frequentemente que o pedido, a autenticação ou a autorização não foram aceitáveis; um 5xx indica que um componente do servidor não conseguiu satisfazer o pedido. Os proxies podem gerar qualquer uma das classes antes de o Immich receber o pedido.

O guia de campos dos registos de acesso destaca o código de estado, o caminho do URL, a hora do pedido, o anfitrião remoto e os identificadores de pedido como campos úteis para a resolução de problemas. Capture esses valores para a única ação que falha, em vez de analisar milhares de linhas não relacionadas.

Se o proxy registar um 502 ou um tempo limite sem um pedido correspondente no Immich, siga o percurso a montante. Se os registos do Immich mostrarem um pedido e devolverem um 4xx determinístico, inspecione a autenticação, as permissões ou o conteúdo do pedido. Se o cliente comunicar uma falha, mas todas as camadas do servidor mostrarem 2xx, inspecione a análise do cliente, a cache local ou os pedidos subsequentes.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Correlacione a Taxa de Erros, a Latência e os Registos do Servidor num Único Momento

Um pedido falhado pode ser um caso isolado. Reproduza a ação cinco a dez vezes e registe a taxa de sucesso e a latência enquanto observa os registos relevantes do servidor e do proxy. Se os erros aumentarem durante períodos de pressão sobre os recursos ou picos nas filas, o servidor pode estar intermitentemente indisponível, mesmo que uma segunda tentativa tenha sucesso.

A visão geral da Better Stack sobre erros e latência como sinais do serviço separa a taxa de erros da latência e do tráfego. Essa abordagem ajuda a distinguir um único pedido malformado do cliente de um percurso do servidor que só se degrada sob carga.

Se os registos do servidor contiverem a mesma exceção para vários clientes, trate o problema como sendo do lado do servidor até prova em contrário. Se o servidor nunca receber o pedido que falha, rastreie o DNS, o TLS, o proxy e a rede do cliente. Se apenas um cliente gerar uma estrutura de pedido diferente, atualize ou reponha esse cliente depois de preservar provas suficientes para confirmar a diferença.

Faça a Avaliação Final com um Teste de Dois por Dois

Utilize dois clientes e duas rotas: navegador-local, navegador-remoto, móvel-local e móvel-remoto. Mantenha a mesma conta e o mesmo recurso de teste. Esta matriz separa as falhas específicas do cliente das falhas específicas da rota e das falhas do servidor que afetam todas as combinações.

Uma causa no cliente é sustentada quando um cliente falha em ambas as rotas enquanto outro funciona. Uma causa na rota é sustentada quando ambos os clientes falham apenas através de uma rota. Uma causa no servidor é sustentada quando as quatro combinações reproduzem o mesmo erro da aplicação e os registos do servidor mostram a mesma operação falhada.

Depois de corrigir a camada identificada, repita as quatro combinações e reinicie uma vez o componente afetado. Pare quando a combinação que falhava originalmente funcionar sem quebrar os controlos. Ao escalar o problema, inclua a matriz, os carimbos de data e hora, os estados HTTP, excertos dos registos do proxy e do servidor, as versões dos clientes e um pedido reproduzível, em vez de uma captura de ecrã genérica.