Monitorando aplicativos
Instana apresenta a próxima geração de APM com sua hierarquia de serviços de aplicativos, pontos finais e perspectivas de aplicativos entre eles. O principal objetivo é simplificar o monitoramento da qualidade do serviço do seu negócio Com base nos dados coletados de rastreamentos e sensores de componentes, o Instana identifica seu ambiente de aplicativos diretamente a partir dos serviços que estão sendo executados.
As soluções Application Performance Management (APM) tradicionais são sobre o gerenciamento do desempenho e da disponibilidade de aplicativos.
Uma aplicação para ferramentas APM é um conjunto estático de ambientes de execução de código (por exemplo, JVM ou CLR) que são monitorados por meio de um agente. Normalmente, o aplicativo é definido como um parâmetro de configuração em cada agente.
Esse conceito, que era um bom modelo para aplicativos clássicos de 3 camadas, não funciona mais em aplicativos de (micro)serviço modernos. Nem sempre um serviço pertence a exatamente um aplicativo. Por exemplo, considere um serviço de pagamento com cartão de crédito que é utilizado tanto na loja online de uma empresa quanto em seus pontos de venda. Definir cada serviço como um aplicativo poderia resolver essa questão, mas isso traz os seguintes novos desafios:
- São muitas aplicações para monitorar : tratar cada serviço como uma aplicação gera centenas ou milhares de aplicações. O monitoramento de aplicativos por meio de painéis torna-se impraticável devido à sobrecarga de dados.
- Perda de contexto : tratar cada serviço separadamente dificulta a compreensão das dependências ou do papel do serviço no contexto mais amplo de um problema.
Resumo
Distribuição de latência
O gráfico de distribuição de latência é ideal para investigar problemas relacionados à latência em suas aplicações, serviços ou terminais. Você pode selecionar um intervalo de latência no gráfico e, usando o menu “Ver no Analytics”, explorar mais detalhadamente as chamadas específicas no Unbounded Analytics.
Questões e mudanças relacionadas à infraestrutura
A guia "Resumo" exibe problemas e alterações na infraestrutura relacionados às suas aplicações, serviços ou terminais. Essas informações ajudam a identificar correlações com alterações significativas nas métricas da aplicação, como um aumento na taxa de chamadas com erro ou na latência.
Para saber mais sobre alguns problemas ou mudanças específicos, selecione um intervalo de tempo desejado no gráfico e clique no item de menu Visualizar eventos , que o leva à visualização Eventos.
Tempo de processamento
O gráfico de Tempo de Processamento ajuda a entender quanto tempo é gasto no processamento em um aplicativo, um serviço ou no próprio endpoint (Self), e quanto tempo é gasto chamando as dependências a jusante, o que é detalhado por tipo de chamada, como Http, Database, Messaging Rpc, SDK,, etc.
Por exemplo, se a latência de uma chamada ao Shop serviço for 1000ms, o Shop serviço faz uma chamada de ` HTTP ` ao Payment serviço que leva 300ms e, em seguida, outra chamada ao banco de dados Catalog do serviço que leva 200ms, o tempo de processamento interno do Shop serviço é 1000-300-200=500ms.
Deslocamento de tempo
Para comparar métricas com períodos anteriores, você pode usar a funcionalidade “Time Shift”, conforme mostrado na imagem. Esteja ciente de que a precisão pode diminuir ao comparar métricas com dados históricos.
Mapa de dependência de aplicativo
O mapa de dependência está disponível para cada aplicativo e fornece,
- uma visão geral das dependências de serviço dentro do seu aplicativo.
- uma representação visual de chamadas entre serviços para entender caminhos de comunicação e rendimentos.
- diferentes layouts para ter um rápido entendimento da arquitetura do aplicativo.
- acesso confortável às visualizações de serviço (painéis, fluxos, chamadas e problemas.)
Mensagens de erro
As mensagens de erro são mensagens coletadas a partir de erros ocorridos durante a execução do código de um serviço. Por exemplo, se uma exceção for lançada durante o processamento e não for interceptada ou tratada pelo código do aplicativo, ela será listada na guia “Mensagens de erro ”. Um exemplo seria uma exceção não manipulada em um método doGet do Servlet, o que faz com que a solicitação seja respondida com HTTP 500.
Mensagens de log
As mensagens de log são coletadas a partir de bibliotecas ou estruturas de registro de log instrumentadas. Por exemplo, consulte a seção "Registro" na lista de bibliotecas compatíveis. Quando um serviço grava uma mensagem de log com gravidade WARN ou superior por meio de uma biblioteca de registro, a mensagem é exibida na guia Mensagens de log. Além disso, as mensagens de log capturadas são exibidas nos detalhes do rastreamento, no contexto do respectivo rastreamento. Se uma mensagem de log foi registrada com gravidade ERROR ou superior, ela é marcada como um erro. As mensagens de log com gravidade inferior a não WARN são rastreadas.
Infraestrutura
A partir da visualização “Perspectiva da aplicação” ou do painel de controle “Serviços”, é possível acessar o componente de infraestrutura correspondente exibido na visualização “Monitoramento de infraestrutura”.
O componente da infraestrutura "Não monitorado"
A lista de componentes de infraestrutura de um aplicativo ou serviço pode, às vezes, incluir um host, contêiner ou processo "não monitorado".
O componente "Não monitorado" indica que, para algumas ou todas as chamadas a um serviço, não foi possível associá-las a um componente específico da infraestrutura. Os serviços são entidades "lógicas" e, normalmente, estão vinculados a componentes de infraestrutura por meio do processo monitorado. Isso não se aplica a serviços web de terceiros, que não são monitorados, mas ainda assim possuem serviços e pontos de extremidade criados com base no nome do host + caminho. Como não se conhece nenhum host ou processo, esses serviços estão associados ao componente de infraestrutura "Desconhecido".
Alertas inteligentes
Visualize uma lista de todos seus Alertas inteligentes configurados. Clique em um alerta para visualizar sua configuração, modificá-la ou visualizar seu histórico de revisões Se necessário, também é possível desativar ou remover o alerta.
Para obter informações sobre como adicionar um alerta, consulte a documentação do Smart Alerts.
Ajuste do intervalo de tempo
O intervalo de tempo utilizado nos painéis ou análises do Instana pode diferir ligeiramente do intervalo de tempo selecionado no seletor de datas. O intervalo de tempo do painel ou da análise exclui o primeiro e o último depósito parcial. Por exemplo, ao selecionar a predefinição “Últimas 24 horas” no seletor de horário às 15h15 do dia 20 de janeiro, o intervalo de tempo é ajustado para o período entre as 15h30 do dia 19 e as 19h January–3:00, do dia 20 de janeiro. Esse ajuste é feito porque a granularidade do respectivo gráfico é de 30 minutos O ajuste do intervalo de tempo assegura a consistência entre diferentes widgets na mesma página e evita a interpretação incorreta de depósitos parciais como uma tendência de métrica inesperada, por exemplo, uma queda no número de chamadas.
Dados aproximados
Ao visualizar um painel ou realizar uma consulta no Analytics para um intervalo de tempo específico que ultrapasse os últimos sete dias, você poderá ver o Indicador de Dados Aproximados em diferentes widgets; ele é usado para indicar que o Instana está acessando um número reduzido de rastreamentos e chamadas estatisticamente significativos para atender às consultas. Exemplo:
Rastreios e chamadas que ocorrem raramente podem não ser representados em tais cenários.
Nota sobre a precisão da amostragem para métricas no nível das chamadas
O sistema utiliza amostragem aleatória com base no hash do ID do rastreamento, o que garante uma amostragem consistente no nível do rastreamento. No entanto, isso tem implicações na análise de métricas no nível da chamada:
- A amostragem é feita por traço, não por chamada. Se os tamanhos dos traços variarem significativamente (por exemplo, o número de chamadas por traço), os dados no nível das chamadas podem ficar distorcidos.
- Por exemplo, um único rastreamento com mais de um milhão de chamadas 2.4 pode afetar significativamente as métricas no nível das chamadas se o sistema o incluir na amostragem.
- Esse é um comportamento esperado, não um defeito. Isso ilustra como funciona a amostragem baseada em traços.