Quatro Sinais de Ouro – Aprenda as quatro principais métricas da SRE

Quatro Sinais de Ouro – Aprendas as quatro principais métricas da SRE

Começar pelos quatro sinais de ouro permite criar métricas que ajudam na confiabilidade do software. Frequentemente é percebida uma queda de braços entre times de engenharia de produtos e operações. De um lado, times de produtos, querendo colocar sua proposta de valor em produção. Do outro lado operações, querendo maximizar a estabilidade em produção.

Quais são as quatro métricas de ouro?

Dado o cenário, surgem os quatro sinais de ouro, latência, tráfego, erros e saturação que é início para medir a confiabilidade do software, plataforma ou serviço. Com propósitos diferentes, cada métrica responde a questões específicas sobre o quão confiável é seu software ou serviço.

O intervalo entre uma ação e o retorno dessa ação é a Latência

Latência é o intervalo entre uma ação e uma reação. Ao clicar em um botão, ocorrerá uma chamada ao servidor, algo será processado com um retorno. Assim sendo, o tempo entra ação e reação é a latência, como dito anteriormente. Entretanto, nesse meio há a latência da internet, que deve ser desprezada.

Dessa forma, pelas lentes dos quatro sinais de ouro, para a latência, recomenda-se uma visão daquilo o servidor processou. Garantir aquilo que é processado, servidor, é o ponto inicial para o entendimento e análise da latência.

A fim de trazer ainda mais clareza e considerando que os status de retorno estejam certos, seguindo a RFC 2616, algumas situações podem ocorrer em uma requisição:

1. Em um curto período de tempo, milissegundos, temos código de retorno 200
2. Embora com tempo degradado, ou seja, um tempo maior que, temos o código de retorno 200
3. A falha acontece rapidamente com um código de retorno 500
4. A requisição demora muito tempo com um código de retorno 500

Erros lentos prejudicam a confiabilidade do software

Erros lentos são mais prejudiciais, uma vez que exigem mais recurso computacional se comparado com o errar rápido. A maneira recomendada de identificar essa lentidão é utilizando o modelo estatístico percentil.

Por exemplo, posso perguntar qual é a latência para serviços que responderam com código 200? Utilizando percentil, a resposta, pode ser 95% das minhas requisições ocorrem com menos de 100 milissegundos.

Para quem utiliza o Prometheus como banco de dados para monitoramento a métrica utilizada é http_request_duration_seconds_bucket com uma função histogram_quantile.

Tráfego e a quantidade de erros é o termômetro para confiabilidade

Assim como latência, ter a quantidade de erros e o tráfego medidos trará aos operadores clareza do estado atual do serviço. O foco é saber quantas requisições estão acontecendo no momento e quantas estão com erros.

Esses dois indicadores ajudam a saber sobre:

1. Se seu sistema está sofrendo com alta demanda de acessos
2. Em conjunto com a latência e saturação você compara o comportamento do serviço em caso de lentidão
3. Quantas requisições estão apresentando erros

Do mesmo modo, outras análises devem ser feitas para compreender melhor o estado do serviço. Tudo depende do cenário que está passando no momento da crise.

No Prometheus utilize as métricas http_requests_received_total e http_requests_in_progress. Em conjunto elas darão o total de requisições boas em andamento. Do mesmo modo você pode filtrar para descobrir a quantidade de requisições com erro, utilize o filtro “code=5xx”.

Error rate bem definido, assim como a disponibilidade ajudam a criar alertas para saber o quão disponível determinando o estado do serviço. Se alinhados à um SLO, Service Level Objectives, trará clareza no aspecto de experiência do cliente.

Recursos computacionais como CPU, memória, i/o e network são medidos pela Saturação

Não só latência, erros e tráfego, ao falarmos de saturação nos quatro sinais de ouro, estamos falando de recursos computacionais. Eventualmente, se um recurso computacional como memória está comprometido, as aplicações começam a ficar indisponíveis.

Alguns tipos de linguagens de programação como .NET, pelo Prometheus, possibilita diversos “contadores” para medir a saturação de um sistema.

JIT

• dotnet_jit_cpu_ratio
• dotnet_jit_method_total
• dotnet_jit_method_seconds_total

Memória e Garbage Collector

• dotnet_gc_allocated_bytes_total
• dotnet_gc_collection_count_total
• dotnet_gc_memory_total_available_bytes
• dotnet_gc_pause_ratio
• dotnet_gc_heap_size_bytes

Bloqueios

• dotnet_contention_total

Threads

• dotnet_threadpool_queue_length
• dotnet_threadpool_timer_count

Em resumo, construir sistemas confiáveis dependem de métricas eficazes.