Atender a milhões de solicitações por minuto, em vários data centers, em um ambiente de microsserviços, não é uma tarefa fácil. Cada solicitação é roteada para muitos aplicativos e pode potencialmente travar ou falhar a cada etapa do fluxo. Identificar gargalos, solucionar problemas de falhas e conhecer nossos limites de capacidade são tarefas difíceis. No entanto, essas não são coisas das quais você pode simplesmente desistir "porque são difíceis", mas são tarefas que todo engenheiro deve ser capaz de realizar sem muita sobrecarga. É claro que temos que procurar que todos os engenheiros possam entender como estão suas aplicações a qualquer momento.
Como enfrentamos todos esses desafios todos os dias, chegamos ao ponto em que era necessária uma mudança de paradigma. Por exemplo, passe do antigo e familiar "investigar o passado" para o novo e desconhecido "investigue o presente". Esse é apenas um dos requisitos que criamos. Aqui estão mais alguns:
Visibilidade em tempo real
Parece bem direto, certo? No entanto, ao usar um sistema de monitoramento persistente, sempre há pelo menos alguns minutos de atraso. Esses minutos podem conter milhões de erros que potencialmente afetam seus negócios. Visar MTTR baixo significa cortar atrasos sempre que possível, passando da granularidade baseada em minutos para a segunda base.
Taxa de transferência, latência e taxa de erro estão vinculadas
Alguns componentes podem sofrer de alta latência, mas talvez a quantidade de tráfego que eles recebam seja insignificante. Outros podem ter baixa latência sob alta carga, mas isso ocorre apenas porque eles falham rapidamente em quase todas as solicitações (somos reativos!). Queríamos ver essas métricas juntas e classificá-las por importância.
Correção matemática em qualquer agregação (não minta!)
Ao lidar com a latência, deve-se considerar percentis, não médias, pois as médias podem enganar e podem não contar toda a história. Mas e se quisermos exibir a latência por host e, em seguida, por data center? se armazenarmos apenas percentis por host (o que é altamente comum em nosso setor), não é matematicamente correto calculá-los! Por outro lado, temos tanto tráfego que não podemos simplesmente armazenar qualquer medida com sua latência; e definitivamente não visualizá-los todos em tempo real
A resolução da latência é importante
Os sistemas baseados em JVM tendem a exibir números loucos ao observar os altos percentis (que loucura? Com tempestades intensas de contenção e contenção de trava, não há limite para o quanto esses valores podem piorar). É crucial para nós diferenciar entre latência nos percentis 99,5 e 99,9, enquanto os valores nos percentis 5 ou 10 realmente não importam.
Resumindo todos os requisitos acima, chegamos à conclusão de que nosso sofisticado sistema de monitoramento persistente, com sua resolução baseada em minutos, suportando milhões de métricas por minuto, não é mais suficiente. Gostamos que todo host possa gravar milhares de valores de métricas a cada minuto, e gostamos de poder visualizar dados históricos por longos períodos de tempo, mas, avançando, isso não é bom o suficiente. Portanto, como costumamos fazer, sentamos para repensar nossa coleção de métricas no nível do aplicativo e criamos uma solução nova e aprimorada.
Nossa Unidade de Monitoramento
Primeiro, considere a coleta de métricas da perspectiva do aplicativo. Logicamente, é o ponto de vista de um aplicativo de algum componente: uma chamada para outro aplicativo, para um back-end ou computação ligada à CPU simples. Portanto, para cada componente, medimos seu número de solicitações, falhas, tempos limite e retrocessos, juntamente com um histograma de latência por um curto período de tempo.
Além disso, queremos ver os hosts com pior desempenho em termos de qualquer métrica (pode ser latência média, erros numéricos, etc.)
Para alcançar essa exibição para cada componente medido, decidimos usar essas excelentes tecnologias:
Histogramas HDR
O HdrHistogram suporta a gravação e análise de contagens de valores de dados amostrados, em um intervalo de valores configurável, com precisão de valor configurável dentro do intervalo. Ele foi projetado para registrar histogramas de medições de latência em aplicativos sensíveis ao desempenho.
Por que isso é importante? Porque ao usar esses histogramas para medir a latência de algum componente, ele permite uma boa precisão dos valores nos percentis altos às custas dos percentis baixos
Assim, decidimos armazenar na memória instâncias de histogramas (bem como contadores para solicitações, erros, tempos limite, retrocessos, etc.) para cada componente medido. Em seguida, substituí-los a cada segundo e expor esses histogramas na forma de rx.Observable usando nossos próprios recursos do servidor de aplicativos .
Tudo o que resta é agregar e exibir.
Extensões Java reativas
O rx é uma ótima ferramenta para mesclar e agregar fluxos de dados na memória. No nosso caso, criamos um serviço para mesclar fluxos brutos de componentes medidos; agrupe-os pelo tipo medido e agregue-os em uma janela de alguns segundos. Mas aqui está o truque - fazemos isso sob demanda. Isso permite que os usuários visualizem resultados agrupados por qualquer dimensão que desejarem, sem perder a correção matemática da agregação de histogramas de latência.
Alguns exemplos dos operadores que usamos para agregar as várias unidades de monitoramento:
O operador de mesclagem rx permite tratar vários fluxos como um único fluxo
O operador rx window permite abstração de janela deslizante
O operador rx scan permite agregação em cada janela
Para simplificar, podemos dizer que, para cada componente que queremos exibir, nos conectamos a cada máquina para buscar o ponto de extremidade do fluxo monitorado, realizamos 'mesclagem' para obter uma única abstração de fluxo, 'janela' para obter um resultado por unidade de tempo, e 'scan' para executar a agregação
Hystrix Dashboard
Os funcionários da Netflix encontraram uma ótima fórmula para exibir o status dos componentes de veiculação de uma maneira que vincula volume, porcentagem de erros e latência em uma única exibição. Nós realmente gostamos disso, então adotamos essa interface para mostrar nossos resultados agregados.
A visualização do painel hystrix de um único componente medido mostra contadores de sucessos, falhas, tempos limite e retrocessos, juntamente com um histograma de latência, informações sobre o número de hosts e muito mais. Além disso, fornece uma visualização em balão, que aumenta / diminui com o volume de tráfego por componente e é codificada por cores pela taxa de erro.
Veja abaixo como isso fica na exibição de detalhamento de todos os componentes da solicitação. O usuário obtém uma visão de todos os componentes medidos, classificados por volume, com uma lista dos hosts com pior desempenho.
Outro exemplo mostra a visualização de um aplicativo, com nada além de seus pontos de entrada, agrupados por data center. Nossos funcionários de Operações acham isso extremamente útil quando precisam reequilibrar o tráfego nos datacenters.
OK, até agora tudo bem. Agora vamos falar sobre o que realmente fazemos com isso.
Solução de problemas
Às vezes, um aplicativo não atende ao seu SLA, seja em latência ou taxa de erro. O caso simples é devido a um componente interno danificado (por exemplo, algum back-end caiu e todas as chamadas para ele resultam em falhas). Nesse ponto, podemos visualizar o painel do aplicativo e localizar facilmente a chamada com falha. Um caso de uso mais complexo é um aumento no número de chamadas para um componente de alta latência à custa de um componente de baixa latência (por exemplo, queda na taxa de acertos do cache). Aqui, nosso detalhamento precisará se concentrar na quantidade relativa de tráfego que cada componente recebe - podemos esperar uma proporção de 1: 2, enquanto, na realidade, podemos observar uma proporção de 1: 3.
Se houver alertas suficientes, isso pode ser detectado por um alerta. A visualização em tempo real nos permitirá localizar a causa raiz rapidamente, mesmo quando o alerta é geral.
Comparação de desempenho
Em muitos casos, queremos comparar o desempenho de dois grupos de hosts que executam a mesma operação, como atualizações de versão ou alterações de topologia. Usamos tags para diferenciar grupos de máquinas (cada datacenter é uma tag, cada ambiente e até cada nome de host). Em seguida, podemos solicitar uma métrica específica, agrupada por tags, para obter a seguinte visualização:
Teste de carga
Realizamos vários tipos de testes de carga. Uma é onde transferimos o máximo de tráfego possível para um data center, tentando atingir o primeiro gargalo em todo o sistema. Outra é executada em aplicativos específicos. Nos dois casos, usamos o painel do aplicativo para visualizar os gargalos, como faríamos ao solucionar eventos inesperados.
Um aspecto a ter em mente é que, quando um aplicativo é carregado, às vezes a CPU é limitada e as medidas são falsas, porque os threads simplesmente não recebem tempo de CPU. Outro caso em que isso acontece é durante o GC. Nesses casos, também devemos medir os efeitos desse fenômeno.
A unidade de medição, nesse caso, é 'jvm hiccup', que basicamente significa pegar uma linha, deixar dormir por um tempo e medir o “tempo de medição além do tempo de sono”. Soluços baixos significa que podemos confiar nos números apresentados por outras métricas.
Qual é o próximo?
O monitoramento em tempo real tem um papel crítico em nosso trabalho diário, e temos muitos planos para alavancar essas medições. Desde o balanceamento de carga mais inteligente orientado por métricas no cliente até as implantações de canários com base no comportamento real dos aplicativos - não há limite para o que você pode alcançar ao medir as coisas de maneira rápida e confiável.
