SLI: catálogo de exemplos por tipo de serviço e como definir

Definir um SLI errado é pior do que não ter nenhum. Um time que monitora o percentual de uptime do servidor acredita estar medindo confiabilidade — mas se os usuários enfrentam timeouts de 30 segundos nas respostas da API, o dashboard permanece verde enquanto a experiência degrada.

O Service Level Indicator (SLI) é a métrica que quantifica um aspecto específico do comportamento de um serviço do ponto de vista do usuário. Não é qualquer métrica de infraestrutura: é a métrica que, quando fora do intervalo esperado, significa que o usuário está sendo impactado. Integrado a uma estratégia de observabilidade, o SLI é o ponto de partida para definir SLOs e calcular error budgets.

Neste guia, você encontra um catálogo técnico de SLIs por categoria de serviço — com exemplos concretos de métricas, fórmulas e queries para cada tipo de sistema.

O que é um SLI e como se diferencia de uma métrica comum

Um SLI é uma proporção: eventos bons divididos pelo total de eventos válidos, expressa como percentual. A pergunta central ao definir um SLI é: o que significa “funcionar corretamente” para o usuário neste serviço?

Uma métrica de CPU é um dado de infraestrutura. Um SLI de disponibilidade é a proporção de requisições que retornaram resposta sem erro dentro do tempo esperado. A diferença é que o SLI está diretamente ancorado na experiência do usuário — não no estado interno do sistema.

A fórmula base de qualquer SLI é: SLI = (eventos bons / eventos válidos) × 100. O que varia por tipo de serviço é a definição de “evento bom” e “evento válido”.

SLIs para APIs e serviços HTTP

Disponibilidade

Mede a proporção de requisições que retornaram sem erro. A definição de “erro” deve excluir erros de cliente (4xx) — apenas erros de servidor (5xx) e timeouts indicam falha do serviço.

Fórmula: SLI = requisições com status < 500 / total de requisições válidas

Query Prometheus de referência:
sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

Latência

Mede a proporção de requisições atendidas abaixo de um threshold de tempo. O percentil mais comum é P95 ou P99 — não a média, que mascara outliers críticos.

Fórmula: SLI = requisições com latência < threshold / total de requisições válidas

Query Prometheus de referência:
sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m])) / sum(rate(http_request_duration_seconds_count[5m]))

Thresholds típicos por perfil de serviço: APIs síncronas de dados críticos: 200ms (P95). APIs de relatórios ou processamento batch: 2s (P95). APIs de upload ou processamento assíncrono: excluir do SLI de latência.

Corretude

Menos comum, mas crítico em sistemas financeiros ou de dados. Mede a proporção de respostas com conteúdo correto. Requer validação ativa (testes de fumaça ou canários que verificam o payload de resposta, não só o código HTTP).

SLIs para bancos de dados

Disponibilidade de leitura e escrita

Bancos de dados distribuídos frequentemente têm SLAs distintos para operações de leitura e escrita. O SLI deve separar as duas dimensões: a disponibilidade de leitura pode ser medida via replicas, enquanto a escrita exige o primary.

Exemplos de métricas: pg_stat_activity (PostgreSQL), mongodb_connections, mysql_up.

Latência de queries

O P99 de latência de queries é o SLI mais relevante para bancos de dados transacionais. Queries acima de 1s em bancos OLTP são um sinal de degradação independente do sistema estar "up".

Taxa de replicação

Em sistemas com replicas de leitura, o replication lag é um SLI crítico: define até onde os dados lidos podem estar desatualizados. Um lag acima de 5s pode ser aceitável para analytics, mas inaceitável para sistemas de pagamento.

SLIs para filas e sistemas de mensageria

Freshness (frescor)

Em sistemas baseados em eventos (Kafka, RabbitMQ, SQS), o SLI mais relevante não é disponibilidade — é frescor: a proporção de mensagens processadas dentro de uma janela de tempo aceitável após a publicação.

Fórmula: SLI = mensagens processadas em < X segundos / total de mensagens publicadas

Taxa de processamento

Mede se a taxa de consumo acompanha a taxa de produção. Uma fila que acumula mensagens indefinidamente está degradando mesmo que o consumer esteja "up".

Métricas relevantes: kafka_consumer_lag, rabbitmq_queue_messages, sqs_approximate_age_of_oldest_message.

SLIs para aplicações mobile e frontend

Em aplicações cliente, o SLI não pode ser medido no servidor — requer Real User Monitoring (RUM) ou instrumentação de SDK mobile.

Os SLIs mais relevantes para frontend são os Core Web Vitals: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) e CLS (Cumulative Layout Shift). A fórmula segue o mesmo padrão: proporção de sessões onde os indicadores estão dentro do threshold aceitável.

Métricas adicionais para mobile: taxa de crash (crashes / sessões), taxa de ANR (Application Not Responding) e taxa de sucesso de operações críticas (login, checkout, pagamento).

SLIs para pipelines de dados e ETL

Pipelines de dados têm perfil distinto dos serviços síncronos. Os SLIs mais relevantes são: completude (proporção de registros processados com sucesso vs. total esperado), frescor (proporção de execuções concluídas dentro da janela de tempo definida) e corretude (proporção de registros que passam na validação de qualidade).

Esses SLIs são especialmente críticos em arquiteturas de observabilidade que dependem de dados de telemetria para alertas em tempo real.

Erros comuns na definição de SLIs

O erro mais frequente é monitorar métricas de infraestrutura no lugar de métricas de experiência do usuário — como usar CPU ou uso de memória como proxy de disponibilidade. CPU a 90% pode ser completamente normal para um serviço saudável.

O segundo erro é não excluir eventos inválidos do denominador. Requisições bloqueadas por firewall, bots conhecidos ou tráfego de health check devem ser excluídos para não distorcer o SLI. A referência técnica do Google SRE em sre.google detalha essa distinção com exemplos práticos.

O terceiro erro é definir SLIs para métricas que o time não consegue influenciar — como latência de DNS de terceiros. O SLI deve refletir o que o serviço entrega, não o ambiente externo.

Conclusão

Um SLI bem definido é a fundação de qualquer estratégia de confiabilidade orientada ao usuário. A escolha da métrica certa para cada tipo de serviço — disponibilidade para APIs HTTP, frescor para filas, completude para pipelines — é o que distingue um sistema de alertas que gera ruído de um sistema que detecta impacto real.

O catálogo apresentado aqui é um ponto de partida. O próximo passo é converter cada SLI em um SLO com threshold e janela de tempo definidos, e conectá-lo a um error budget que guia as decisões operacionais do time. Para estruturar sua estratégia de SLIs e SRE com suporte especializado, fale com nossos especialistas.