SLI: os indicadores que mostram a saúde real do sistema

O que são SLIs e por que métricas brutas não bastam

A diferença entre monitorar servidores e monitorar a experiência do usuário

SLI (Service Level Indicator) é uma métrica quantificável que representa um aspecto específico da qualidade do serviço do ponto de vista do usuário. Métricas brutas de infraestrutura como uso de CPU e memória do servidor são importantes para diagnóstico, mas não dizem se o usuário está tendo uma boa experiência — um servidor com 10% de CPU pode estar retornando erros 500 para 80% das requisições sem que qualquer alarme de infraestrutura dispare. SLIs bem definidos respondem perguntas como: "Qual fração das requisições dos últimos 30 minutos foi atendida com sucesso e dentro do tempo esperado?" Essa perspectiva centrada no usuário é o que diferencia times de SRE maduros de times que apenas monitoram hardware.

Tipos de SLI — availability, latência, error rate, throughput

As quatro categorias fundamentais que cobrem a maioria dos sistemas

Os quatro tipos principais de SLI são: availability (fração de requisições bem-sucedidas), latência (fração de requisições atendidas abaixo de um threshold de tempo), error rate (fração de requisições que retornaram erro), e throughput (volume de dados ou operações processadas por unidade de tempo). Para um serviço de API REST, um SLI de availability seria "porcentagem de requisições com código HTTP 2xx ou 3xx nos últimos 10 minutos". Para latência, seria "porcentagem de requisições respondidas em menos de 200ms". A combinação desses quatro tipos cobre a experiência do usuário de forma abrangente — uma API pode estar disponível mas ser tão lenta que é inútil, ou ter latência baixa mas alto error rate.

Como definir bons SLIs — boas e más práticas

O que torna um SLI útil versus enganoso

Um bom SLI é mensurável objetivamente, relevante para a experiência do usuário, e estável o suficiente para ser monitorado sem ruído excessivo. Más práticas comuns incluem: usar médias em vez de percentis para latência (a média esconde cauda longa), medir a saúde do servidor em vez da experiência do usuário, criar SLIs impossíveis de medir com a instrumentação existente, e definir SLIs que sempre ficam verdes mesmo quando usuários estão insatisfeitos. Uma prática excelente é começar mapeando os user journeys críticos — login, checkout, busca — e definir SLIs que medem exatamente esses fluxos, incluindo chamadas a dependências externas que são invisíveis para o servidor mas visíveis para o usuário final.

Coletando dados para SLIs com Prometheus e OpenTelemetry

Instrumentação prática para capturar métricas de qualidade

Prometheus é o padrão de fato para coletar e armazenar SLIs em sistemas modernos: a biblioteca de cliente registra counters e histogramas no processo da aplicação, e o servidor Prometheus faz scraping periódico desses dados. Em .NET, o pacote prometheus-net expõe métricas como http_requests_total (counter por status code) e http_request_duration_seconds (histograma de latência) com poucas linhas de configuração. OpenTelemetry é a evolução que padroniza a instrumentação — a mesma configuração exporta métricas para Prometheus, Datadog, Grafana Cloud ou qualquer backend compatível. A regra prática é instrumentar primeiro os endpoints críticos de negócio (autenticação, transações, consultas principais) e expandir para cobrir o sistema inteiro progressivamente.

SLI de latência — percentis p50, p95, p99

Por que a média mente e os percentis revelam a verdade

A média de latência é enganosa porque uma pequena fração de requisições extremamente lentas pode representar a experiência de uma parcela significativa dos usuários sem mover a média de forma perceptível. Percentis resolvem isso: p50 (mediana) é a latência que 50% das requisições estão abaixo — representa o usuário típico. p95 é a latência que 95% das requisições estão abaixo — representa usuários com conexão mais lenta ou requests mais complexos. p99 é o "pior caso frequente" — 1% das requisições é mais lento que isso, o que em um sistema com 1 milhão de requests por hora significa 10.000 usuários com experiência ruim. Um SLI de latência bem definido geralmente monitora p95 ou p99, com alertas quando qualquer um desses percentis ultrapassa o threshold acordado.

SLI de error rate — classificando erros por severidade

Nem todo erro é igual — como distinguir falhas reais de ruído

Error rate como SLI requer cuidado na definição do que conta como erro. Respostas 4xx (como 404 Not Found ou 401 Unauthorized) geralmente representam comportamento correto do sistema em resposta a requisições inválidas — incluí-las no error rate pode mascarar erros reais do servidor. O foco deve ser em 5xx (erros do servidor) e timeouts, que indicam falhas no lado da aplicação. Alguns sistemas refinam ainda mais: um erro em um endpoint não crítico de analytics tem impacto menor do que um erro no endpoint de checkout. Definir SLIs por criticidade do endpoint — separando o caminho crítico de negócio das operações auxiliares — permite alertas mais precisos e error budgets mais úteis para priorização.

SLI de saturação — CPU, memória, fila de espera

Métricas preditivas que avisam antes da degradação chegar ao usuário

SLIs de saturação medem o quão perto dos limites o sistema está operando — CPU acima de 85%, memória acima de 80%, tamanho da fila de processamento crescendo continuamente. Esses indicadores são preditivos: quando a saturação é alta, é questão de tempo até a latência aumentar e o error rate subir. O Prometheus expõe métricas de saturação nativamente para contêineres (via cAdvisor) e aplicações (via clientes de métricas). SLIs de saturação são especialmente importantes em sistemas de fila e streaming: um consumer group do Kafka com lag crescendo é um sinal antecipado de que os workers não estão acompanhando a produção — um SLI de saturação alerta antes que os usuários percebam atraso no processamento.

Dashboards e alertas baseados em SLI

Transformar números em ação — visualizações que guiam decisões

Um dashboard de SLI eficaz mostra o estado atual de cada indicador em relação ao SLO correspondente, a tendência nas últimas horas, e o error budget restante no período de janela (geralmente 30 dias). Grafana com datasource Prometheus é a combinação mais comum, permitindo criar visualizações de SLI com queries como sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])). Alertas devem ser configurados para disparar quando o burn rate do error budget é alto — não quando uma métrica isolada ultrapassa threshold, mas quando o ritmo de consumo do budget indica que o SLO será violado antes do fim do período. Alertas baseados em burn rate reduzem drasticamente o número de falsos positivos em comparação com alertas estáticos por threshold.

A relação entre SLI, SLO e SLA

Como as métricas técnicas se conectam a compromissos comerciais

SLI é o dado bruto coletado — a porcentagem de requests com sucesso medida pelo Prometheus. SLO é a meta que a equipe de engenharia define para esse SLI — manter acima de 99,9% nas últimas 4 semanas. SLA é o contrato formal com o cliente, geralmente mais conservador que o SLO para absorver variações e manter margem de segurança. A cadeia funciona assim: se o SLI cai abaixo do SLO, o error budget é consumido e a equipe deve priorizar confiabilidade. Se o SLO é violado repetidamente, o SLA pode ser ativado, resultando em penalidades contratuais. Manter o SLO como objetivo interno mais rigoroso que o SLA externo é uma prática de engenharia madura que protege tanto a experiência do usuário quanto a relação comercial.

Conclusão — SLIs como linguagem comum entre engenharia e negócio

Métricas que todos entendem e que orientam as decisões certas

SLIs bem definidos transformam a conversa sobre qualidade de sistema: em vez de discutir se o servidor está com CPU alta, a equipe discute se os usuários estão tendo a experiência acordada. Essa mudança de perspectiva, de métricas de infraestrutura para métricas de experiência, é o que diferencia times de engenharia orientados a confiabilidade de times que apenas apagam incêndios. Comece com poucos SLIs bem escolhidos para os fluxos críticos, instrumente com Prometheus ou OpenTelemetry, crie dashboards com burn rate, e use os dados para priorizar trabalho de forma objetiva. Continue em: Fundamentos obrigatórios antes de produção.