Framework — Vortex

PRINCÍPIOS FUNDAMENTAIS

As três leis do framework

Antes de qualquer regra técnica, estas três leis regem toda decisão de implementação.

①

Um framework construído para escalar com cada cliente. A taxonomia, as macros de tempo e a estrutura de camadas são o resultado de anos de experiência operacional — e é justamente essa consistência que entrega valor. Cada cliente contribui com as especificidades do seu ITSM; o Vortex garante que tudo se conecte de forma padronizada, previsível e auditável.

②

Not Classified é espaço de evolução, não de produção. Itens com severidade Not Classified fazem parte do ciclo natural de desenvolvimento e validação de sensores. Em produção, garantimos que cada item já esteja classificado, testado e alinhado à sua camada — isso é o que diferencia um ambiente maduro de um ambiente ruidoso.

③

A severidade é uma consequência técnica, não uma opinião. Ao mapear cada ativo em uma camada L1–L5 e uma profundidade de observabilidade, a severidade correta emerge naturalmente. Isso elimina subjetividade, reduz alertas desnecessários e garante que cada acionamento tenha o peso exato que merece.

Revisão: Este documento é revisado a cada 6 meses ou sempre que houver mudança de política, sistema ou requisito de negócio. Alterações são comunicadas a todas as partes interessadas.

SEÇÃO 01

Camadas de impacto L1–L5

Cinco camadas organizam cada ativo monitorado pela distância do seu impacto ao negócio. Essa estrutura garante que cada evento receba exatamente o nível de atenção que merece — nem mais, nem menos.

Camada	Nome	Profundidade	Severidades mapeadas	Exemplos de itens	Vertical típica
`L5`	Impacto de Negócio	Estratégica	Disaster	SLA breach, perda de receita, usuário final indisponível, incidentes de segurança	Negócio — Missão crítica, Compliance
`L4`	Core Business	Estratégica → Tática	High Disaster	ERP, CRM, portal cliente, sistema de pagamento, integrações críticas	Negócio — ERP, E-commerce, Financeiro
`L3`	Serviços de TI	Tática	Average High	APIs internas, bancos de dados, filas, autenticação, certificados, logs de app	Tecnológica — Banco de Dados, Middleware
`L2`	Plataforma	Operacional → Tática	Warning Average	OS, containers, VMs, Kubernetes, agentes, rede lógica, CRC	Tecnológica — Virtualização, Kubernetes, Cloud
`L1`	Infraestrutura Física	Operacional	Information Warning	CPU, disco, memória, temperatura, fontes, interfaces físicas, fan RPM	Tecnológica — Servidores, Storage, Network

Flexibilidade com consistência: Um mesmo host pode naturalmente ter itens em camadas diferentes. Um servidor de banco de dados monitora disco (L1/Warning), o processo mysqld (L3/Average) e a disponibilidade da aplicação que ele suporta (L4/High). A tag layer no host define sua camada principal — os itens individuais podem ter contextos complementares.

SEÇÃO 02

Severidades Zabbix

O Zabbix possui seis níveis de severidade. O framework Vortex define a aplicabilidade exata de cada um — garantindo que toda equipe, em qualquer ambiente, interprete e responda aos eventos da mesma forma.

Código	Severidade	Aplicabilidade	Sensores típicos	Em produção
`0`	Not Classified	Exclusivo para desenvolvimento de sensores, gatilhos e processos. Espaço reservado para avaliação futura ou integração inicial.	Itens em fase de testes, validação de coleta	⚙ Apenas dev/teste
`1`	Information	Itens raramente alterados, usados para identificação ou eventos apenas informativos que não exigem atenção imediata.	Hostname, agent.hostname, versão do banco, agent.variant	✓ Sem trigger
`2`	Warning	Configurações ou capacidades fixas (itens estáticos). Problema potencial que pode exigir investigação, mas não é crítico.	Disco >80%, CPU >85%, memória total, espaço total de tablespace	✓ Ticket D+1
`3`	Average	Itens com mudanças menos frequentes (análise de tendências). Problema significativo que deve ser resolvido em breve.	Container down, latência DB, pod restart, cert expira <30d, logs de aplicação	✓ Ticket P3
`4`	High	Monitoramento geral de desempenho e utilização. Problemas críticos que precisam de atenção imediata para evitar interrupções.	API timeout, DB unreachable, auth service down, fila cheia, cert <7d	✓ Ticket P2
`5`	Disaster	Itens críticos com necessidade de monitoramento em tempo real. Incidente grave: war room, escaladas, risco de perda de dados ou prejuízo financeiro.	Sistema core down, SLA breach, ERP indisponível, pagamento falhou, data loss	⚡ War room

SEÇÃO 03

Macros de tempo

Intervalos cuidadosamente calibrados com base em experiência operacional real. Esses valores garantem cobertura adequada sem gerar ruído — e podem ser refinados pontualmente mediante análise técnica da Engenharia de Monitoração.

Evolução v2.0: Os tempos de recovery foram refinados para sempre serem menores que o tempo de análise. Princípio: recovery = ~50% do tempo de análise. Esse ajuste reduz fechamentos prematuros e garante que o ambiente esteja genuinamente estável antes de encerrar o evento.

Disaster

Coleta3m

{$TEMPO_COLETA_DISASTER}

Análise trigger15m

{$TEMPO_ANALISE_DISASTER}

Recovery trigger5m

{$TEMPO_RECOVERY_DISASTER}

SLA de resposta< 15 min

High

Coleta5m

{$TEMPO_COLETA_HIGH}

Análise trigger30m

{$TEMPO_ANALISE_HIGH}

Recovery trigger15m

{$TEMPO_RECOVERY_HIGH}

SLA de resposta1 hora

Average

Coleta10m

{$TEMPO_COLETA_AVERAGE}

Análise trigger45m

{$TEMPO_ANALISE_AVERAGE}

Recovery trigger20m

{$TEMPO_RECOVERY_AVERAGE}

SLA de resposta4 horas

Warning

Coleta15m

{$TEMPO_COLETA_WARNING}

Análise trigger60m

{$TEMPO_ANALISE_WARNING}

Recovery trigger30m

{$TEMPO_RECOVERY_WARNING}

SLA de respostaD+1

Information

Coleta1h

{$TEMPO_COLETA_INFORMATION}

Análise0 (sem trigger)

{$TEMPO_ANALISE_INFORMATION}

Recovery0 (sem trigger)

{$TEMPO_RECOVERY_INFORMATION}

SLARevisão semanal

Macros de governança — contexto e limiares

Macro	Padrão	Nível	Descrição
`{$ENV}`	prd	Host	prd · hml · dev · qa
`{$CLIENT}`	—	Host	Código/nome do cliente. Obrigatório em ambientes multi-tenant.
`{$SERVICE_LAYER}`	L2	Host	Camada principal do host (L1–L5). Usada em tags e roteamento.
`{$ONCALL_TEAM}`	—	Host/Grupo	Time de plantão responsável. Mapeado para fila ITSM.
`{$DISK_WARN}` / `{$DISK_HIGH}`	80 / 90	Global/Host	Limiares de disco (%). Sobrescrevíveis por host.
`{$CPU_WARN}` / `{$CPU_HIGH}`	85 / 95	Global/Host	Limiares de CPU (%).
`{$MEM_WARN}`	90	Global/Host	Limiar de memória (%).
`{$CERT_EXPIRE_WARN}` / `{$CERT_EXPIRE_HIGH}`	30 / 7	Global	Dias para expiração de certificado.
`{$HYSTERESIS_PERIOD}`	5m	Template	Período mínimo antes de re-trigger (anti-flapping).
`{$SUPPRESSION_WINDOW}`	0	Host	Janela de manutenção ativa (0 = não suprimido).

SEÇÃO 04

Padrão de nomenclatura

Nomes padronizados são a base de qualquer operação escalável. Com uma nomenclatura consistente, automação de roteamento, filtros e relatórios funcionam sem esforço manual — e qualquer membro da equipe entende o ambiente ao primeiro olhar.

Hosts

{cliente}-{ambiente}-{tipo}-{seq}

ex: acme-prd-db-01
ex: acme-hml-app-02
ex: acme-prd-k8s-node-03

Tipo: app · db · lb · k8s · fw · sw · esxi · sto

Grupos de hosts

{Cliente}/{Ambiente}/{Tipo}

ex: ACME/Produção/Database
ex: ACME/Homologação/App
ex: Global/Infra/Network

Hierarquia de 3 níveis obrigatória. Barra como separador.

Itens (sensores)

{contexto}.{metrica}[{param}]

ex: system.cpu.util[,user]
ex: vfs.fs.size[/,pused]
ex: custom.app.response_time

Prefixo custom. obrigatório para itens externos/scripts.

Triggers

[{SEV}] {HOST.NAME}: {condição}

ex: [HIGH] {HOST.NAME}: API timeout >5s
ex: [WARN] {HOST.NAME}: Disco /var >80%
ex: [DIS] {HOST.NAME}: DB unreachable

Prefixo de severidade obrigatório. Visível em exportações e integrações externas.

Templates

Tmpl {Tecnologia} {Versão} {Tipo}

ex: Tmpl Linux OS Base
ex: Tmpl PostgreSQL 15 DB
ex: Tmpl Kubernetes Node

Prefixo Tmpl obrigatório. Sem abreviações ambíguas.

Dashboards

Vortex - {Cliente} - {Foco}

ex: Vortex - ACME - Overview
ex: Vortex - Global - SLA
ex: Vortex - ACME - Kubernetes

Prefixo Vortex identifica dashboards gerenciados pela plataforma.

SEÇÃO 05

Taxonomia de tags

Tags são a inteligência de roteamento do Vortex. Elas viajam com cada evento do Zabbix até o ITSM do cliente, carregando contexto de negócio, ambiente e serviço — tornando cada ticket automaticamente enriquecido, rastreável e direcionado à equipe certa.

env

Obrigatória

Criticidade base do tratamento. Produção ativa SLA rigoroso e fila prioritária.

prdhmldevqa

client

Obrigatória

Associa o evento ao cliente correto. Essencial em ambientes multi-tenant.

braskemacmestefanini

layer

Obrigatória

Camada de impacto do host. Direciona a severidade e o fluxo de escalonamento.

L1L2L3L4L5

host_type

Obrigatória

Tipo do ativo monitorado. Orienta equipe de suporte e diagnóstico.

serverdatabasek8s_nodenetworkstoragevm

itsm_queue

Obrigatória

Fila de atendimento exata no ITSM do cliente. Nome conforme cadastro.

infra_bancoinfra_nocinfra_unixinfra_windows

service

L3 – L5

Identifica a aplicação ou serviço de negócio impactado. Direciona ao owner.

erp_xyzportal_clienteapi_credito

os

Infraestrutura

Sistema operacional do ativo. Orienta ações de diagnóstico específicas.

linux_rhellinux_ubuntuwindows_srvaix

location

Recomendada

Localização geográfica/lógica. Direciona para equipes locais e issues regionais.

dc_saopauloaws_sa_east1escritorio_rj

playbook

Recomendada

Referência ao SOP/Runbook. Garante passos corretos de resolução.

sop_db_criticoplaybook_perf_app

compliance

Se aplicável

Requisitos de conformidade. Pode disparar procedimentos adicionais.

lgpdpci_dsssla_ouro

symptom

Recomendada

Sintoma técnico chave. Ajuda a equipe a identificar rapidamente a natureza do problema.

cpu_altadisco_cheioerro_http503

ticket_id

Automática

Preenchida pelo Thanos após abertura. Vincula evento Zabbix ao registro ITSM.

INC0905891CHG0012345

SEÇÃO 06

Ciclo de vida do evento

Cada evento tem uma história completa — do primeiro sinal ao fechamento com métricas de SLA. Essa rastreabilidade é o que transforma um sistema de alertas em uma ferramenta real de gestão de serviços.

FASE 01

⚡

Abertura

PROBLEM detectado

Ticket aberto no ITSM com prioridade mapeada e fila definida pelas tags. Marco inicial para cálculo de SLA.

{EVENT.ID}{EVENT.STATUS}{EVENT.NAME}{EVENT.SEVERITY}{EVENT.NSEVERITY}{EVENT.OPDATA}{TRIGGER.ID}{TRIGGER.NAME}{TRIGGER.DESCRIPTION}{HOST.NAME}{HOST.IP}{HOST.ID}{EVENT.TAGS}{EVENT.TAGSJSON}{EVENT.DATE}{EVENT.TIME}{ACTION.NAME}

FASE 02

👁

Reconhecimento

ACK registrado

Ticket atualizado com responsável e contexto. Escalada automática disparada se sem ACK no prazo do SLA.

{EVENT.ACK.STATUS}{EVENT.ACK.USER.ALIAS}{EVENT.ACK.HISTORY}{EVENT.UPDATE.STATUS}{EVENT.UPDATE.MESSAGE}{USER.FULLNAME}{USER.NAME}{EVENT.AGE}{EVENT.SEVERITY}

FASE 03

🔧

Tratamento

Equipe em ação

Equipe atua conforme playbook vinculado à tag. SOP e histórico disponíveis diretamente no ticket.

{TRIGGER.URL}{EVENT.TAGSJSON}{TRIGGER.DESCRIPTION}{ITEM.NAME}{ITEM.KEY}

FASE 04

✓

Resolução

Evento OK

Ticket fechado automaticamente. MTTR calculado, duração registrada, métricas de SLA atualizadas.

{EVENT.RECOVERY.DATE}{EVENT.RECOVERY.TIME}{EVENT.DURATION}{EVENT.AGE}{USER.FULLNAME}{TRIGGER.URL}

Correlação bidirecional: {EVENT.ID} é a chave que mantém o Zabbix e o ITSM do cliente sempre sincronizados — armazenado no campo de correlação do ITSM (ex: u_zabbix_event_id). O Thanos preenche automaticamente a tag ticket_id no Zabbix após a criação do ticket, fechando o loop de rastreabilidade em tempo real.

SEÇÃO 07

Mapeamento ITSM

O Thanos traduz automaticamente cada evento Zabbix para a linguagem do ITSM de cada cliente. A tabela abaixo define o mapeamento padrão — o cliente compartilha os valores exatos dos seus campos e a integração acontece de forma transparente.

Zabbix severity	ITSM priority	impact	urgency	SLA resposta	Ação Vortex
Disaster	`P1 — Crítico`	1 — Alto	1 — Alta	< 15 min	War room · Bridge de crise · Escalada gestão · Postmortem 48h
High	`P2 — Alto`	2 — Médio	1 — Alta	1 hora	Chamada telefônica N2 · Canal Teams · Ticket cliente
Average	`P3 — Médio`	2 — Médio	2 — Média	4 horas	Notificação Teams/Slack · E-mail N1 + cópia N2
Warning	`P4 — Baixo`	3 — Baixo	3 — Baixa	D+1	Ticket automático categoria "Melhoria" · E-mail N1
Information	`P5 — Planejamento`	3 — Baixo	3 — Baixa	Semanal	Log + dashboard de tendências. Sem notificação ativa.

Mapeamento de filas — tabela padrão de roteamento por tag

Tag Zabbix (chave:valor)	Fila ITSM destino	Critério
`itsm_queue:infra_banco`	GRP_SUP_Banco_Dados	Preenchido pelo cliente no questionário de onboarding
`itsm_queue:infra_noc`	GRP_SUP_NOC	Preenchido pelo cliente no questionário de onboarding
`itsm_queue:infra_unix`	GRP_SUP_Unix_Linux	Preenchido pelo cliente no questionário de onboarding
`itsm_queue:infra_windows`	GRP_SUP_Windows	Preenchido pelo cliente no questionário de onboarding
`itsm_queue:infra_rede`	GRP_SUP_Network	Preenchido pelo cliente no questionário de onboarding
`(sem tag itsm_queue)`	GRP_SUP_Nivel_1	Fila default — fila de triagem N1

Os nomes exatos das filas são fornecidos pelo cliente no questionário de onboarding e configurados no Thanos como um adapter dedicado. Essa abordagem garante flexibilidade para cada ambiente sem abrir mão da consistência do framework.

SEÇÃO 08

Ações por severidade

Para cada severidade, o Vortex define canais de comunicação, SLA de resposta e fluxo de escalada. Essa previsibilidade é o que permite que as equipes ajam com confiança — sabendo exatamente o que fazer, quando e com quem.

Disaster — War room imediato

→ Ticket P1 — impacto de negócio declarado
→ Chamada automática N2, N3 e gestor
→ Bridge de crise aberta imediatamente

→ Comunicação ao cliente em até 15 min
→ SLA de resposta: imediato (<15 min)
→ Postmortem obrigatório em até 48h

High — Escalonamento imediato

→ Ticket P2 com cliente notificado
→ Chamada telefônica para N2 de plantão

→ Canal de crise criado no Teams
→ Escalada para N3 se sem ACK em 30min

Average — Ação em 4 horas

→ Ticket P3 aberto automaticamente
→ Notificação Teams/Slack #alertas

→ E-mail N1 + cópia N2
→ Escalada automática se sem ACK em 2h

Warning — Próximo dia útil

→ Ticket automático categoria "Melhoria"
→ E-mail para lista do time N1

→ Exibir em dashboard de operações
→ Auto-resolve sem ação se <2h

Information — Revisão semanal

→ Registrar no histórico Zabbix · Exibir em dashboard de capacidade · Sem notificação ativa · Base para tendências e planejamento de capacidade

SEÇÃO 09

Checklist de integração

Um guia completo para que cada novo ambiente entre em operação com o mesmo nível de qualidade e maturidade. Use em conjunto com o questionário de diretrizes — juntos, eles garantem um onboarding estruturado e sem surpresas.

0%

0 / 20 itens

1 — Acesso e autenticação à API ITSM

URL base da API REST do ITSM do cliente definida e documentada

Método de autenticação escolhido (Bearer Token recomendado)

Usuário de serviço dedicado criado no ITSM para o Vortex/Zabbix

Permissões verificadas: criar, consultar, atualizar e fechar tickets

Restrições de IP de origem verificadas e liberadas para os servidores Zabbix

2 — Mapeamento de campos e correlação

Campo de correlação definido no ITSM para armazenar {EVENT.ID}

Resposta de criação mapeada — campo que retorna o ID do ticket criado

Tabela de mapeamento de severidade Zabbix → prioridade/impacto/urgência ITSM documentada

Mapeamento de tag itsm_queue → fila/grupo de atribuição ITSM documentado e validado com equipe do cliente

Mapeamento de {HOST.NAME} → CI/CMDB definido (direto por nome ou lógica específica)

3 — Tags e macros obrigatórias no host

Tag env definida em todos os hosts (prd / hml / dev / qa)

Tag client definida (obrigatória em ambientes multi-tenant)

Tag layer definida em todos os hosts (L1–L5)

Tag host_type e itsm_queue definidas

Macros {$SERVICE_LAYER} e {$ONCALL_TEAM} preenchidas

4 — Nomenclatura e templates

Hosts nomeados conforme padrão {cliente}-{ambiente}-{tipo}-{seq}

Grupos de hosts criados com hierarquia {Cliente}/{Ambiente}/{Tipo}

Templates Vortex aplicados via GitOps — prefixo Tmpl em todos

5 — Validação e go-live

Teste de abertura de ticket via evento PROBLEM simulado no Zabbix

Teste de ACK, atualização e fechamento de ticket (evento OK)

Dashboard Batman atualizado com os novos hosts e métricas de governança

Revisão final com equipe do cliente — sign-off de go-live

SEÇÃO 10

Campos obrigatórios do evento

Cada campo listado abaixo carrega uma informação essencial para que o ciclo de vida do evento seja completo, rastreável e auditável. Quanto mais campos propagados, mais inteligente e útil se torna o ticket gerado no ITSM do cliente.

Macro Zabbix	Descrição	Fase	Criticidade	Uso no ITSM
`{EVENT.ID}`	ID único do evento Zabbix	Todas	CRÍTICO	Chave primária de correlação. Campo `u_zabbix_event_id`.
`{EVENT.STATUS}`	PROBLEM ou OK	Abertura / Fechamento	CRÍTICO	Define ação principal: PROBLEM → abre, OK → fecha.
`{EVENT.TAGS}`	Tags do evento (tag:valor)	Abertura	CRÍTICO	Roteamento automático, categorização e relatórios.
`{EVENT.TAGSJSON}`	Tags em formato JSON	Tratamento	Importante	Alternativa ao {EVENT.TAGS} para sistemas que preferem JSON.
`{EVENT.ACK.STATUS}`	Status de reconhecimento (Yes/No)	ACK	CRÍTICO	Dispara atualização do ticket. Melhora accountability.
`{EVENT.SEVERITY}`	Severidade textual	Abertura / Atualização	CRÍTICO	Mapeado para prioridade/impacto/urgência no ITSM.
`{EVENT.NSEVERITY}`	Código numérico (0–5)	Abertura	Importante	Útil para lógica condicional no webhook.
`{EVENT.NAME}`	Nome do evento (= nome do trigger)	Abertura	Importante	Título/resumo do ticket no ITSM.
`{EVENT.OPDATA}`	Valor que disparou o alerta	Abertura	Importante	Evidência técnica no corpo do ticket.
`{HOST.NAME}` / `{HOST.HOST}`	Nome visível do host	Abertura	CRÍTICO	Identifica o IC/CI afetado. Vínculo com CMDB.
`{HOST.IP}` / `{HOST.CONN}`	IP / conexão do host	Abertura	Importante	Localização adicional do ativo afetado.
`{TRIGGER.ID}`	ID único do trigger	Abertura	Importante	Categorização e análise de causa raiz.
`{TRIGGER.NAME}`	Nome do trigger	Abertura	Importante	Identifica o tipo de problema.
`{TRIGGER.DESCRIPTION}`	Descrição do trigger	Tratamento	Recomendado	Contexto e instruções no corpo do ticket.
`{TRIGGER.URL}`	Link para o trigger no Zabbix	Tratamento	Recomendado	Acesso direto ao Zabbix a partir do ticket.
`{EVENT.DATE}` / `{EVENT.TIME}`	Data/hora do evento	Abertura	CRÍTICO	Marco inicial para cálculo de SLA e MTTR.
`{EVENT.RECOVERY.DATE}` / `{EVENT.RECOVERY.TIME}`	Data/hora da recuperação	Fechamento	CRÍTICO	Marco final para MTTR e SLA total do incidente.
`{EVENT.DURATION}`	Duração total do evento	Fechamento	Importante	Duração calculada para métricas de performance.
`{EVENT.AGE}`	Idade do evento em andamento	ACK / Escalada	Recomendado	Usado em regras de escalada automática.
`{EVENT.ACK.USER.ALIAS}`	Usuário que reconheceu	ACK	Importante	Accountability — registra quem reconheceu no Zabbix.
`{EVENT.ACK.HISTORY}`	Histórico de reconhecimento	ACK	Recomendado	Notas e comentários do ACK no histórico do ticket.
`{ACTION.NAME}`	Nome da ação Zabbix que notificou	Diagnóstico	Recomendado	Identifica qual regra originou a comunicação com o ITSM.

Taxonomia de GovernançaZabbix — Padrão Vortex.

As três leis do framework

Camadas de impacto L1–L5

Severidades Zabbix

Macros de tempo

Padrão de nomenclatura

Hosts

Grupos de hosts

Itens (sensores)

Triggers

Templates

Dashboards

Taxonomia de tags

Ciclo de vida do evento

Mapeamento ITSM

Ações por severidade

Checklist de integração

Campos obrigatórios do evento

Taxonomia de Governança
Zabbix — Padrão Vortex.