Plaid.com - uma compania tecnológica do ramo financeiro que permite a aplicações se conectar a contas bancárias de usuários - possui integração com mais de 9600 instituições financeiras distintas, das quais adquire (para processamento posterior) e processa dados. O monitoramento dessas integrações é um desafio devido à natureza heterogênea das integrações multiplicada pelo número existente. As mesmas métricas podem ter diferentes interpretações em integrações distintas, e as métricas que devem ser consideradas alarmantes também divergem. Plaid reconstruiu seu sistema de monitoramento baseando-se em AWS Kinesis, Prometheus, Alertmanager e Grafana para resolver os desafios de escalabilidade e baixa latência.
O sistema de monitoramento que era utilizado pela Plaid dependia muito do sistema de logs baseado em Elasticsearch (ES). Nagios efetuava uma consulta no cluster ES e encaminhava qualquer alerta para o PagerDuty. Além da falta de flexibilidade, também não era escalável para lidar com o aumento de tráfego, uma vez que o período de retenção do ES diminuía devido ao aumento do tamanho dos logs. A falta de uma visualização de histórico de métricas, configuração manual de alertas e a dependência frágil em mudanças de logs levou o time a repensar sua abordagem de monitoramento. Eles decidiram analisar os requisitos - o que tem e como deve ser monitorado, no contexto do seu caso de uso específico. Requisitos funcionais incluíram priorizar métricas baseando-se no impacto que causam ao cliente e os custos de instrumentação, enquanto que os requisitos técnicos mantiveram o foco em escalabilidade, consultas com baixa latência, suporte a alta cardinalidade e facilidade em usar o sistema por parte dos desenvolvedores.
O time escolheu Prometheus como uma base de dados em série temporal, Kinesis como um stream processor, Alertmanager para envio de alertas e Grafana para visualização. Os três últimos foram escolhidos devido a flexibilidade e Prometheus e Grafana funcionam bem em conjunto. Eles desenharam o fluxo de execução de monitoramento de forma que tanto os componentes padrões quanto os customizados possam puxar dados e gerar métricas. Serviços que exportam métricas padrões podem utilizar o fluxo de execução padrão, enquanto que os demais enviam eventos para o Kinesis, do qual um consumidor recebe os eventos e gera métricas. Ambos os casos acabam como métricas no Prometheus e a partir daí, o restante do fluxo de execução é igual para todos. Tipicamente, eventos levam menos que cinco segundos para se tornar métricas.
Alertmanager - uma parte do projeto Prometheus - possui configuração baseada em arquivos. Uma pergunta que deve ser feita é se por ter esse tipo de configuração não pode se tornar um desafio de manutenção conforme o número de integrações (e consequentemente, novas métricas) aumente? InfoQ entrou em contato com Joy Zheng, engenheiro de software na Plaid, para descobrir.
Arquivos de configuração implementados manualmente para o Alertmanager não têm sido um grande problema porque nós podemos definir regras baseando-nos em categorias de alertas ao invés de alertas individuais (por exemplo, uma regra que notifica Pagerduty para qualquer alerta de alta prioridade e o Slack para alertas de baixa prioridade). Por outro lado, a configuração do Prometheus têm sido um desafio para nós devido ao alto número de integrações. A implementação inicial do monitoramento dependia de arquivos de configuração criados manualmente, no entanto, em um projeto subsequente construímos uma ferramenta para gerar os arquivos de configuração derivando de código JS ao invés de copiar e colar definições de regras existentes para novas integração.
O time parece ter feito um bom trabalho em relação a facilidade de usar pois de um time de 45 engenheiros, 31 fizeram contribuições para as configurações de monitoramento. O fluxo de execução padrão não necessita de nenhuma instrumentação - bibliotecas compartilhadas automaticamente através da base de código exportam métricas. Zheng entrou em maiores detalhes sobre como eles padronizaram as convenções de métricas:
Bibliotecas compartilhadas ajudam a manter nomenclaturas padrões de métricas, uma vez que a biblioteca controla os nomes, e tudo o que o serviço deve fazer é especificar um rótulo para suas chamadas. Utilizando valores enumerados Protobuf nos ajudou a estabelecer um padrão para alguns rótulos. No entanto, nós ainda não temos convenções estabelecidas para nomenclatura de métricas customizadas por serviço, e isso torna difícil para que alguém descubra métricas no Prometheus sem saber previamente a que elas se referem. Nossa solução atual para discoverability têm sido principalmente, a construção de painéis de visualização e controle no Grafana exibindo as métricas mais importantes por serviço existentes no Prometheus.
Prometheus - que roda em uma configuração federada na Plaid - possui retenção limitada de métricas. No entanto, isso não foi um desafio onde dados históricos são necessários, disse Zheng, pois "nossa forma de uso inicial do Prometheus tinha como foco gerar alertas imediatamente, logo, manter apenas alguns meses de histórico não era um grande problema. Nós encontramos mais casos de uso para análise histórica de métricas baseada com o passar do tempo, e recentemente, entregamos um projeto que exporta métricas do Prometheus para o nosso long-term data warehouse (no AWS Redshift)."
O fluxo de dados pode chegar desordenado ou com atraso ao consumidor devido a latência de rede ou reordenação. O Kinesis é responsável por lidar com isso no caso de uso da Plaid, disse Zheng:
Utilizando o Kinesis conseguimos manter a ordenação mesmo quando o consumidor do Kinesis fica inoperante. Nós temos observado atraso de alguns minutos no consumidor de eventos devido a latência e então picos para que possa se recuperar, o que acaba causando 1-2 páginas de espúrio. Outro benefício de utilizar o Kinesis é ter a capacidade de suportar leitores paralelos, logo, nós também temos uma leitura paralela do ambiente de monitoramento de pré-produção utilizando o mesmo fluxo de eventos no qual testamos mudanças no monitoramento em larga escala. Como um resultado, normalmente nós vemos uma boa estabilidade dos consumidores de eventos.
Monitoramento também tem uma participação no fluxo de implantação, onde o código é publicado em um ambiente interno de staging antes de ser promovido para produção. O fluxo de trabalho atual na Plaid, frequentemente envolve desenvolvedores verificando painéis de controle (incluindo monitoramento de métricas) antes de promover uma versão para ambientes subsequentes.