Diagnose server-side webpage errors using Application Monitoring - Application Real-Time Monitoring Service: Central de Documentação do Alibaba Cloud

Erros no lado do servidor — especialmente respostas 5xx — estão entre os mais difíceis de solucionar, pois a causa raiz frequentemente se oculta nas camadas profundas da lógica de negócios. A depuração tradicional baseada em logs exige acesso SSH, buscas manuais e suposições em services distribuídos.

O exemplo a seguir mostra logs de erro comuns de uma aplicação Java:

2018-03-19 20:34:22,890 ERROR [io.undertow.request] (default task-84) UT005023: Exception handling request to /plan-manage.htm:
java.lang.IllegalStateException: UT000010: Session not found wFcTlKtkzPiwMyNtBTFv48jU
	at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:353) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:121) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
	at org.springframework.security.web.context.HttpSessionSecurityContextRepository$SaveToSessionResponseWrapper.saveContext(HttpSessionSecurityContextRepository.java:323) [spring-security-web-3.2.5.RELEASE.jar:3.2.5.RELEASE]
	at org.springframework.security.web.context.HttpSessionSecurityContextRepository.saveContext(HttpSessionSecurityContextRepository.java:117) [spring-security-web-3.2.5.RELEASE.jar:3.2.5.RELEASE]
	at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:93) [spring-security-web-3.2.5.RELEASE.jar:3.2.5.RELEASE]
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) [spring-security-web-3.2.5.RELEASE.jar:3.2.5.RELEASE]
	at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192) [spring-security-web-3.2.5.RELEASE.jar:3.2.5.RELEASE]
	at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160) [spring-security-web-3.2.5.RELEASE.jar:3.2.5.RELEASE]
	at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:344) [spring-web-4.0.6.RELEASE.jar:4.0.6.RELEASE]
	at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:261) [spring-web-4.0.6.RELEASE.jar:4.0.6.RELEASE]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
	at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88) [spring-web-4.0.6.RELEASE.jar:4.0.6.RELEASE]
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) [spring-web-4.0.6.RELEASE.jar:4.0.6.RELEASE]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]

O Application Real-Time Monitoring Service (ARMS) elimina essa sobrecarga por meio de instrumentação de bytecode. Após a instalação do agente do ARMS, o sistema captura, agrega e rastreia exceções automaticamente, sem necessidade de alterações no código. Em um único console, identifique quando uma exceção ocorreu pela primeira vez, sua frequência de recorrência e qual chamada de método a desencadeou.

Essa abordagem é particularmente útil para:

Identificar o horário e a frequência de uma exceção específica em um cluster distribuído.
Comparar as exceções de hoje com as de ontem ou comparar exceções pós-lançamento com linhas de base pré-lançamento.
Recuperar o contexto completo da requisição — parâmetros, chamadas upstream e downstream — para uma exceção específica.
Rastrear uma transação com falha mencionada em um ticket de suporte até sua causa raiz.

Como funciona

O fluxo de trabalho de diagnóstico tem três etapas:

Instale o agente do ARMS na sua aplicação para iniciar a coleta automática de dados de exceção.
Analise as estatísticas de exceções para identificar tendências, picos e os tipos de erro mais frequentes.
Rastreie exceções até a causa raiz investigando snapshots de chamadas e pilhas de métodos.

Pré-requisitos

Instale o agente do ARMS na sua aplicação. Escolha o método correspondente à sua implantação:

Aplicação Java: Manually install an ARMS agent
Aplicação Java no Container Service for Kubernetes (ACK): Automatically install an ARMS agent in ACK
Aplicação Java em um cluster Kubernetes open-source: Automatically install an ARMS agent in a Kubernetes environment

Após a instalação, o agente começa a coletar métricas automaticamente, permitindo comparações diárias e semanais. As métricas rastreadas incluem tempo médio de resposta, contagem de requisições, erros, instâncias em tempo real, eventos de GC completo, consultas SQL lentas, exceções e chamadas lentas.

Analisar estatísticas de exceções

Use o console do ARMS para identificar quais exceções ocorrem com maior frequência e como as tendências mudam ao longo do tempo.

Faça login no console do ARMS.
No painel de navegação à esquerda, escolha Application Monitoring > Applications.
Na barra de navegação superior, selecione a região onde sua aplicação está implantada.
Na página Applications, clique em nome da sua aplicação.
Na página Application Overview, clique em aba Overview. A seção inferior exibe o número total de exceções, bem como as variações diárias e semanais.
Role para baixo até a seção Statistics Analysis e localize Exception Type. Este detalhamento mostra quantas vezes cada tipo de exceção ocorreu.
No painel de navegação à esquerda, clique em Application Details. Na página Application Details, clique em aba Exception Analysis para visualizar gráficos de estatísticas de exceções, contagens de erros e pilhas de exceções.

Rastrear uma exceção até a causa raiz

As estatísticas de exceções mostram o que está falhando, mas não o motivo. Um stack trace em um arquivo de log indica qual linha lançou a exceção, porém não fornece o contexto completo de chamadas upstream e downstream nem os parâmetros da requisição.

O ARMS preenche essa lacuna por meio da instrumentação de bytecode: ele captura snapshots completos de chamadas upstream e downstream para cada exceção com sobrecarga mínima de desempenho. Isso fornece o contexto completo da requisição — parâmetros, cadeia de chamadas e pilha de métodos — necessário para identificar as causas raízes.

Na aba Exception Analysis, encontre o tipo de exceção a ser diagnosticado e clique em Interface Snapshot na coluna Actions. A aba Interface Snapshot exibe os rastreamentos de chamadas associados a esse tipo de exceção.
Clique em TraceId de uma chamada específica para abrir seu rastreamento completo.

Nota
Para filtragem avançada de rastreamento, consulte Trace query.
Na página de detalhes do rastreamento, revise a cadeia completa de chamadas. Na coluna Method Stack, clique em ícone de lupa para inspecionar a pilha de métodos e compreender o contexto completo de execução da chamada com falha.

A Method Stack mostra uma duração total de rastreamento de 58947ms. As chamadas principais são:
- Tomcat Servlet Process (58947ms)
- sun.net.www.protocol.http.HttpURLConnection.getInputStream() (linha 1476, 21ms, mensagem de exceção: java.io.IOException: Server)
- org.apache.http.impl.client.CloseableHttpClient.execute(...) (linha 81, 104ms)
- org.apache.http.protocol.HttpRequestExecutor.execute(...) (linha 118, 93ms)
- com.alibaba.arms.console.service.impl.ArmsContextServiceImpl.clear() (linha 79, 0ms)

Após identificar a causa raiz, corrija o código subjacente. Para resolver outras exceções, retorne à aba Interface Invocation e revise outras chamadas com falha.

Configurar alertas proativos

Configure regras de alerta para notificar sua equipe no momento em que uma exceção ocorrer, em vez de descobri-la posteriormente. Crie regras de alerta para uma API específica ou para todas as APIs da sua aplicação. Para mais detalhes, consulte Application Monitoring alert rules.