O Service Mesh (ASM) oferece monitoramento e alertas integrados com base em objetivos de nível de serviço (SLOs). O monitoramento de SLO acompanha o desempenho das chamadas entre os serviços da aplicação — incluindo latência e taxa de erros — e aciona alertas quando a confiabilidade diminui.
Conceitos principais
Indicador de nível de serviço (SLI) Métrica quantitativa que mede a integridade do serviço. Exemplos incluem a porcentagem de solicitações com resposta bem-sucedida ou a porcentagem de solicitações atendidas dentro de um limiar de latência.
Objetivo de nível de serviço (SLO) Valor ou intervalo alvo para um SLI durante um período definido. Um SLO é composto por um ou mais SLIs e serve como referência compartilhada de confiabilidade para desenvolvedores de aplicações, operadores de plataforma e equipes de operações e manutenção, permitindo medir e melhorar continuamente a qualidade do serviço.
Error budget Quantidade aceitável de falhas ou dívida técnica derivada da meta do SLO. Calculado como 100% - SLO target. Um SLO de 99,9% resulta em um error budget de 0,1%.
Burn rate Velocidade de consumo do error budget. Um burn rate igual a 1 indica que o error budget será totalmente consumido ao final do período de conformidade. Valores maiores sinalizam esgotamento mais rápido e problemas mais graves.
Tipos de SLI
O ASM suporta dois tipos de SLI:
|
Tipo de SLI |
O que é medido |
Tipo de plug-in |
Condição de falha |
|
Disponibilidade do serviço |
O serviço respondeu com sucesso? |
availability |
Código de status HTTP 429 ou 5XX (qualquer código iniciado com 5) |
|
Latência |
Quanto tempo o serviço levou para responder? |
latency |
Tempo de resposta excede a latência máxima especificada |
Defina objetivos realistas
Um SLO composto por múltiplos SLIs descreve a integridade do serviço com mais precisão do que um único SLI isoladamente.
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 defina objetivos, concentre-se na percepção real dos usuários. Se eles não distinguem entre latências de 200 ms e 600 ms, estabeleça o objetivo de latência em 600 ms. Metas excessivamente rigorosas consomem esforço de engenharia sem melhorar a experiência do usuário.
Cada tipo de serviço exige metas diferentes. Por exemplo:
|
Meta de disponibilidade |
Tempo de inatividade aproximado por ano |
Caso de uso típico |
|
99% |
~3 dias |
Serviços 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 avaliados em relação à meta do SLO. A mesma porcentagem alvo tem implicações muito distintas dependendo desse período:
Disponibilidade de 99% em 1 dia: no máximo ~14 minutos de inatividade contínua (24 horas x 1%)
Disponibilidade de 99% em 30 dias: até ~7 horas de inatividade contínua (30 dias x 1%)
O ASM suporta períodos de conformidade de 7, 14, 28 e 30 dias.
Error budget
O error budget quantifica quanta falta de confiabilidade um serviço pode tolerar e ainda assim cumprir seu SLO:
Error budget = 100% - SLO targetExemplo prático
|
Parâmetro |
Valor |
|
Definição de falha do SLI |
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 cumprir este SLO, o serviço não deve ter mais de 10 solicitações com falha em uma janela de 30 dias.
Use o error budget 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 foi cumprido durante o período de conformidade.
Error budget < 0: O SLO foi violado.
Utilize o error budget restante para decidir quando implantar alterações:
Orçamento quase esgotado: Adie as implantações. O risco de violação do SLO é alto.
Orçamento suficiente no fim do período de conformidade: Implante com segurança. Mesmo que a nova versão introduza alguns erros, é improvável que o SLO seja violado.
Burn rate
O burn rate mede a velocidade de consumo do error budget em relação ao período de conformidade. Trata-se da razão entre a taxa de erro atual e o error budget:
Burn rate = Error rate / (1 - SLO target)Um burn rate igual a 1 significa que o error budget será totalmente consumido exatamente no final do período de conformidade. Já um burn rate de 2 indica que o orçamento acabará na metade do tempo.
Exemplos de burn rate (período de conformidade de 30 dias)
|
Burn rate |
Orçamento consumido por período de conformidade |
Tempo para esgotar o orçamento |
|
1 |
100% |
30 dias |
|
2 |
200% |
15 dias |
|
60 |
6.000% |
12 horas |
Valores elevados de burn rate indicam falhas mais graves e acionam alertas de maior severidade.
Regras de alerta
As regras de alerta notificam você quando o error budget é consumido rapidamente demais, permitindo uma resposta antes que ocorra uma violação do SLO.
O ASM utiliza alertas de burn rate com múltiplas janelas, combinando uma janela longa para detecção com uma janela curta para resolução automática. Essa abordagem identifica tanto picos repentinos quanto problemas de evolução lenta, além de limpar os alertas prontamente após a recuperação.
Funcionamento dos alertas de múltiplas janelas
Cada regra de alerta defina duas janelas:
Janela longa: Detecta quando o burn rate excede o limiar durante um período maior, acionando o alerta.
Janela curta (1/12 da janela longa): Verifica se a taxa elevada de erros persiste. Quando a taxa cai abaixo do limiar na janela curta, o alerta é encerrado automaticamente.
Esse design evita dois problemas comuns:
Não detectar um aumento gradual que esgota o error budget ao longo de vários dias
Manter alertas ativos por muito tempo após a resolução da falha
Níveis de severidade de alerta (exemplo de SLO de 30 dias)
|
Severidade |
Condição |
Burn rate |
Resposta |
|
Nível de page |
2% do error budget consumido em 1 hora |
14,4x |
Ação imediata necessária |
|
Nível de page |
5% do error budget consumido em 6 horas |
6x |
Ação imediata necessária |
|
Nível de ticket |
10% do error budget consumido em 1 dia |
3x |
Acompanhar via ticket |
|
Nível de ticket |
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 falha seja corrigida no terceiro dia:
Com janela curta: O alerta é encerrado cerca de 6 horas após a correção, pois a janela curta detecta a recuperação.
Sem janela curta: O alerta persiste por mais 3 dias, mesmo com a falha já resolvida.