Ao usar as métricas RED – taxa, erro e duração – você pode obter uma compreensão sólida do desempenho de seus serviços para os usuários finais.
O monitoramento de um aplicativo é crucial para fornecer um produto e uma experiência de qualidade aos usuários. Mas simplesmente coletar uma tonelada de métricas de aplicativos não resolve o verdadeiro problema. O que as empresas de software precisam é de uma maneira de obter insights acionáveis de suas métricas para que possam corrigir rapidamente quaisquer problemas que seus usuários estejam enfrentando.
Origens do método RED
O método RED é uma metodologia de monitoramento criada por Tom Wilkie com base no que aprendeu enquanto trabalhava no Google. RED é derivado de algumas práticas recomendadas estabelecidas no Google, conhecidas como “Quatro Sinais Dourados”, desenvolvidas pela equipe SRE do Google.
A principal razão por trás do RED é que as filosofias e metodologias de monitoramento anteriores, como o método USE, não se alinhavam totalmente com os objetivos das empresas de software e das arquiteturas de software modernas. USE se aplica mais a hardware e infraestrutura, enquanto o método RED pretende focar no que os usuários de uma aplicação estão realmente vivenciando.
O objetivo do método RED é garantir que o aplicativo de software funcione adequadamente para os usuários finais, acima de tudo. Na era moderna das arquiteturas de microsserviços, contêineres e infraestrutura em nuvem, as métricas relacionadas ao hardware não são tão importantes, desde que seus objetivos de nível de serviço (SLOs) sejam atendidos.
Método RED explicado
RED significa taxa, erros e duração. Elas representam as três principais métricas que você deseja monitorar para cada serviço em sua arquitetura:
- Taxa (R) – O número de solicitações que o serviço está processando por segundo.
- Erro (E) – O número de solicitações com falha por segundo.
- Duração (D) – A quantidade de tempo que cada solicitação leva.
Usando essas três métricas, você pode obter uma compreensão sólida do desempenho de seus serviços. O número de solicitações fornece uma base de quanto tráfego está indo para o seu serviço. A parte dessas solicitações que contém erros permite que você saiba se um serviço está funcionando em seu SLO. Por fim, o tempo que leva para cada solicitação ser processada pelo seu serviço fornece uma visão geral da experiência do usuário em seu aplicativo.
Benefícios do método RED
O primeiro benefício do método RED é ajudar a reduzir a carga cognitiva necessária para que os engenheiros determinem por que um serviço está apresentando problemas. O RED abstrai os detalhes internos de cada serviço em algo que pode ser compreendido em toda a arquitetura. Isso não apenas significa que os problemas podem ser resolvidos mais rapidamente, mas também que é mais fácil dimensionar uma equipe de operações porque os membros agora podem estar de plantão para serviços que eles próprios não escreveram.
A abstração RED facilita a compreensão do que está errado e a determinação de como corrigi-lo. Mesmo que o serviço que estão tentando consertar seja efetivamente uma caixa preta que eles não entendem internamente, o engenheiro pode analisar os dados de telemetria e determinar a melhor ação para melhorar a experiência do usuário. Como as mesmas métricas são usadas para todos os serviços, a quantidade de tempo de treinamento ou conhecimento específico do serviço também é reduzida.
Outro benefício do método RED é que ele se alinha melhor com os usuários e com os objetivos gerais da empresa. Os usuários não se importam com sua infraestrutura. Eles não se importam com a utilização da CPU, o uso da memória ou qualquer outra métrica de hardware. Eles se importam se começarem a ver mensagens de erro ao usar seu aplicativo. Eles se preocupam se as páginas do seu site demoram muito para carregar. O método RED deixa bem claro quando um serviço não está de acordo com seu SLO e seus usuários estão tendo uma experiência ruim.
Um benefício final do método RED é que a automação de tarefas e alertas em seus serviços se torna mais fácil. Automatizar tarefas repetitivas é mais simples e seguro porque todos os serviços são tratados da mesma forma. Você também pode padronizar coisas como layouts de painel entre serviços porque as mesmas três métricas estão sendo usadas.
Influxo de dados
Influxo de dados
Limitações do método RED
Todos esses benefícios não significam que o método RED seja perfeito. O método RED foi projetado principalmente para aplicativos orientados a solicitações; portanto, para casos de uso que envolvem processamento em lote ou streaming, ele pode não fornecer o insight necessário.
Uma segunda desvantagem é que a visão “externa” do RED significa que pode ser difícil saber o quão perto um serviço está de falhar. Um ligeiro aumento no tráfego pode fazer com que a duração da sua resposta aumente e você pode não ter métricas internas do aplicativo para determinar o motivo. Usar o método RED significa que suas métricas podem ser interpretadas de maneira diferente dependendo de vários fatores, portanto, requer implementação deliberada.
A boa notícia é que o método RED nunca foi concebido como uma forma de cobrir todos os aspectos da monitorização. Tom Wilkie recomenda que a metodologia de monitoramento RED seja usada em combinação com outros métodos de monitoramento como USE para dar às equipes uma cobertura completa de monitoramento de sua aplicação.
Tim Yocum é diretor de operações da InfluxData , onde é responsável pela engenharia de confiabilidade do site e pelas operações da infraestrutura multinuvem da InfluxData. Ele ocupou cargos de liderança em startups e empresas nos últimos 20 anos, enfatizando o fator humano na excelência da equipe SRE.
