prefácio
Recentemente, o projeto da empresa estava fazendo uma revisão de vulnerabilidade de segurança, e as versões fastjson, tomcat e log4j de um lote de serviços foram atualizadas. Mais de 50 serviços foram lançados naquele dia. Verifiquei os logs da rede ao vivo e descobri que o serviço de adaptação possui informações anormais e as informações de erro são as seguintes
Caused by: feign.FeignException: status 400 reading TestServiceClient#calculateDuration(String); content:
<!doctype html><html lang="en"><head><title>HTTP Status 400 – Bad Request</title><style type="text/css">body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 400 – Bad Request</h1></body></html>
at feign.FeignException.errorStatus(FeignException.java:62)
at feign.codec.ErrorDecoder$Default.decode(ErrorDecoder.java:91)Aqueles que estão familiarizados com o protocolo HTTP devem saber que o status de resposta 400 significa que a solicitação do cliente é ilegal e o servidor não pode analisar a solicitação. Vamos dar uma olhada no processo de investigação naquele momento.
Processo de solução de problemas
Conforme mencionado acima sobre o log de exceção do serviço de adaptação, sabemos que é um problema de solicitação do cliente. Como o conteúdo do lançamento do serviço de adaptação desta vez não envolve necessidades específicas do negócio, notificamos a operação e manutenção para fazer um rollback de emergência do serviço de adaptação do cliente na rede ativa. Após a reversão de todos os nós do serviço de adaptação, verificou-se que a versão antiga do serviço de adaptação ainda apresentava um erro. Isso mostra que o problema não é causado pelo serviço de adaptação de nível superior, então começamos a verificar o negócio do pedido. O problema é que ao verificar o link no kibana com base no traceId, apenas a mensagem de erro do serviço de adaptação pode ser vista, mas não é possível ver as informações da solicitação do serviço seguinte do pedido. Naquela época, mais e mais usuários da rede ao vivo davam feedback. Não havia outra maneira a não ser reverter o serviço de pedidos. Depois que a reversão do serviço de pedidos foi concluída, o log de erros na rede ao vivo desapareceu.....
Posteriormente, a versão da rede ao vivo foi implantada no ambiente integrado e, em seguida, depurada remotamente no IDEA local, e um pedido foi feito na caneta de gravação. Como resultado, nem mesmo o áudio pôde ser carregado. Posteriormente, foi verificado que a versão do serviço de upload de áudio do ambiente integrado era a versão a ser lançada no dia seguinte e algumas correções de bugs também foram feitas, portanto, a versão do serviço de upload de áudio do ambiente integrado foi revertida para a rede ao vivo. Indo reproduzir a versão atual da rede, no log do serviço de pedidos, encontrei algumas pistas
Error parsing HTTP request header
Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: The HTTP header line [x-device-info:{"content":""0x00.","createTime":1562298084000,"deviceId":"12132123213213","deviceType":"ashkdahdksahkd","key":"232hahkdkadhksadhkad"}] does not conform to RFC 7230. The request has been rejected.
at org.apache.coyote.http11.Http11InputBuffer.skipLine(Http11InputBuffer.java:1074)
at org.apache.coyote.http11.Http11InputBuffer.parseHeader(Http11InputBuffer.java:977)
at org.apache.coyote.http11.Http11InputBuffer.parseHeaders(Http11InputBuffer.java:606)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:514)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:932)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1695)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)Descobriu-se que a solicitação do serviço de adaptação foi rejeitada pelo serviço tomcat do serviço de pedidos no final do serviço de pedidos, portanto, a solicitação não chegou ao serviço de pedidos, por isso explicou que não havia informações de solicitação para o serviço de pedidos ao consultar o log do link com base no traceId no kibana. Vendo as informações de exceção acima, seguimos o código-fonte do tomcat para ver qual era o problema, que fez com que o tomcat rejeitasse a solicitação. A localização do erro é a seguinte
Veja aqui, vamos ver quando rejeiçãoThisHeader está definido como verdadeiro
Preste atenção a este comentário // Cabeçalhos de comprimento de conteúdo malformados sempre devem ser rejeitados, cabeçalhos de solicitação de comprimento de conteúdo ilegais serão rejeitados. Vendo isso, eu ia ver onde o tamanho do conteúdo da solicitação era ilegal, mas descobri que não havia nenhum atributo de comprimento do conteúdo no cabeçalho da solicitação. Esta solicitação é uma solicitação posterior, mas não há dados no corpo. Se não houver dados no corpo da solicitação, o atributo Content-Length não será incluído no cabeçalho da solicitação. O atributo Content-Length é usado principalmente para indicar o comprimento dos dados do corpo da solicitação. Se não houver dados do corpo da solicitação, este atributo será omitido. Portanto, a causa final da falha foi encontrada. Então, por que não houve nenhum problema antes?Depois de ler o registro de envio do serviço, descobri que meu colega não apenas atualizou o jackson, mas também atualizou a versão do tomcat.
Resumir
Através desta matéria, o resumo é o seguinte
- Não entre em pânico ao encontrar problemas na rede ativa, pense com calma na natureza do problema e não se concentre apenas nos logs de negócios. Você não tem a menor ideia ao verificar os logs de negócios. O access.log do tomcat e do Nginx também é muito útil, assim como os logs do gateway. Com base nesses logs, verifique onde a solicitação foi interrompida.
- Um lote de serviços lançados desta vez são para alguns reparos de vulnerabilidades de segurança, e não há exigência de negócio, portanto pode haver omissões na verificação funcional do teste, o que levou à falha da rede ativa, por isso ainda é necessário ser cauteloso.