Services e SLA

Service monitoring trabalha no nível do serviço

O monitoramento de Services fornece uma visão de alto nível sobre disponibilidade e dependência, diferente de detalhes como CPU, disco ou uma interface específica. A hierarquia permite representar serviços compostos, identificar pontos fracos e calcular SLA com base no impacto real observado.

A árvore traduz arquitetura técnica em dependência de serviço

Um Service pode possuir filhos e pais. O status de níveis inferiores pode propagar para níveis superiores conforme algoritmo e regras configuradas. A árvore deve representar uma dependência lógica real, não apenas uma classificação visual. Se dois componentes não participam do mesmo serviço, não devem ser conectados apenas para “organizar a tela”.

Nem todo problema técnico derruba o serviço

Uma fonte redundante com falha pode gerar problema de hardware sem indisponibilidade do serviço. Um link backup down pode reduzir resiliência, mas manter a Internet disponível. Services permitem modelar essa diferença: o componente pode estar em PROBLEM enquanto o serviço permanece OK ou apenas degradado.

Problemas chegam ao Service por tags

Problem tags correlacionam problemas de triggers a Services. Apenas Services no nível mais baixo da hierarquia podem receber problem tags e serem associados diretamente a problemas. Se múltiplos problemas corresponderem, o Service assume o status do problema mais severo.

Service tags têm outra função

Service tags identificam o próprio Service e são usadas para associar Services a SLAs e Service Actions. Elas não são iguais às problem tags. Essa separação é importante: problem tags dizem “quais incidentes afetam este Service”; service tags dizem “que tipo de serviço este objeto representa e a quais políticas ele pertence”.

SLA usa service tags

Na associação entre SLA e Services, a lógica é baseada em service tags. Um Service será incluído se possuir ao menos uma tag correspondente às condições do SLA. Isso permite criar um SLA para todos os serviços com customer=cliente-a, class=gold ou provider=operadora-a sem selecionar cada Service manualmente.

O algoritmo define como filhos influenciam o pai

Services com filhos possuem algoritmo de cálculo de status. Entre as opções estão manter OK, assumir o status mais crítico quando todos os filhos estão em problema ou assumir o status mais crítico entre os filhos. Além disso, status rules permitem modelagem quantitativa muito mais específica.

N, percentual e peso permitem modelar impacto real

Status rules podem alterar o status do Service com base em quantidade de filhos, percentual de filhos ou peso agregado. Isso permite expressar políticas como “Disaster se ao menos 50% das filiais estiverem indisponíveis” ou “High se o peso dos serviços críticos afetados ultrapassar determinado limite”.

Peso representa importância relativa

Quando filhos não possuem o mesmo impacto, weight permite diferenciá-los. Um link de backbone pode ter peso maior que um link secundário; um serviço premium pode pesar mais que um ambiente de teste. O uso deve ser documentado para que peso não vire um número arbitrário sem significado operacional.

SLO é o objetivo mensurável

Service Level Objective define a disponibilidade esperada. Um SLO de 99,9% significa que o serviço deve permanecer disponível em pelo menos 99,9% do período considerado, descontando janelas excluídas conforme a configuração do SLA. O objetivo deve refletir contrato ou meta interna, não apenas um número “bonito”.

SLI é o resultado observado

Service Level Indicator mede a disponibilidade real do Service no período. A comparação SLI versus SLO mostra se o objetivo foi atingido. Essa distinção é fundamental: SLA é a política, SLO é a meta e SLI é o desempenho medido.

Disponibilidade pode ser traduzida em tempo permitido de indisponibilidade

Mesmo quando o Zabbix não chama isso explicitamente de error budget, a matemática do SLO permite derivar o tempo máximo de indisponibilidade aceitável. Isso ajuda equipes a entender o significado prático de 99%, 99,9% ou 99,99%.

SLA pode ter calendário operacional

Nem todo serviço precisa ser medido 24x7. Um SLA pode refletir horário comercial, operação contínua ou períodos específicos. O calendário deve corresponder ao serviço contratado ou à expectativa interna, evitando penalizar indisponibilidade fora do período em que o serviço deveria estar disponível.

Manutenção planejada precisa de tratamento explícito

Períodos de downtime podem ser excluídos do cálculo de SLA quando previstos pela política. Isso evita misturar manutenção autorizada com falha não planejada. A exclusão deve ser governada: se qualquer manutenção apaga indisponibilidade do SLA sem critério, o indicador perde credibilidade.

Relatório transforma eventos em evidência histórica

O SLA report apresenta SLI e dados relacionados aos Services mapeados ao SLA. Ele pode ser filtrado por período e Service. Isso transforma histórico de problemas em uma visão de cumprimento de objetivo, adequada para acompanhamento interno ou prestação de contas.

Service ajuda a subir e descer entre impacto e causa

A camada de Services não substitui triggers e hosts. Ao identificar um Service degradado, o operador ainda precisa acessar os problemas de origem. Macros como SERVICE.ROOTCAUSE podem listar eventos de trigger associados à falha do Service, preservando o caminho entre impacto de negócio e causa técnica.

Mudança de status também pode gerar ação

O Zabbix possui Service Actions separadas das Trigger Actions. Elas podem reagir a eventos de Service e usar service tags nas condições. Isso permite enviar alertas diferentes para “roteador down” e “serviço corporativo indisponível”, mesmo quando o segundo foi causado pelo primeiro.

Árvore boa reduz duplicação sem esconder dependências

Evite uma árvore profunda apenas por estética. Cada nível deve acrescentar significado: organização → serviço → região → unidade → componente lógico, por exemplo. Hierarquia excessiva aumenta manutenção e torna difícil entender por que um status foi propagado.

Serviços redundantes precisam de regra de status apropriada

Se Internet de uma filial depende de dois links redundantes, o Service não deveria ficar indisponível quando apenas um cai. Uma árvore com filhos e algoritmo/regra adequada pode representar degradação com um link down e indisponibilidade quando ambos falham.

Services são úteis para indisponibilidade massiva por operadora

Uma operadora pode ser representada como Service pai de vários circuitos ou Services regionais. Regras por N ou N% ajudam a transformar dezenas de links em um estado agregado. Isso complementa o modelo de correlação sem inventar dependência técnica entre circuitos irmãos.

Agregação geográfica reduz falso “outage nacional”

Se uma operadora possui circuitos em várias regiões, use Services regionais abaixo do Service da operadora. Assim uma falha no RJ pode degradar apenas o ramo RJ e, conforme regras, talvez nem altere o status nacional.

Service tree pode representar cliente ou tenant

Em ambientes MSP, cada cliente pode possuir uma árvore própria de serviços, desde que permissões, tags e políticas sejam desenhadas corretamente. Service tags podem ajudar a associar SLA por cliente, contrato ou classe de atendimento.

Classes de SLA exigem diferença real

Criar Gold, Silver e Bronze só faz sentido se SLO, calendário, escalonamento ou política diferirem. Caso contrário, são apenas rótulos. A modelagem deve refletir compromisso operacional mensurável.

Status do Service não precisa copiar exatamente a trigger

Status rules podem transformar o impacto. Um problema Warning em um único componente pode não alterar o Service; múltiplos Warnings podem elevar o serviço para High. Isso permite representar impacto composto que não existe em nenhuma trigger isoladamente.

Toda regra de status deve possuir cenário de teste

Se uma regra diz “High quando 25% dos filhos estiverem em Average ou superior”, crie teste controlado que confirma 24%, 25% e recuperação. Limiares não testados costumam falhar justamente durante incidentes complexos.

SLA herda a qualidade das triggers

Se triggers flapeiam, têm falso positivo ou não representam indisponibilidade real, o SLA também será incorreto. Service monitoring não corrige coleta ruim; ele amplifica o resultado da modelagem anterior. Antes de usar SLA para contrato, valide rigorosamente triggers, recovery e manutenção.

SLA de disponibilidade não mede tudo

Um serviço pode estar tecnicamente UP e ainda estar lento. Se latência ou performance são compromissos contratuais, precisam de indicadores próprios e talvez Services/triggers específicos. Não use uma única porcentagem de disponibilidade para representar qualidade completa.

Serviço pode ter metas diferentes por dimensão

Disponibilidade, tempo de resposta, perda e capacidade são objetivos diferentes. O SLA de availability pode ser 99,9%, enquanto performance pode exigir latência abaixo de 100 ms. Separe indicadores para manter semântica clara.

Tag e regra precisam ser versionáveis e explicáveis

Quando SLA participa de contrato ou relatório executivo, mudanças em service tags, problem tags, status rules e calendário devem ter controle. Alterar uma tag pode remover um Service do SLA sem qualquer falha técnica. Trate essa configuração como parte do modelo de negócio.

Services e SLAs podem ser automatizados

A API do Zabbix possui objetos para Services e SLA. Ambientes com muitos clientes ou circuitos podem gerar hierarquias, tags e políticas via automação, desde que exista fonte de verdade para contratos, serviços e ownership.

SLA precisa ser visível antes do fechamento do mês

Não espere o relatório mensal para descobrir que o SLO foi perdido. Dashboards podem mostrar status atual do Service, SLI acumulado e tendência. Quando o error budget restante se aproxima de zero, a equipe pode priorizar estabilidade antes de novas mudanças.

SLA é consequência de detecção, resposta e recuperação

Melhorar SLI envolve reduzir frequência e duração de indisponibilidades. Zabbix ajuda na detecção e contexto; processos operacionais reduzem MTTR. Um SLA ruim nem sempre é “problema do monitoramento”, mas o monitoramento deve mostrar claramente onde o tempo foi perdido.

O Service deve refletir o que o usuário percebe

Se o usuário continua acessando o serviço por caminho redundante, o Service principal pode permanecer OK mesmo que um componente esteja em falha. A modelagem deve se aproximar da experiência entregue, não da ansiedade da infraestrutura.

Service status melhora a linguagem com áreas não técnicas

“BGP session down” pode ser útil ao NOC, mas “Internet corporativa degradada em três filiais” é mais apropriado para gestão. Services permitem que ambos coexistam, cada um no nível correto de comunicação.

Comece com poucos Services de alto valor

É comum tentar modelar toda a empresa de uma vez. Melhor começar por serviços críticos e dependências conhecidas, validar o cálculo e expandir. Uma árvore pequena e correta é mais útil que centenas de Services sem owner ou lógica validada.

O que 99,9% realmente permite?

Valores aproximados considerando disponibilidade contínua 24x7 e sem exclusões.

Internet corporativa multioperadora

INTERNET CORPORATIVA
│
├── RJ
│   ├── Site Centro
│   │   ├── Operadora A
│   │   └── Operadora B
│   │
│   └── Site Maricá
│       ├── Operadora A
│       └── Operadora C
│
└── SP
    ├── Site 01
    └── Site 02

A regra de cada site pode representar redundância; a regra regional pode representar quantidade de sites afetados; a raiz pode representar impacto global.

Um link falha, o serviço degrada; dois falham, o serviço cai

SERVICE: Internet — Site Centro

Filhos:
- Link Operadora A
- Link Operadora B

Política conceitual:

0 filhos em problema
→ OK

1 filho em problema
→ Warning
→ redundância perdida

2 filhos em problema
→ Disaster
→ indisponibilidade real

Quantidade, percentual e peso

Problem tags e Service tags lado a lado

TRIGGER / PROBLEM TAGS
service=internet
site=rj-centro
carrier=operadora-a
scope=availability

SERVICE: Internet — Operadora A — RJ Centro

Problem tags:
service=internet
site=rj-centro
carrier=operadora-a

Service tags:
service_class=wan
provider=operadora-a
customer=interno
sla_class=gold

Um SLA deve ser legível sem conhecer a árvore inteira

SLA: Internet Gold

Service tag:
sla_class=gold

SLO:
99.95%

Calendar:
24x7

Excluded downtimes:
- manutenção aprovada
- mudança planejada com janela formal

Reporting:
mensal

Owner:
Operações de Rede

Quanto do orçamento de indisponibilidade já foi consumido?

Período: 30 dias
SLO: 99.95%

Downtime permitido:
21m 36s

Downtime observado:
15m 00s

Error budget restante:
6m 36s

Se novo incidente durar 10 minutos:
→ SLO será violado

Não espere o relatório mensal

Impacto agregado com evidência técnica

SERVICE
Internet Corporativa — RJ
Status: Disaster

Root causes:
1. Link Operadora A — RJ Centro — DOWN
2. Link Operadora B — RJ Centro — DOWN
3. BGP peer ISP-02 — Niterói — DOWN

Ação:
→ abrir evento agregado
→ manter acesso aos problemas de origem
→ evitar investigação “às cegas” no nível executivo

SLA bonito, dado ruim

Criar Service redundante com SLA

Teste status e cálculo antes de usar para SLA real

Antes de publicar um SLA

Base factual

Conteúdo desenvolvido a partir da documentação oficial Zabbix 7.4 sobre Service monitoring, Services, Problem tags, Service tags, Status rules, Service Actions, SLA, SLO, SLI e SLA reports. Os modelos de redundância, error budget, arquitetura de serviços, laboratórios, matrizes e recomendações operacionais são síntese editorial própria.

Linha Zabbix 7.4

Mantenha problem tags e service tags com finalidades distintas. O modelo de Services deve representar dependências de serviço reais para que SLA/SLO tenha significado operacional.