Um dos princípios fundamentais para executar um sistema confiável é medir o que importa. Isso significa medir o que é importante para o negócio e o que é importante para resolver problemas. A New Relic mede o que é importante por meio da New Relic. Isso inclui o uso de nossos agentes, produto de objetivos de nível de serviço (SLO) e produto de alertas.
Agentes APM na New Relic
As equipes de engenharia gostam de executar o agente de monitoramento do desempenho de aplicativos (APM) para seus serviços, e todo o hardware normalmente é monitorado usando o agente de infraestrutura da New Relic. Isso cria um conjunto consistente de métricas para que qualquer engenheiro possa alternar entre equipes ou serviços e ainda entender as principais métricas de integridade.
Os agentes APM da New Relic são altamente ajustados para fornecer as métricas-chave corretas para detectar e diagnosticar problemas no serviço. As principais métricas incluem tempo de resposta HTTP, tempos de chamadas de banco de dados e tempos de chamadas de HTTP externas.
Além disso, embora equipes dedicadas de agentes frequentemente adicionem nova instrumentação aos nossos agentes, outras equipes de engenharia — aquelas que utilizam os agentes para monitorar sua própria infraestrutura, bancos de dados e serviços de streaming — também contribuíram com instrumentação para nossos agentes. Um ótimo exemplo é a instrumentação atual do Kafka no agente Java. Esta instrumentação foi criada originalmente por uma equipe da New Relic que opera muitos serviços de streaming principais do Kafka. A instrumentação foi inicialmente criada como uma extensão do agente Java. Depois de ser adotada por muitas equipes internas, a instrumentação foi finalmente colocada no produto APM. A interface do Kafka, que exibe essas métricas, também foi criada em conjunto por uma equipe de produto do APM junto com nossas principais equipes do Kafka e dos serviços de streaming.
Instrumentação eficaz
Usando dashboards e Nerdpacks para eliminar a alternância de contexto
As equipes da New Relic são treinadas para pensar em dados de observabilidade durante o desenvolvimento. Além da instrumentação padrão fornecida em nossos agentes, as equipes de engenharia podem criar uma instrumentação personalizada adicional. Algumas equipes enviam instrumentação personalizada para a New Relic usando agentes APM. Outras criaram bibliotecas para enviar instrumentação diretamente para nossos endpoints públicos de métricas, eventos, logs e traces. Exemplos de instrumentação personalizada incluem um evento da New Relic para cada consulta ao banco de dados da New Relic (NRDB) e um evento para cada conexão inicial do agente APM com a New Relic. As equipes então exibem esses eventos personalizados em dashboards ou Nerdpacks personalizados (aplicativos personalizados). Esses aplicativos personalizados integram instruções textuais com resultados de consultas e visualizações em tempo real.
Por exemplo, problemas de paralisação do pipeline do Kafka podem ser diagnosticados com visualizações em um Nerdlet personalizado, que também gera automaticamente o comando necessário para estender a retenção de dados, transformando um processo manual de várias etapas em uma única ação de copiar e colar. Isso reduz significativamente a alternância de contexto e acelera a resolução.
Objetivos de nível de serviço
Alcançando objetivos de negócios com SLOs
Os objetivos de nível de serviço (SLOs) são importantes porque definem e medem a experiência do cliente ao longo de um período de tempo definido. Eles são essenciais para equilibrar o trabalho de confiabilidade com novas funcionalidades. Na New Relic, exigimos que todas as equipes mantenham um conjunto interno de SLOs. Antes de implementar SLOs em toda a empresa, descobrimos que nossos dados de telemetria eram extremamente ricos, mas estavam ajustados para resolução de problemas e não para medir a experiência do cliente. Então criamos um programa de elevação de nível de SLO que ajudou as equipes a criar SLOs focados no cliente, com valores que refletiam a realidade da época.
Utilizando essas medições, conseguimos compartilhar com a empresa o custo para operar no SLO atual e o trabalho necessário para aumentá-lo. As equipes que mais se beneficiam dos SLOs monitoram seus SLOs diariamente e tomam medidas corretivas quando necessário. Essas equipes não apenas melhoraram a experiência do cliente como também reduziram significativamente a quantidade de alertas.
Alertas e Terraform
Como automatizar insights proativos
Na New Relic, nossas equipes usam os alertas da New Relic para serem notificadas sobre quaisquer anomalias no sistema. Isso permite que os engenheiros da New Relic tomem medidas rapidamente para mitigar qualquer possível degradação do sistema. A maioria das equipes usam o Terraform para criar e manter seus alertas no controle de versão. A maioria das equipes também usam alertas detalhados para garantir que alertas sejam criados para qualquer nova célula ou ambiente. A seguir, um exemplo de um alerta agrupado por hostname:
SELECT latest(etcdServerProposalsFailedRate) FROM K8sEtcdSample WHERE clusterName = 'my-cluster' FACET hostname
Para garantir que as equipes tenham os alertas corretos, a New Relic fornece um conjunto de alertas recomendados para equipes em nossos Padrões de Engenharia. Isso inclui alertas para interrupções por falta de memória (Out of Memory, OOM), pods em espera, atraso do Kafka, taxas de erro e outros. Os líderes então configuram os alertas de suas equipes no dashboard (já que cada alerta é registrado no banco de dados New Relic, ou NRDB) e monitoram as tendências semanalmente.