Saúde do proxy: qual site e qual operação você testou?
Separe a alcançabilidade geral do proxy das falhas específicas do destino ao manter um conjunto de proxies reutilizável.
Um proxy busca sua página de verificação de IP e falha na API que sua aplicação precisa. Chamá-lo de “saudável” ou “morto” perde o fato mais útil: as duas solicitações eram diferentes.
Comece com um registro de todo o transporte para o endpoint. Você consegue alcançar o listener e concluir a negociação de proxy necessária? Mantenha as observações específicas do destino ao lado desse registro em vez de sobrescrevê-lo.
| Observação | Âmbito a investigar |
|---|---|
| O listener do proxy recusa conexões | O endpoint e a rota até ele |
| O proxy nega uma porta de destino | A operação permitida para esse destino |
| Um site retorna um erro de conta | A aplicação de destino e as credenciais |
| Respostas grandes travam, as pequenas terminam | A carga de transferência e a política de tempo limite |
Uma resposta HTTP pode estabelecer que um caminho de solicitação retornou algo e ainda assim continuar inutilizável para a aplicação. Mantenha o sucesso do transporte, o status HTTP e o conteúdo esperado como resultados separados.
Se um destino falha repetidamente, pause ou investigue esse par de endpoint e destino. Desativar o proxy para cada tarefa não relacionada pode desperdiçar capacidade útil. Por outro lado, uma falha de conexão global não deve permanecer escondida atrás do registro isolado de um único site.
Uma chave de saúde prática pode incluir o identificador do proxy, o serviço de destino e o tipo de operação. Evite usar a URL inteira que carrega credenciais ou cada caminho exclusivo de recurso como uma chave que cresce sem parar. Agrupe apenas onde o agrupamento faz uma previsão significativa sobre a próxima solicitação.
O objetivo são evidências de roteamento melhores, não uma coleção maior de emblemas verdes. Um resultado de saúde deve dizer o que foi tentado, quando e o que realmente estabeleceu.