Surgido das experiências adquiridas enquanto trabalhava no Google, Tom Wilkie desenvolveu o método RED (rate, errors
and duration), derivada das práticas adotadas pelo time de SRE da Google. O foco do RED é no que os usuários estão tendo de experiência com a aplicação, focando nos serviços individuais dentro de uma arquitetura distribuída.
Isso se deve ao fato que o método USE atende bem hardware, rede e discos, mas ele não atende bem os cenários de serviços de software, exigindo uma filosofia especifíca para software em microsserviços.
RED busca garantir que os serviços de software funcionem adequadamente para os usuários, onde as principais métricas dão nome ao método.: Taxa (Red), Erros (Errors) e Duração (Duration). A seguir iremos falar um pouco de cada uma delas.:
✔ Taxa (Rate).: Taxa é utilizada para medir o número de solicitações por segundo que um serviço está processando.
Ela permite entender o comportamento da demanda em cada serviço individual e identificar padrões que podem tanto gerar oportunidades como problemas de otimização.
Medir taxas de solicitações por segundo pode ser útil para a maioria dos serviços de software, mas alguns casos que possuem padrões indefinidos de demanda, olhar médias ao longo de determinados períodos de tempo pode ser mais indicado.
Além disso, a taxa pode ser uma métrica de contexto útil para entender o comportamento de outras métricas em um ambiente complexo e distribuído.
✔ Erros (Errors).: Dentro da filosofia do método RED, erros são os números de solicitações que tiveram problemas.
É uma métrica importante por que ela analisa algo que impacta diretamente os usuários, pois serviços com erros são percebidos pelos usuários. Solicitações que demoram mais que um tempo limite determinado podem ser considera das erros mesmo que retornem mensagem de sucesso.
Lembrando que é importante não apenas contar a quantidade de erros, mas considerar a taxa de erros como uma % do tráfego. Por exemplo.: taxas de erros de 1% para um serviço pode ser considerada aceitável, mas inaceitável para outro, classificar os tipos de erros é importante e ajuda na criação de alertas mais eficientes e na priorização
de atendimento em caso de incidente.
✔ Duração (Duration).: duração é a métrica que irá medir o tempo que as solicitações são atendidas. É a mais facilmente percebida pelos usuários, quando um serviço fica lento, os usuários logo percebem a lentidão.
Para medir essa métrica, é necessário atenção especial as distribuições para evitar usar apenas média. Médias podem trazer resultados enganosos por causa da influência de determinadas quantidades de solicitações. Trabalhar com porcentagens como P95 por exemplo podem trazer uma foto mais realista do que a maioria dos usuários estão tendo de comportamento do serviço.
Separar o que é a duração de solicitações com sucesso de solicitações com falha é importante pois cada uma gera diferentes impactos para os usuários e para o diagnóstico de problemas.
Benefícios do Método RED
RED fornece diversas vantagens para aplicações construídas em arquitetura de microsserviços. Além de reduzir a carga de trabalho através de uma visão de como cada serviço está agindo, possibilitando a rápida identificação de serviços com problemas ou instáveis.
RED também permite identificar como anda a experiência do usuário, possibilitando ações para manter os usuários satisfeitos com os serviços. Na arquitetura de microsserviços, a metodologia RED permite abstrair de forma eficiente o que está de errado com um serviço, permitindo ações mais eficientes e rápidas de correção.
Finalmente, RED permite a automação de tarefas e alertas, gerando aos times alertas e dashboards padronizados, o que torna os times mais efetivos.
Limitações e Considerações Finais
Apesar de ser muito bom para a arquitetura de microsserviços, RED tem algumas limitações que devem ser levadas em conta. Ele é muito bom para serviços orientados a solicitações, serviços que usam processamento em lotes ou streaming ele pode não ser tão efetivo. Outro ponto.: ele foca em solicitações síncronas, podendo não ser muito adequado para serviços assíncronos ou orientados a eventos.
Outra limitação é que RED não possui insights para problemas em recursos específicos, por exemplo.: um aumento no tempo de resposta de solicitação de forma ligeira pode ocorrer e você não ter as métricas internas do serviço para determinar as causas.
Em cenários de serviços que fazem muitas solicitações de downstream, RED pode ter suas métricas influenciadas por dependências, o que torna difícil identificar problemas no serviço.
O próprio criador do método, Tom Wikie recomenda que RED deva ser usada em conjunto com outras métricas, pois RED não foi pensada para cobrir todos os pontos da monitoração, o que faz com que ela seja possível de usar junto com outros métodos como o USE, fornecendo aos times uma cobertura de forma abrangente do monitoramento de uma aplicação.
Referências.:
https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services/
https://gist.github.com/lpsm-dev/af6acc8bf6581614e3f88485d87d27e4
https://www.opservices.com.br/o-metodo-red-uma-nova-estrategia-para-monitorar-microsservicos/
https://medium.com/@valentin.marlier/monitoring-made-simple-understanding-red-and-use-methodologies-608aec056ae9
https://www.sentinelone.com/blog/red-and-monitoring-three-key-metrics-and-why-they-matter/
https://thenewstack.io/monitoring-methodologies-red-and-use/
E-book Os Métodos RED e USE e os 4 Golden Signals para Observabilidade - Jeferson Fernando - LinuxTips.
Top comments (0)