Exemplos de configuração de Objetivos de Nível de Serviço (SLO)
Exemplo 1: SLO de aplicativo com projeto de latência
Objetivo: Garantir que 90% das chamadas do aplicativo “Robot-shop” tenham uma latência média superior a 100 ms durante um período fixo de uma semana.
A configuração do SLO seria:
Entidade: Aplicativo Robot-shop
- Escopo:
- Limite: Todos os serviços
- Incluir chamadas internas: false
- Incluir chamadas sintéticas: false
- Serviço: Todos os serviços
- Ponto final: Todos os pontos finais
Indicador:
- Plano: Latência
- Tipo: Tempo
- Agregação: média
- Limite: 100 ms
Objetivo:
- Meta SLO: 90%
- Tipo de janela de tempo: Contínua
- Duração da janela de tempo: 1 semana
Cenário : Supondo que o SLO teve 400 minutos ruins durante a janela de tempo SLO de uma semana (400 minutos tiveram latência média > 100 ms) a partir de 04/03/2025 :
O orçamento de erros para este SLO seria calculado da seguinte forma:
- Minutos no período x (1 - porcentagem da meta SLO)
- Total de minutos na janela de tempo: 24 × 60 × 7 minutos em 1 semana = 10.080 minutos
- Porcentagem alvo SLO: 90% ( 0.9 )
- Orçamento de erros: 10080 x (1 - 0.9 ) = 1008 minutos
O status SLO seria calculado da seguinte forma:
- Status SLO = 100% x (total de minutos na janela de tempo - minutos ruins na janela de tempo) / total de minutos na janela de tempo
- 100% x (10.080 minutos totais - 400 minutos ruins) / 10.080 minutos totais = 96.03 %
Exemplo 2: SLO do site com plano de disponibilidade baseado em eventos
Objetivo: Garantir que as solicitações HTTP para a página do carrinho de compras ( cart.html ) do site de demonstração possam atingir 95% de disponibilidade durante um período fixo de 4 dias, com início em 1º de março de 2025.
A configuração do SLO seria:
- Entidade: Site de demonstração
- Beacon: solicitações HTTP
- Filtro personalizado: Localização > Nome da página = Carrinho
- Indicador:
- Plano: Disponibilidade
- Tipo: Contagem de eventos (contagem total de chamadas corretas vs. chamadas incorretas)
- Objetivo:
- Meta SLO: 95%
- Tipo de janela de tempo: Fixa
- Duração da janela de tempo: 4 dias
- Início: 01/03/2025, 0:00
Cenário : Supondo que haja 234 solicitações bem-sucedidas HTTP e 11 solicitações com falha HTTP durante o período de tempo SLO a partir de 1º de março de 2025 :
O orçamento de erros para este SLO seria calculado da seguinte forma:
- Evento:
- Contagem de eventos positivos: 234 beacons
- Contagem de eventos ruins: 11 beacons
- Contagem total de eventos: 234 + 11 = 245 beacons
- Porcentagem alvo SLO: 95% ( 0.95 )
- Orçamento de erros: 245 x (1 - 0.95 ) = 12 beacons
- Orçamento de erros restante: 12 - 11 = 1 sinalizador
- Porcentagem restante do orçamento para erros: 100% * (12 - 11) / 12 = 8.33 %
O status SLO seria calculado da seguinte forma:
- Status SLO = 100% x contagem total de eventos positivos na janela de tempo / contagem total de eventos na janela de tempo
- 100% x 234 balizas / 245 balizas = 95.5 %
Exemplo 3: Monitoramento sintético com modelo de tráfego
Objetivo: Garantir que três testes de monitoramento sintético (carrinho de compras, página inicial e página de lista de produtos) sejam executados 15 vezes por minuto, com uma meta de 99% de regularidade, durante um período fixo de uma semana, com início em 18/03/2025.
A configuração do SLO seria:
Entidades:
- teste do carrinho de compras
- teste da página inicial
- página de teste da lista de produtos
Indicador:
- Plano: Tráfego
- Limite: > 15 resultados por minuto
Objetivo:
- Meta SLO: 99%
- Tipo de janela de tempo: Fixa
- Duração da janela de tempo: 1 semana
- Início: 18/03/2025, 0:00
Cenário : Supondo que o SLO tivesse 21 minutos em que os testes sintéticos fossem executados menos de 15 vezes durante a janela de tempo do SLO a partir de 18/03/2025 :
O orçamento de erros para este SLO seria calculado da seguinte forma:
- Minutos no período x (1 - Porcentagem da meta SLO)
- Total de minutos: 24 × 60 × 7 minutos em 1 semana = 10.080 minutos
- Meta SLO: 99% ( 0.99 )
- Orçamento de erros: 10080 x (1 - 0.99 ) = 101 minutos
- Orçamento de erros restante: 101 - 21 = 80
- Porcentagem restante do orçamento de erros: 100% * (101 - 21) / 101 = 79.21 %
O status SLO seria calculado da seguinte forma:
- Status SLO = 100% x (total de minutos na janela de tempo - minutos ruins na janela de tempo) / total de minutos na janela de tempo
- 100% x (10.080 minutos totais - 21 minutos ruins) / 10.080 minutos totais = 99.8 %
Exemplo 4: Monitoramento sintético de SLO com disponibilidade baseada em eventos usando filtros de tags
Objetivo: Garantir que os testes simulados do processo de finalização de compra atinjam pelo menos 99% de disponibilidade durante um período fixo de 1 dia.
A configuração do SLO seria:
- Entidade: Sintética
- Escopo:
- Método de seleção: com base em filtros
- Expressão do filtro de tags: synthetic.testName startsWith "checkout"
- Indicador:
- Plano: Disponibilidade
- Tipo: Contagem de eventos (contagem total de resultados positivos versus resultados negativos)
- Evento positivo: call.erroneous = false
- Evento indesejado: call.erroneous = true
- Objetivo:
- Meta SLO: 99%
- Tipo de janela de tempo: Fixa
- Duração da janela de tempo: 1 dia
- Início: 18/01/2026, 0h
Cenário : Suponha que tenham ocorrido 14.850 execuções bem-sucedidas de testes sintéticos e 150 execuções com falha durante o intervalo de tempo do SLO que se inicia em 18/01/2026.
O orçamento de erros para este SLO seria calculado da seguinte forma:
- Evento:
- Total de eventos: 14.850 execuções de testes
- Contagem de eventos indesejáveis: 150 execuções de teste
- Número total de eventos: 14.850 + 150 = 15.000 execuções
- Porcentagem alvo de SLO: 99% ( 0.99 )
- Margem de erro: 15.000 × (1 − 0.99 ) = 150 execuções
- Orçamento de erros restante: 150 − 150 = 0 execuções
- Porcentagem restante do orçamento de erro: 100% × (0 / 150) = 0%
O status SLO seria calculado da seguinte forma:
- Índice de SLO = 100% × número total de eventos positivos / número total de eventos
- 100% × 14.850 / 15.000 = 99%
Exemplo 5: SLO de aplicativo com modelo personalizado
Objetivo: Garantir que 98% das chamadas do aplicativo “Robot-shop” não resultem em um código de status 400 “ HTTP ” (Falha no envio) durante um período contínuo de 1 dia.
A configuração do SLO seria:
Entidade: Aplicativo Robot-shop
- Escopo:
- Limite: Todos os serviços
- Incluir chamadas internas: false
- Incluir chamadas sintéticas: false
- Serviço: Todos os serviços
- Ponto final: Todos os pontos finais
Indicador:
- Plano: Personalizado
- Tipo: Contagem de eventos (contagem total de chamadas corretas vs. chamadas incorretas)
- Filtro adequado: HTTP código de status!= 400
- Filtro incorreto: HTTP código de status = 400
Objetivo:
- Meta SLO: 98%
- Tipo de janela de tempo: Contínua
- Duração da janela de tempo: 1 dia
Cenário : Supondo que o SLO teve 25.000 chamadas boas e 200 chamadas ruins durante o período de um dia do SLO, começando em 10/03/2025 :
O orçamento de erros para este SLO seria calculado da seguinte forma:
- Evento:
- Contagem de eventos válidos: 25.000 chamadas
- Contagem de eventos ruins: 200 chamadas
- Contagem total de eventos: 25.000 + 200 = 25.200 chamadas
- Porcentagem alvo SLO: 98% ( 0.98 )
- Orçamento de erros: 25.200 x (1 - 0.98 ) = 504 chamadas
- Orçamento de erros restante: 504 - 200 = 304 chamadas
- Porcentagem restante do orçamento de erro: 100% * (504 - 200) / 504 = 60.32 %
O status SLO seria calculado da seguinte forma:
- Status SLO = 100% x contagem total de eventos positivos na janela de tempo / contagem total de eventos na janela de tempo
- 100% x 25.000 chamadas / 25.200 chamadas = 99.2 %
Exemplo 6: SLO de aplicativo com modelo de latência baseado em eventos
Objetivo: Garantir que 92% das chamadas do aplicativo “Robot-shop” tenham latência inferior a 100 ms durante um período fixo de duas semanas.
A configuração do SLO seria:
Entidade: Aplicativo Robot-shop
- Escopo:
- Limite: Todos os serviços
- Incluir chamadas internas: false
- Incluir chamadas sintéticas: false
- Serviço: Todos os serviços
- Ponto final: Todos os pontos finais
Indicador:
- Plano: Latência
- Tipo: Contagem de eventos (contagem total de chamadas corretas vs. chamadas incorretas)
- Boa decisão: Latência < 100 ms
- Chamada ruim: Latência >= 100 ms
Objetivo:
- Meta SLO: 92%
- Tipo de janela de tempo: Fixa
- Duração da janela de tempo: 2 semanas
- Início: 10/03/2025, 0:00
Cenário : Supondo que o SLO teve 50.000 chamadas boas e 1.000 chamadas ruins durante o período de duas semanas do SLO, começando em 10/03/2025 :
O orçamento de erros para este SLO seria calculado da seguinte forma:
- Evento:
- Contagem de eventos válidos: 50.000 chamadas
- Contagem de eventos ruins: 1000 chamadas
- Contagem total de eventos: 50.000 + 1.000 = 51.000 chamadas
- Porcentagem alvo SLO: 92% ( 0.92 )
- Orçamento de erros: 51.000 x (1 - 0.92 ) = 4.080 chamadas
- Orçamento de erros restante: 4080 - 1000 = 3080 chamadas
- Porcentagem restante do orçamento de erros: 100% * (4080 - 1000) / 4080 = 75.49 %
O status SLO seria calculado da seguinte forma:
- Status SLO = 100% x contagem total de eventos positivos na janela de tempo / contagem total de eventos na janela de tempo
- 100% x 50.000 chamadas / 51.000 chamadas = 98.04 %
Exemplo 7: SLO do site com modelo de disponibilidade baseado no tempo
Objetivo: Garantir que as solicitações HTTP ao site de demonstração pudessem atingir 92% de disponibilidade com menos de 5% de taxa de erro durante um período contínuo de três dias.
A configuração do SLO seria:
- Entidade: Site de demonstração
- Beacon: solicitações HTTP
- Indicador:
- Plano: Disponibilidade
- Tipo: Tempo
- Limite da taxa de erro: 5%
- Objetivo:
- Meta SLO: 92%
- Tipo de janela de tempo: Contínua
- Duração da janela de tempo: 3 dias
Cenário : Supondo que o SLO teve 200 minutos ruins durante o período de 3 dias do SLO (200 minutos tiveram uma taxa de erro média superior a 5%) a partir de 05/03/2025 :
O orçamento de erros para este SLO seria calculado da seguinte forma:
- Minutos no período x (1 - porcentagem da meta SLO)
- Total de minutos na janela de tempo: 24 × 60 × 3 minutos em 3 dias = 4320 minutos
- Porcentagem alvo SLO: 92% ( 0.92 )
- Orçamento de erro: 4320 x (1 - 0.92 ) = 346 minutos
O status SLO seria calculado da seguinte forma:
- Status SLO = 100% x (total de minutos na janela de tempo - minutos ruins na janela de tempo) / total de minutos na janela de tempo
- 100% x (4320 minutos totais - 200 minutos ruins) / 4320 minutos totais = 95.37 %
Exemplo 8: SLO de infraestrutura com modelo de saturação baseado no tempo (CPU)
Objetivo: Garantir que a utilização da CPU nos hosts de produção permaneça abaixo de 75% durante 99% do tempo em um período contínuo de 7 dias.
- Entidade: Infraestrutura
- Tipo de infraestrutura: Host
- Expressão do filtro de etiquetas:
availabilityZone = "us-east-1"
- Indicador:
- Plano: Saturação
- Tipo: Tempo
- Métrica:
cpu.used - Agregação: Média
- Operador: >=
- Limite: 75%
- Objetivo:
- Meta SLO: 99%
- Tipo de janela de tempo: Contínua
- Duração da janela de tempo: 7 dias
- Minutos no período x (1 - porcentagem da meta SLO)
- Total de minutos na janela de tempo: 24 × 60 × 7 minutos em 1 semana = 10.080 minutos
- Porcentagem alvo de SLO: 99% ( 0.99 )
- Orçamento de erros: 10080 x (1 - 0.99 ) = 101 minutos
- Status SLO = 100% x (total de minutos na janela de tempo - minutos ruins na janela de tempo) / total de minutos na janela de tempo
- 100% x (10.080 minutos totais - 25 minutos ruins) / 10.080 minutos totais = 99.75 %
Exemplo 9: SLO de infraestrutura com modelo de saturação baseado em eventos (Memória)
Objetivo: Garantir que a utilização da memória nos servidores de banco de dados permaneça abaixo de 85% para 99.9 % dos instantâneos métricos durante um período contínuo de 1 dia.
- Entidade: Infraestrutura
- Tipo de infraestrutura: Host
- Expressão do filtro de etiquetas:
host.fqdn contains "company-name" AND availabilityZone = "us-east-1"
- Indicador:
- Plano: Saturação
- Tipo: Contagem de eventos (contagem total de instantâneos de métricas válidos vs. instantâneos de métricas inválidos)
- Métrica:
memory.used - Operador: >=
- Limite: 85%
- Objetivo:
- Meta SLO: 99.9 %
- Tipo de janela de tempo: Contínua
- Duração da janela de tempo: 1 dia
- Evento:
- Eventos positivos: 8.640 instantâneos
- Contagem de eventos ruins: 5 instantâneos
- Contagem total de eventos: 8.640 + 5 = 8.645 instantâneos
- Porcentagem alvo SLO: 99.9 % ( 0.999 )
- Orçamento de erros: 8.645 x (1 - 0.999 ) = 8.65 instantâneos (arredondado para 9)
- Orçamento de erros restante: 9 - 5 = 4 instantâneos
- Porcentagem restante do orçamento de erros: 100% * (9 - 5) / 9 = 44.44 %
- Status SLO = 100% x contagem total de eventos positivos na janela de tempo / contagem total de eventos na janela de tempo
- 100% x 8.640 instantâneos / 8.645 instantâneos = 99.94 %
Exemplo 10: SLO de infraestrutura com modelo personalizado para um cluster d Kubernetes
Objetivo: Garantir que o cluster de produção Kubernetes mantenha pelo menos 6 nós disponíveis 99.9 % do tempo durante um período contínuo de 7 dias.
- Entidade: Infraestrutura
- Tipo de infraestrutura: Cluster Kubernetes
- Expressão do filtro de etiquetas:
kubernetes.cluster.name = "prod-cluster"
- Indicador:
- Plano: Personalizado
- Tipo: Contagem de eventos (contagem total de instantâneos de métricas válidos vs. instantâneos de métricas inválidos)
- Eventos positivos: nodes.count >= 6
- Eventos ruins: nodes.count < 6
- Objetivo:
- Meta SLO: 99.9 %
- Tipo de janela de tempo: Contínua
- Duração da janela de tempo: 7 dias
- Evento:
- Contagem de eventos positivos: 60.400 instantâneos
- Contagem de eventos ruins: 80 instantâneos
- Contagem total de eventos: 60.400 + 80 = 60.480 instantâneos
- Porcentagem alvo SLO: 99.9 % ( 0.999 )
- Orçamento de erros: 60.480 x (1 - 0.999 ) = 60.48 instantâneos (arredondado para 60)
- Orçamento de erros restante: 60 - 80 = -20 instantâneos (excedido)
- Porcentagem restante do orçamento para erros: 100% x (-20 / 60) = -33.33 % (excesso de gastos)
- Status SLO = 100% x contagem total de eventos positivos na janela de tempo / contagem total de eventos na janela de tempo
- 100% x 60.400 instantâneos / 60.480 instantâneos = 99.87 %
Exemplo 11: Comportamento do SLO com vinculação de fuso horário
Objetivo: Garantir que o intervalo de tempo do SLO corresponda ao horário do calendário e permaneça o mesmo todos os dias, mesmo durante as mudanças do horário de verão, para que os relatórios sejam precisos e consistentes. Certifique-se de que o cálculo do SLO esteja vinculado a um fuso horário específico, pois a mudança para o horário de verão afeta o intervalo de tempo de acordo com o fuso horário configurado.
- Entidade: Aplicativo Robot-shop
- Escopo:
- Limite: Todos os serviços
- Incluir chamadas internas: false
- Incluir chamadas sintéticas: false
- Serviço: Todos os serviços
- Ponto final: Todos os pontos finais
- Escopo:
- Indicador:
- Plano: Latência
- Tipo: Tempo
- Agregação: média
- Limite: 100 ms
- Objetivo:
- Meta SLO: 90%
- Tipo de janela de tempo: Fixa
- Duração da janela de tempo: 3 dias
- Zona horária vinculada: Ativar
- Fuso horário: Europa/Berlim
Exemplo 12: SLO associado a uma equipe
Objetivo: Atribuir o SLO a uma ou mais equipes associadas ao usuário. Essas associações de equipes são então utilizadas para aplicar restrições de acesso.
Entidade: Aplicativo Robot-shop
- Escopo:
- Limite: Todos os serviços
- Incluir chamadas internas: false
- Incluir chamadas sintéticas: false
- Serviço: Todos os serviços
- Ponto final: Todos os pontos finais
- Escopo:
Indicador:
- Plano: Latência
- Tipo: Tempo
- Agregação: média
- Limite: 100 ms
Objetivo:
- Meta SLO: 90%
- Tipo de janela de tempo: Contínua
- Duração da janela de tempo: 1 semana
Detalhes:
- Nome: Exemplo de SLO
- Tags (opcional): Tag de amostra
- Equipes: Equipe 1, Equipe 2
Exemplo 13: SLO mensal criado no meio do mês
Objetivo: Garantir que 99% das chamadas para o aplicativo “Serviço de Pagamento” tenham uma latência média inferior a 200 ms ao longo de períodos de um mês civil, com o SLO criado em 15 de janeiro.
A configuração do SLO seria:
- Entidade: Aplicação de serviço de pagamento
- Escopo:
- Limite: Chamadas recebidas
- Incluir chamadas internas: false
- Incluir chamadas sintéticas: false
- Serviço: Todos os serviços
- Ponto final: Todos os pontos finais
- Escopo:
- Indicador:
- Plano: Latência
- Tipo: Tempo
- Agregação: média
- Limite: 200 ms
- Objetivo:
- Meta SLO: 99%
- Tipo de janela de tempo: Fixa
- Duração da janela de tempo: 1 mês civil
- Zona horária vinculada: Ativar
- Fuso horário: América/Nova York
- Início: 15/01/2025, 00:00
Cenário : O SLO é criado em 15 de janeiro de 2025. Os SLOs do mês civil se alinham com os limites do mês, criando um primeiro período parcial quando criados no meio do mês.
- Duração: 17 dias (de 15 a 31 de janeiro)
- Total de minutos: 17 × 24 × 60 = 24.480 minutos
- Orçamento de erros: 24.480 × (1 - 0.99 ) = 245 minutos
- Minutos ruins registrados: 30 minutos
- Status SLO: 100% × (24.480 - 30) / 24.480 = 99.88 %
- Orçamento de erros restante: 245 - 30 = 215 minutos
- Duração: 28 dias (mês civil completo)
- Total de minutos: 28 × 24 × 60 = 40.320 minutos
- Orçamento de erro: 40.320 × (1 - 0.99 ) = 403 minutos
- Minutos ruins registrados: 50 minutos
- Status SLO: 100% × (40.320 - 50) / 40.320 = 99.88 %
- Orçamento de erros restante: 403 - 50 = 353 minutos
- Duração: 31 dias (mês civil completo)
- Total de minutos: 31 × 24 × 60 = 44.640 minutos
- Orçamento de erro: 44.640 × (1 - 0.99 ) = 446 minutos
Exemplo 14: SLO mensal criado no primeiro dia do mês
Objetivo: Garantir que 95% das solicitações HTTP ao “site de comércio eletrônico” alcancem disponibilidade ao longo de períodos mensais, com o SLO criado em 1º de março.
A configuração do SLO seria:
- Entidade: Site de comércio eletrônico
- Beacon: solicitações HTTP
- Filtro personalizado: Nenhum
- Indicador:
- Plano: Disponibilidade
- Tipo: Tempo
- Limite da taxa de erro: 5%
- Objetivo:
- Meta SLO: 95%
- Tipo de janela de tempo: Fixa
- Duração da janela de tempo: 1 mês civil
- Zona horária vinculada: Ativar
- Fuso horário: UTC
- Início: 01/03/2025, 00:00
Cenário : O SLO é criado em 1º de março de 2025 (o primeiro dia do mês). Todos os períodos de medição são meses civis completos.
- Duração: 31 dias (mês civil completo)
- Total de minutos: 31 × 24 × 60 = 44.640 minutos
- Orçamento de erros: 44.640 × (1 - 0.95 ) = 2.232 minutos
- Minutos ruins registrados: 400 minutos
- Status SLO: 100% × (44.640 - 400) / 44.640 = 99.10 %
- Orçamento de erros restante: 2.232 - 400 = 1.832 minutos
- Duração: 30 dias (mês civil completo)
- Total de minutos: 30 × 24 × 60 = 43.200 minutos
- Orçamento de erros: 43.200 × (1 - 0.95 ) = 2.160 minutos
- Minutos ruins registrados: 350 minutos
- Status SLO: 100% × (43.200 - 350) / 43.200 = 99.19 %
- Orçamento de erros restante: 2.160 - 350 = 1.810 minutos
Exemplo 15: SLO de aplicativo móvel com modelo de latência baseado em eventos (latência de HTTP s para Android)
Este exemplo demonstra como configurar um SLO para um aplicativo móvel que utiliza um modelo de latência baseado em eventos para garantir que 99% das solicitações de ` HTTP ` enviadas ao serviço de carrinho a partir de dispositivos Android apresentem latência inferior a 200 ms durante um período fixo de 1 dia.
Configuração
O SLO está configurado com as seguintes opções:
- Entidade: Aplicativo móvel
- Método de seleção: com base em filtros
- Expressão do filtro de tags:
mobileBeacon.platform EQUALS "Android"
- Indicador:
- Plano: Latência
- Tipo de beacon: solicitações de HTTP
- Filtro personalizado do Beacon:
mobileBeacon.http.url EQUALS "https://rs-cart/add-cart" - Métrica:
httpLatency - Tipo: Contagem de eventos (contagem total de beacons válidos versus beacons inválidos)
- Limite: 200 ms
- Operador:
>
- Objetivo:
- Meta SLO: 99%
- Tipo de janela de tempo: Fixa
- Duração da janela de tempo: 1 dia
- Fuso horário: UTC
- Início: 18/02/2026 00:00
Cenário
Durante o intervalo de tempo SLO com início em 18/02/2026, há 19.800 solicitações do tipo “ HTTP ” com latência inferior a 200 ms e 200 solicitações do tipo “ HTTP ” com latência maior ou igual a 200 ms.
Cálculo da margem de erro
A margem de erro é calculada da seguinte forma:
- Número de eventos válidos: 19.800 beacons
- Eventos indesejáveis contabilizados: 200 beacons
- Número total de eventos: 19.800 + 200 = 20.000 beacons
- Porcentagem alvo de SLO: 99% ( 0.99 )
- Orçamento de erro: 20.000 × (1 - 0.99 ) = 200 balizas
- Saldo restante do orçamento de erros: 200 - 200 = 0 balizas
- Porcentagem restante do orçamento de erro: 100% × (0 / 200) = 0%
Cálculo do status do SLO
O status do SLO é calculado da seguinte forma:
Status do SLO = 100% × número total de eventos válidos na janela de tempo / número total de eventos na janela de tempo
100% × 19.800 beacons / 20.000 beacons = 99%
Exemplo 16: SLO de aplicativo móvel com modelo de disponibilidade baseado no tempo (sessões afetadas por falhas)
Este exemplo demonstra como configurar um SLO para um aplicativo móvel que utiliza um modelo de disponibilidade baseado em tempo para garantir que o número de sessões afetadas por falhas no aplicativo móvel Retail permaneça abaixo de 15 por minuto em 99% do tempo, durante um período fixo de 1 mês civil.
Configuração
O SLO está configurado com as seguintes opções:
- Entidade: Aplicativo móvel
- Método de seleção: aplicativos móveis individuais
- Aplicativo móvel: Aplicativo móvel para o varejo
- Indicador:
- Plano: Disponibilidade
- Tipo de sinal: Colisão
- Métrica:
crashAffectedSessionCount - Tipo: Baseado no tempo
- Agregação: SUM
- Limite: 15
- Operador:
>
- Objetivo:
- Meta SLO: 99%
- Tipo de janela de tempo: Fixa
- Duração da janela de tempo: 1 mês civil
- Fuso horário: Europe/Dublin
- Início: 01/02/2026 00:00
Cenário
Durante o intervalo de tempo do SLO com início em 01/02/2026, o SLO registrou 120 minutos com desempenho insatisfatório ao longo do mês civil, o que significa que, nesses 120 minutos, o número de sessões afetadas por falhas foi superior a 15.
Cálculo da margem de erro
A margem de erro é calculada como o número de minutos no período multiplicado por (1 - porcentagem-alvo do SLO):
- Total de minutos no intervalo de tempo: 28 × 24 × 60 = 40.320 minutos (fevereiro)
- Porcentagem alvo de SLO: 99% ( 0.99 )
- Orçamento de erro: 40.320 × (1 - 0.99 ) = 403 minutos
- Orçamento de erro restante: 403 - 120 = 283 minutos
- Porcentagem restante do orçamento de erro: 100% × (283 / 403) = 70.22 %
Cálculo do status do SLO
O status do SLO é calculado da seguinte forma:
Status do SLO = 100% × (total de minutos na janela de tempo - minutos com falha na janela de tempo) / total de minutos na janela de tempo
100% × (40.320 minutos no total - 120 minutos ruins) / 40.320 minutos no total = 99.70 %
Exemplo 17: SLO de aplicativo móvel com modelo personalizado (solicitações rápidas de HTTP e transições de tela suaves)
Este exemplo demonstra como configurar um SLO para um aplicativo móvel que utiliza um modelo personalizado (avançado) para garantir que 99% das interações dos usuários no aplicativo móvel de comércio eletrônico tenham respostas rápidas HTTP API (menos de 500 ms) e transições de tela suaves (menos de 300 ms) durante um período fixo de 1 mês civil.
Configuração
O SLO está configurado com as seguintes opções:
- Entidade: Aplicativo móvel
- Método de seleção: aplicativos móveis individuais
- Aplicativos móveis: aplicativo móvel de comércio eletrônico, aplicativo móvel de compras
- Indicador:
- Modelo: Personalizado (Avançado)
- Tipo: Contagem de eventos (contagem total de beacons válidos versus beacons inválidos)
- Eventos positivos:
- Tipo de beacon: solicitações de HTTP
- Métrica:
httpLatency - Limite: 500 ms
- Operador:
<
- Eventos ruins:
- Tipo de baliza: Ver alterações
- Métrica:
viewChangeDuration - Limite: 300 ms
- Operador:
>
- Objetivo:
- Meta SLO: 99%
- Tipo de janela de tempo: Fixa
- Duração da janela de tempo: 1 mês civil
- Fuso horário: UTC
- Início: 01/02/2026 00:00
Cenário
Durante o intervalo de tempo do SLO com início em 01/02/2026, há 85.000 solicitações de “ HTTP ” que atendem aos critérios de qualidade (latência inferior a 500 ms) e 1.500 alterações de visualização classificadas como inadequadas (viewChangeDuration latência superior a 300 ms).
Cálculo da margem de erro
A margem de erro é calculada da seguinte forma:
- Eventos válidos: 85.000 beacons
- Número de eventos indesejáveis: 1.500 beacons
- Contagem total de eventos: 85.000 + 1.500 = 86.500 beacons
- Porcentagem alvo de SLO: 99% ( 0.99 )
- Orçamento de erro: 86.500 × (1 - 0.99 ) = 865 balizas
- Orçamento de erro restante: 865 - 1.500 = -635 beacons (ultrapassado)
- Porcentagem restante do orçamento para erros: 100% × (-635 / 865) = -73.41 % (orçamento excedido)
Cálculo do status do SLO
O status do SLO é calculado da seguinte forma:
Status do SLO = 100% × número total de eventos válidos na janela de tempo / número total de eventos na janela de tempo
100% × 85.000 beacons / 86.500 beacons = 98.27 %
Comportamento personalizado do blueprint
Este modelo personalizado demonstra a flexibilidade do monitoramento da experiência do usuário em diferentes tipos de interação. Eventos positivos são definidos com base em respostas rápidas HTTP API (httpLatency menos de 500 ms a partir dos beacons de solicitação HTTP ), enquanto eventos negativos são transições lentas de visualização (viewChangeDuration mais de 300 ms a partir dos beacons de mudança de visualização). Essa abordagem monitora simultaneamente tanto o desempenho do backend API quanto a fluidez da navegação no frontend, utilizando métricas de diferentes tipos de beacons, o que não pode ser alcançado com um único modelo padrão. Os eventos que não se enquadram nem nos critérios “bom” nem nos critérios “ruim” são excluídos do cálculo do SLO.
Exemplos de configuração de alertas inteligentes para níveis de serviço
Exemplo 1: Alerta inteligente de níveis de serviço para monitorar o status de um SLO
Objetivo: Alertar e levantar uma questão se o status da configuração SLO de confiabilidade da máquina de venda automática for inferior a 90%.
A configuração do alerta inteligente de níveis de serviço seria:
Rule:
Alert Type: Service Levels Objective
Metric: Status
Threshold:
Operator: <
value: 0.90
SLOs: Vending Machine Reliability
Time Threshold:
Expiry: 5 Minutes
Time window: 10 Minutes
Assim que a configuração do Smart Alert estiver definida, o sistema começará a monitorar o status da configuração do SLO de Confiabilidade da Máquina de Venda Automática.
Cenário: Monitoramento e acionamento de eventos
SLO cai abaixo do limite
- Suponha que o SLO de confiabilidade da máquina de venda automática caia para 89%, abaixo do limite definido de 90%.
- Com o limite de tempo definido para 10 minutos, o sistema aguardará todo o intervalo de 10 minutos antes de tomar qualquer ação.
- Se o SLO permanecer abaixo de 90% após 10 minutos, o sistema aciona um evento, levantando uma questão.
SLO retorna acima do limite
- Se, após algum tempo, o status do SLO se recuperar e subir acima de 90%, o sistema continuará monitorando.
- No entanto, se o status permanecer acima de 90%, o sistema aguardará o prazo de expiração de 5 minutos.
- Se o SLO permanecer acima de 90% durante os 5 minutos completos, o evento será automaticamente encerrado.
Exemplo 2: Alerta inteligente de níveis de serviço para monitorar o limite de erros de um SLO
Objetivo: Alertar e levantar uma questão se a porcentagem de consumo do orçamento de erros da configuração SLO de confiabilidade da máquina de venda automática for superior a 50%.
A configuração do alerta inteligente de níveis de serviço é:
Rule:
Alert Type: Error Budget
Metric: Burned Percentage
Threshold:
Operator: >
value: 0.50
SLOs: Vending Machine Reliability
Time Threshold:
Expiry: 5 Minutes
Time window: 10 Minutes
Assim que a configuração do alerta inteligente estiver definida, o sistema começará a monitorar a porcentagem de consumo da margem de erros da configuração do SLO de Confiabilidade da Máquina de Venda Automática.
Cenário: Monitoramento e acionamento de eventos
O consumo do orçamento de erros excede 50%
- Suponha que o consumo do orçamento de erros exceda 50%.
- Com o limite de tempo definido para 10 minutos, o sistema aguardará o período completo de 10 minutos antes de tomar qualquer ação.
- Se o consumo do orçamento de erros permanecer acima de 50% após 10 minutos, o sistema aciona um evento, levantando uma questão.
O consumo do orçamento de erros cai abaixo de 50%
- Se, após algum tempo, o consumo do orçamento de erros cair novamente abaixo de 50%, o sistema continuará monitorando.
- Se o consumo do orçamento de erros permanecer abaixo de 50%, o sistema aguardará o prazo de expiração de 5 minutos.
- Se o consumo do orçamento de erros permanecer abaixo de 50% durante os 5 minutos completos, o evento será automaticamente encerrado.
Cálculo de alertas inteligentes sobre a taxa de consumo dos níveis de serviço
A taxa de queima é calculada usando a fórmula:
Taxa de queima = (Orçamento de erros consumido * Janela de tempo SLO) / Janela de alerta
- Por exemplo:
- Suponha que o orçamento de erros consumido nas últimas 12 horas seja de 70% e que a janela de tempo do SLO para o SLO de confiabilidade da máquina de venda automática seja de 1 dia (24 horas).
- A taxa de queima nas últimas 12 horas seria: ( 0.70 * 24) / 12 = 1.4
- Da mesma forma, se o orçamento de erros consumido nas últimas 2 horas for de 20%
- A taxa de queima nas últimas 2 horas seria: ( 0.20 * 24) / 2 = 2.4
Exemplo 3 - Alerta inteligente para monitorar a taxa de queima de um SLO com uma única janela de alerta e limite
Objetivo: Alertar e levantar uma questão se a taxa de queima da configuração SLO de confiabilidade da máquina de venda automática for superior a 1 nas últimas 12 horas.
A configuração do alerta inteligente de níveis de serviço deve ser:
Rule:
Alert Type: Error Budget
Metric: Burn Rate V2
Burn Rate Config:
[
Alert Window Type: SINGLE
Duration: 12 Hours
Duration Unit Type: Hour
Threshold:
Operator: >
Value: 1
]
SLOs: Vending Machine Reliability
Time Threshold:
Expiry: 5 Minutes
Time window: 10 Minutes
Após a configuração do Smart Alert, o sistema começa a monitorar a taxa de queima da configuração do SLO de Confiabilidade da Máquina de Venda Automática durante o intervalo de tempo especificado para o alerta.
Cenário: Monitoramento e acionamento de eventos
A taxa de queima excede 1 para a janela de alerta (últimas 12 horas)
- Suponha que a taxa de queima calculada para as últimas 12 horas comece a exceder 1.
- Com o limite de tempo definido para 10 minutos, o sistema aguarda o período completo de 10 minutos antes de tomar qualquer ação.
- Se a taxa de queima ainda permanecer acima de 1 após 10 minutos, o sistema aciona um evento de alerta, levantando uma questão.
A taxa de queima cai abaixo de 1 para a janela de alerta (últimas 12 horas)
- Se, após algum tempo, a taxa de queima da janela de alerta cair abaixo de 1, o sistema continuará monitorando.
- Se a taxa de queima permanecer abaixo de 1, o sistema aguardará o prazo de validade de 5 minutos.
- Se a taxa de queima permanecer abaixo de 1 durante os 5 minutos completos, o evento será automaticamente encerrado.
Exemplo 4 - Alerta inteligente para monitorar a taxa de queima de um SLO com várias janelas de alerta e respectivos limites
Objetivo: Alertar e levantar uma questão se a taxa de queima da configuração SLO de confiabilidade da máquina de venda automática for superior a 1 nas últimas 24 horas e superior a 4 nas últimas 2 horas.
A configuração do alerta inteligente de níveis de serviço deve ser:
Rule:
Alert Type: Error Budget
Metric: Burn Rate V2
Burn Rate Config:
[
Alert Window Type: LONG
Duration: 24 Hours
Duration Unit Type: Hour
Threshold:
Operator: >
Value: 1
,
Alert Window Type: SHORT
Duration: 2 Hours
Duration Unit Type: Hour
Threshold:
Operator: >
Value: 4
]
SLOs: Vending Machine Reliability
Time Threshold:
Expiry: 5 Minutes
Time window: 10 Minutes
Após a configuração do Smart Alert, o sistema começa a monitorar a taxa de consumo da configuração do SLO de Confiabilidade da Máquina de Venda Automática, tanto para janelas de alerta longas quanto curtas.
Cenário: Monitoramento e acionamento de eventos
A taxa de queima excede 1 para janelas de alerta longas e curtas (últimas 24 horas e 2 horas)
- Suponha que a taxa de queima calculada para as últimas 24 horas comece a exceder 1 e, para as últimas 2 horas, comece a exceder 4.
- Com o limite de tempo definido para 10 minutos, o sistema aguarda o período completo de 10 minutos antes de tomar qualquer ação.
- Se a taxa de queima de ambas as janelas de alerta ainda violar os limites após 10 minutos, o sistema aciona um evento de alerta, levantando uma questão.
A taxa de queima cai abaixo de 1 para a janela de alerta longa, mas permanece acima de 4 para a janela de alerta curta
- Se, após algum tempo, a taxa de queima para a janela de alerta longa cair abaixo de 1, mas a taxa de queima para a janela de alerta curta permanecer acima de 4, o sistema continuará monitorando.
- Se a taxa de queima permanecer abaixo de 1 durante o longo período de alerta, o sistema aguarda o prazo de expiração de 5 minutos.
- Se a taxa de queima permanecer abaixo de 1 durante a janela de alerta longa por 5 minutos completos, independentemente do valor da janela de alerta curta, o evento será automaticamente encerrado, pois ambos os limites devem ser violados para que um alerta seja enviado. O mesmo se aplica ao contrário — mesmo quando a janela de alerta curta viola o limite, mas a janela de alerta longa não.
A taxa de queima cai abaixo de 1 para a janela de alerta longa e abaixo de 4 para a janela de alerta curta
- Se, após algum tempo, a taxa de queima para ambas as janelas de alerta cair abaixo de seus respectivos limites, o sistema continuará monitorando.
- Se a taxa de queima permanecer abaixo dos limites, o sistema aguarda o limite de tempo de expiração de 5 minutos.
- Se a taxa de queima permanecer abaixo dos limites durante os 5 minutos completos, o evento será automaticamente encerrado.
Resolução de problemas
A seguir estão algumas sugestões para resolver problemas comuns com SLOs de configuração.
Problema : Nenhum orçamento de erros é consumido, o status do SLO é sempre 100%.
- Solução : use o gráfico de indicadores no painel SLO para verificar se o indicador nunca excede o limite durante a janela de tempo SLO, resultando em nenhum consumo do orçamento de erros. Você pode considerar modificar o limite de acordo com isso.
Problema : Nenhum orçamento de erros é consumido, o status do SLO é sempre 100%.
- Solução : use o gráfico de tráfego no painel SLO para verificar se a entidade está recebendo tráfego durante a janela de tempo SLO. Caso contrário, o orçamento de erros e o status do SLO não serão afetados.
Problema : O orçamento de erros é consumido rapidamente de forma consistente, o status do SLO permanece negativo.
- Solução : use o gráfico de indicadores no painel SLO para verificar se o indicador está excedendo consistentemente o limite durante a janela de tempo SLO, resultando em um rápido consumo do orçamento de erros. Você pode considerar modificar o limite de acordo com isso.
Problema : O alerta de taxa de queima não é acionado devido ao desalinhamento da janela de tempo.
- Solução :
- SLO com janela de tempo fixa : se o SLO estiver configurado com uma janela de tempo fixa, o alerta poderá não ser acionado se o cálculo da taxa de consumo for baseado em uma janela de alerta mais longa do que o tempo real decorrido no período do SLO. Por exemplo, se a janela de alerta exigir dados de um período de 12 horas, mas a janela de tempo SLO acabou de começar, pode não haver tempo suficiente para que a taxa de queima exceda o limite. Como resultado, nenhum alerta é acionado, mesmo que a taxa de queima seja alta durante o tempo decorrido.
- Janela de tempo contínua SLO : se o SLO estiver definido para uma janela de tempo contínua, o cálculo da taxa de queima pode não acionar um alerta se a janela de alerta se estender além do tempo de criação do SLO. Por exemplo, se a janela de alerta ultrapassar o período em que o SLO foi criado ou estava ativo, a taxa de queima não poderá ser calculada corretamente, pois os dados não estarão disponíveis para toda a janela de alerta.
- Solução :