Escutando os quatro sinais de ouro do SRE: usando Nginx + Prometheus + Grafana
Nós últimos anos muito vem se falando sobre o termo SRE (Site Reability Engineering). Várias empresas criaram o papel do Engenheiro de Resiliência em seu organograma, é um papel fundamental para que grandes sistemas atinjam um nível alto de confiabilidade e tenham um nível de frustração baixo mesmo durante momentos de mudanças e lançamento de novas funcionalidades.
O framework SRE foi criado desde 2003 quando um engenheiro de software foi convidado a coordenar uma equipe de operação no Google, este framework possui dois livros abertos para a leitura em: https://landing.google.com/sre/books/
Golden signals
Monitoração e métricas são as bases do framework, no capítulo 6 do Livro é introduzido sobre os “The Four Golden Signals”, que são sinais altamente valiosos para a monitoração de serviços.
São sinais muito mais precisos do que medir o uso de recursos como CPU, Memória e Rede de uma aplicação, com eles podemos medir a frustração dos usuários do sistema, estes são:
Latência
Quanto tempo uma transação demora para ser processada ? 2 milissegundos ? 10 segundos ? um minuto ?, nenhum usuário ou sistema dependente tolera uma espera muito alta.
Tráfego
Quantas transações meu sistema processa em uma faixa de tempo ? em qual momento do dia eu tenho um pico de tráfego ?
Erros
Qual a porcentagem de erro do meu serviço em uma determinada faixa de tempo ? nenhum usuário confia em um sistema que tenha que tentar novamente frequentemente devido a um erro de processamento.
Saturação
Quanto recurso computacional eu tenho disponível até meu sistema começar a degradar ?, CPU, Memória, Espaço de disco disponível, etc.
E agora ? quero ter minhas métricas desses sinais
Grande parte dos servidores hoje utilizam o Nginx para servir o tráfego de borda, vamos usar um exemplo utilizando nginx + o módulo nginx-vts + prometheus e grafana.
O Prometheus é um software open-source, cloud-native que nasceu da experiência adquirida de alguns engenheiros do Google que mantiveram o Borgmon (software interno do Google para métricas de sistemas)
O Grafana também é open-source disponibiliza a capacidade de ver as métricas de vários sistemas com gráficos excelentes.
O Nginx VTS possui a responsabilidade de expor métricas para que o prometheus consolide em um banco de time series poderoso.
Como calcular as métricas
O prometheus possui uma linguagem de query chamada PromQL, com ela podemos agregar os dados históricos e ter um visualização completa da situação de todas nossas métricas de ouro.
Volume
Para calcular o volume precisamos saber quantos requests nossa aplicação respondeu em uma determinada faixa de tempo, para calcular via prometheus somamos o incremento do contador de todos os requests, exemplo:
sum(increase(nginx_vts_server_requests_total[1d]))
Disponibilidade
A disponibilidade é o percentual de requisições que foram entregues com sucesso, para calcular via prometheus calculamos a quantidade de requests que tiveram erro e dividimos pela quantidade total.
sum(rate(nginx_vts_server_requests_total{code!~"5xx"}[1d]))/sum(rate(nginx_vts_server_requests_total[1d]))
Também é importante calcularmos o percentual de erros
sum(rate(nginx_vts_server_requests_total{code="5xx"}[1d]))/sum(rate(nginx_vts_server_requests_total[1d]))
Latência
A latência é uma métrica mega importante, porém alguns casos podem ofuscar o tempo de resposta de algumas requisições se olharmos apenas para o tempo médio, pois o percentual de requests com o tempo de resposta bom pode abater as frustrações de outros tempos de resposta, para isso o recomendado é avaliar a latência utilizando Percentis ou Percentile Rank
Podemos calcular a mediana:
histogram_quantile(0.5, sum(rate(nginx_vts_server_request_duration_seconds_bucket[1d])) by (le))
O percentil 90, que responde a pergunta: 90% dos requests foram entregues em até X segundos:
histogram_quantile(0.9, sum(rate(nginx_vts_server_request_duration_seconds_bucket[1d])) by (le))
O percentil 99, que responde a pergunta: 1% dos piores requests começaram a partir de X segundos:
histogram_quantile(0.99, sum(rate(nginx_vts_server_request_duration_seconds_bucket[1d])) by (le))
Hum! agora quero testar tudo isso
Criei um repositório que possui um docker-compose.yml
que já possui todos os serviços necessários para aprender sobre os golden signals
Baixe o projeto em: https://github.com/wpjunior/nginx-vts
git clone https://github.com/wpjunior/nginx-vts
Utilizando o docker compose subiremos os 3 serviços:
docker-compose up
Então agora teremos 3 endereços:
- http://localhost:8000, rodando o Nginx com métricas expostas em http://localhost:8000/metrics
- http://localhost:9090, rodando o prometheus
- http://localhost:3000, rodando o grafana
ao abrir o grafana pela primeira vez, usuário: admin, senha:admin, aponte o primeiro data-source: http://prometheus:9090 e importe o dashboard.json
que está dentro do projeto.
Conclusão
O framework SRE é um excelente guia para atingir uma boa confiabilidade de sistemas, coletando os sinais de ouro podemos utiliza-los como objetivo de assegurar a satisfação dos usuários, criar alertas quando estes objetivos são rompidos. Os livros disponibilizados pelo Google promovem um rico estudo de como o gigante da tecnologia promove a estabilidade de seus sistemas.