Escutando os quatro sinais de ouro do SRE: usando Nginx + Prometheus + Grafana

Wilson Júnior
4 min readJul 10, 2019

--

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

Usuário na espera de uma operação

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.

Resultado dos goldens signals capturados e visualizados via grafana

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:

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.

--

--