A infraestrutura do Uber consiste em milhares de microservices que suportam aplicativos móveis, infraestrutura e serviços internos. Para fornecer alta disponibilidade desses serviços, a equipe de Monitoramento do Uber criou duas soluções de monitoramento internas: o uMonitor para alertas baseados em métricas de série temporal e o Neris para verificações e métricas no nível do host. Ambos os sistemas aproveitam um pipeline comum para alteração e deduplicação.
De acordo com Shreyas Srivatsan, engenheiro de software sênior da equipe de Monitoramento, o Uber rapidamente superou sua plataforma inicial de monitoramento e alerta à medida que seus negócios cresciam. Originalmente, eles estavam aproveitando o Nagios, enviando verificações de limite do Graphite em relação às métricas do Carbon, usando scripts criados pela equipe. No entanto, o Nagios exigia que o código fosse escrito e implantado para cada verificação de métrica, o que não era escalável à medida que as equipes e os produtos aumentavam. Na mesma época, eles começaram a ter problemas de escalabilidade com o cluster do Carbon. Isso levou a equipe do Monitoramento a criar seu próprio banco de dados de métricas, o M3.
Para processar as métricas no M3, a equipe construiu o uMonitor, um sistema de alertas baseado em métricas de séries temporais. No momento da postagem, o uMonitor tem 125.000 configurações de alerta que verificam 700 milhões de pontos de dados em mais de 1,4 milhão de séries temporais a cada segundo. Uma configuração de alerta no uMonitor consiste em uma consulta (Graphite ou M3QL) e um limite. A consulta retorna uma ou mais séries de tempo de M3 e os limites são aplicados a cada uma das séries. Os alertas, em seguida, são acionados se a consulta violar qualquer um dos limites.
O uMonitor consiste de três componentes separados: um serviço de armazenamento com uma API de gerenciamento de alertas, um planejador e workers. O serviço de armazenamento envolve um banco de dados do Cassandra que armazena as definições de alerta e a máquina de estado para os alertas. O agendador rastreia os alertas e despacha a verificação de alerta aproximadamente a cada minuto. Os workers executam as verificações de alerta em relação às métricas subjacentes, enquanto mantêm seu estado em Cassandra para garantir que não estejam em alerta excessivo.
Métricas padrão, como erros de endpoint ou consumo de CPU e memória, são geradas automaticamente pelo uMonitor. Outros alertas podem ser criados manualmente, conforme determinado por cada equipe. Atualmente, o uMonitor suporta dois tipos de limites para seus alertas: estático e anormal. Os limites estáticos são úteis para métricas de estado estacionário, como consultas que retornam valores consistentes. Limiares de anomalia são suportados por meio da plataforma de detecção de anomalias da Argos, Uber. Este sistema gera limites dinâmicos com base em dados históricos.
O Uber mantém um segundo sistema, Neris, para rastrear métricas de host que não estão disponíveis em seu sistema de métricas M3. De acordo com Srivatsan, eles acharam ineficiente armazenar seus "1,5 milhão de métricas de host geradas por minuto em 40.000 hosts por data center" em um banco de dados centralizado e optaram por consultar os hosts diretamente. O Neris tem um agente em execução em cada host para executar verificações de alerta nesse host. Na inicialização, o agente extrai sua configuração do armazenamento de configuração central do Uber, conhecido como Configuração de Objeto. A configuração determinará a função do host, que por sua vez configura as verificações apropriadas. O agente envia os resultados dessas verificações para uma camada de agregação que, em seguida, envia os dados para o Origami. O Origami é responsável por decidir quais alertas devem ser enviados com base em uma série de regras, juntamente com a deduplicação dos alertas.
Srivatsan afirma que "alta cardinalidade sempre foi o maior desafio para nossa plataforma de alerta". Como escreve Aaron Sun, "a cardinalidade no contexto dos sistemas de monitoramento é definida como o número de séries temporais de métricas únicas armazenadas no banco de dados de séries temporais do seu sistema". Originalmente, o Uber lidava com sua alta cardinalidade fazendo consultas de alerta retornarem várias séries e tendo regras que são acionadas apenas se um número suficiente de séries cruzasse um limite. Isso funcionou bem com as consultas que retornavam um número limitado de séries com dependências bem definidas. No entanto, quando as equipes começaram a escrever consultas para alertar sobre uma cidade, produto e versão de aplicativo para oferecer suporte às novas linhas de produtos, as consultas não atendem mais a essa restrição.
A equipe começou a aproveitar o Origami para ajudar nessas consultas mais complicadas. Como mencionado anteriormente, o Origami é capaz de deduplicação e acumulação de alertas. Também é capaz de criar alertas sobre combinações de cidade, produto e versão de aplicativo, que são acionadas em políticas agregadas. Essas definições de alerta são armazenadas nos repositórios git da equipe individual e, em seguida, sincronizadas com a Configuração do Objeto.
À medida que sua plataforma evolui, o alerta progride, desde a simples notificação do engenheiro de plantão até o acionamento automático da reversão e outras atividades de mitigação. O uMonitor fornece suporte total para reversões, mas também pode enviar POST para uma rota para acionar estratégias de mitigação mais complexas. Outros aprimoramentos de roteiros incluem coleta de métricas mais eficiente, simplificação da infraestrutura de execução de alertas e criação de interfaces de usuário para facilitar a correlação de dados entre várias fontes.