O Service Mesh (ASM) oferece monitoramento e alertas integrados com base em service level objectives (SLOs). O monitoramento de SLO acompanha o desempenho das chamadas entre application services — incluindo latência e taxa de erros — e aciona alertas quando a confiabilidade cai.
Conceitos principais
Service level indicator (SLI) Uma métrica quantitativa que mede a integridade do service. Por exemplo: a porcentagem de solicitações com resposta bem-sucedida ou a porcentagem de solicitações atendidas dentro de um limiar de latência.
Service level objective (SLO) Um valor ou intervalo alvo para um SLI durante um período definido. Um SLO consiste em um ou mais SLIs e serve como uma referência compartilhada de confiabilidade para desenvolvedores de aplicativos, operadores de plataforma e equipe de O&M para medir e melhorar continuamente a qualidade do service.
Error budget A quantidade permitida de falhas ou dívida técnica derivada da meta do SLO. É calculado como 100% - SLO target. Um SLO de 99,9% gera um error budget de 0,1%.
Burn rate A velocidade de consumo do error budget. Um burn rate de 1 significa que o error budget se esgotará totalmente no final do período de conformidade. Burn rates mais altos indicam um esgotamento mais rápido e problemas mais graves.
Tipos de SLI
O ASM oferece suporte a dois tipos de SLI:
|
Tipo de SLI |
O que mede |
Tipo de plug-in |
Condição de falha |
|
Service availability |
O service respondeu com sucesso? |
availability |
O código de status http é 429 ou 5XX (qualquer código iniciado em 5) |
|
Latência |
Qual foi o tempo de resposta do service? |
latency |
O tempo de resposta excede a latência máxima especificada |
Defina objetivos realistas
Um SLO composto por múltiplos SLIs descreve a integridade do service com mais precisão do que um único SLI.
Exemplos de SLOs:
Média de consultas por segundo (QPS) > 100.000/s
Latência de 99% das solicitações < 500 ms
Largura de banda por minuto para 99% das solicitações > 200 MB/s
Ao definir objetivos, foque naquilo que os usuários realmente percebem. Se seus usuários não conseguem distinguir entre uma latência de 200 ms e 600 ms, defina o objetivo de latência como 600 ms — uma meta mais rígida consome esforço de engenharia sem melhorar a experiência do usuário.
Diferentes services exigem diferentes metas. Por exemplo:
|
Meta de disponibilidade |
Tempo de inatividade aproximado por ano |
Caso de uso típico |
|
99% |
~3 dias |
Services não críticos |
|
99.999% |
~5 minutos |
Sistemas de missão crítica |
Período de conformidade
O período de conformidade define a janela de tempo em que os SLIs são medidos em relação à meta do SLO. A mesma porcentagem de meta tem implicações muito diferentes dependendo do período de conformidade:
99% de disponibilidade em 1 dia: no máximo ~14 minutos de inatividade contínua (24 horas x 1%)
99% de disponibilidade em 30 dias: até ~7 horas de inatividade contínua (30 dias x 1%)
O ASM oferece suporte a períodos de conformidade de 7, 14, 28 e 30 dias.
Error budget
O error budget quantifica o nível de instabilidade que um service pode tolerar enquanto ainda atende ao seu SLO:
Error budget = 100% - SLO targetExemplo prático
|
Parâmetro |
Valor |
|
Definição de falha de SLI |
O código de status http é 429 ou 5XX |
|
Período de conformidade |
30 dias |
|
Meta do SLO |
99,9% |
|
Error budget |
0,1% (100% - 99,9%) |
|
Total de solicitações em 30 dias |
10.000 |
|
Solicitações com erro permitidas |
10 (10.000 x 0,1%) |
Para atender a este SLO, o service não pode ter mais de 10 solicitações com falha em uma janela de 30 dias.
Use error budgets para orientar decisões
O error budget é atualizado em uma janela móvel com a mesma duração do período de conformidade:
Error budget >= 0: O SLO é atendido durante o período de conformidade.
Error budget < 0: O SLO é violado.
Use o error budget restante para decidir quando implantar alterações:
Budget quase esgotado: Adie as implantações. O risco de violação do SLO é alto.
Budget suficiente no final do período de conformidade: Implante com confiança. Mesmo que a nova versão introduza alguns erros, a violação do SLO é improvável.
Burn rate
O burn rate mede a velocidade de consumo do error budget em relação ao período de conformidade. É a proporção entre a taxa de erro atual e o error budget:
Burn rate = Error rate / (1 - SLO target)Um burn rate de 1 significa que o error budget se esgotará totalmente exatamente no final do período de conformidade. Um burn rate de 2 significa que o budget se esgotará na metade do tempo.
Exemplos de burn rate (período de conformidade de 30 dias)
|
Burn rate |
Budget consumido por período de conformidade |
Tempo para esgotar o budget |
|
1 |
100% |
30 dias |
|
2 |
200% |
15 dias |
|
60 |
6,000% |
12 horas |
Burn rates mais altos indicam falhas mais graves e acionam alertas de maior severidade.
Regras de alerta
As regras de alerta enviam notificações quando o error budget é consumido muito rapidamente, para permitir uma resposta antes da violação do SLO.
O ASM usa alertas de burn rate com múltiplas janelas ao combinar uma janela longa para detecção com uma janela curta para resolução automática. Essa abordagem captura tanto picos abruptos quanto problemas de crescimento lento e limpa os alertas rapidamente após a recuperação.
Como funciona o alerta de múltiplas janelas
Cada regra de alerta define duas janelas:
Janela longa: Detecta quando o burn rate excede o limiar durante um período mais longo. Isso aciona o alerta.
Janela curta (1/12 da janela longa): Verifica se a taxa de erro elevada persiste. Quando a taxa de erro cai abaixo do limiar na janela curta, o sistema limpa o alerta automaticamente.
Esse design evita dois problemas comuns:
Deixar de perceber um aumento gradual, o que esgota o error budget ao longo de dias
Manter alertas ativos por muito tempo após a resolução de uma falha
Níveis de severidade de alerta (exemplo de SLO de 30 dias)
|
Severidade |
Condição |
Burn rate |
Resposta |
|
Page-level |
2% do error budget consumido em 1 hora |
14,4x |
Ação imediata necessária |
|
Page-level |
5% do error budget consumido em 6 horas |
6x |
Ação imediata necessária |
|
Ticket-level |
10% do error budget consumido em 1 dia |
3x |
Acompanhar via ticket |
|
Ticket-level |
10% do error budget consumido em 3 dias |
1x (limiar) |
Acompanhar via ticket |
Janela curta na prática
Suponha que a taxa de erro permaneça no dobro do limiar por 3 dias e a correção da falha ocorra no terceiro dia:
Com uma janela curta: O sistema limpa o alerta ~6 horas após a correção, porque a janela curta detecta a recuperação.
Sem uma janela curta: O alerta persiste por mais 3 dias, mesmo com a falha já resolvida.