Dashboards e mapas

A primeira pergunta do dashboard é “que decisão essa tela suporta?”

Antes de adicionar um widget, defina o usuário e a decisão. O NOC precisa enxergar indisponibilidade, concentração de impacto e prioridade. Um gestor pode precisar de SLA e tendência. Um especialista pode precisar de capacity, erros ou distribuição por interface. Misturar essas três audiências em uma tela única cria excesso de informação e leitura lenta.

Separe operação, análise e gestão

Uma arquitetura robusta pode usar dashboards distintos: NOC geral, WAN/operadoras, backbone/core, acesso/OLT, servidores, aplicações, capacidade e SLA. Cada dashboard pode ter várias páginas. O Zabbix 7.4 permite múltiplas páginas por dashboard e alternância em slideshow, o que combina bem com telas de operação contínua.

O que é crítico precisa aparecer antes do scroll

Na parte imediatamente visível coloque estado atual, problemas críticos, impacto por serviço/operadora, quantidade de ativos afetados e mudanças recentes. Gráficos históricos, detalhes de capacity e análises secundárias podem ficar em páginas seguintes. Um dashboard NOC deve ser útil nos primeiros segundos, não após exploração manual.

Todo elemento compete pela atenção do operador

Cores, movimento, números, gráficos e mapas disputam atenção. Use destaque apenas para exceção real. Um painel em que tudo é colorido perde hierarquia visual. O estado normal deve ser silencioso; problema crítico deve emergir sem depender de leitura detalhada.

Escolha o widget pela pergunta, não pela aparência

O Zabbix 7.4 oferece widgets como Problems, Problem hosts, Problems by severity, Host availability, Host card, Item value, Gauge, Graph, Honeycomb, Top hosts, Top items, Top triggers, SLA report, Map, Geomap, Web monitoring e outros. O melhor widget é o que responde a pergunta operacional com menor esforço cognitivo.

Um dashboard pode funcionar como interface exploratória

Widgets compatíveis podem usar outro widget ou o próprio dashboard como fonte para host, item, lista de itens ou período de tempo. Isso permite selecionar um host em um Host navigator e fazer outros widgets mudarem juntos, criando um painel exploratório em vez de várias telas duplicadas.

Todos olhando para a mesma janela temporal evita conclusões contraditórias

Widgets de gráfico e outros compatíveis podem usar o período do dashboard, de outro widget ou um período customizado. Para investigação, sincronizar vários gráficos no mesmo intervalo facilita correlacionar perda, tráfego, CPU, latência e eventos. Para KPIs instantâneos, use o valor atual quando histórico não acrescenta decisão.

Atualização mais rápida não significa operação melhor

Widgets possuem refresh configurável e usuários podem definir intervalos próprios em muitos casos. Reduzir refresh de tudo para segundos pode aumentar carga do frontend e não melhora sinais que mudam a cada minutos. Painéis de problema podem exigir frequência maior; SLA mensal ou inventário não.

Dashboard não ignora controle de acesso

O conteúdo exibido nos widgets depende das permissões do usuário sobre hosts e objetos relacionados. Dois operadores podem abrir o mesmo dashboard e enxergar resultados diferentes. Isso precisa ser considerado ao validar um painel compartilhado ou investigar discrepâncias entre equipes.

Use páginas para separar contextos, não para esconder desorganização

Um dashboard pode conter várias páginas e executá-las como slideshow. Uma estratégia útil é: Página 1 — situação geral; Página 2 — operadoras/WAN; Página 3 — core/backbone; Página 4 — acesso; Página 5 — capacidade. Não crie dezenas de páginas apenas para reproduzir a árvore de hosts.

A lista de problemas é o centro operacional, não o dashboard inteiro

O widget Problems deve ser filtrado por severidade, tags e grupos para mostrar o que requer ação. Se centenas de eventos irrelevantes precisam ser escondidos no widget, o problema provavelmente está na modelagem de triggers, dependências ou manutenção, não no dashboard.

Distribuição de severidade é excelente para triagem

Problemas por severidade ajudam a perceber rapidamente se existe concentração de High/Disaster e qual grupo está degradado. Use como indicador de panorama, mas mantenha acesso ao detalhe. Um número “12 High” sem contexto é apenas contador.

Ranking deve responder a um risco operacional

Top hosts e Top items são úteis para capacidade, utilização, temperatura, latência, perda e outras métricas comparáveis. Evite rankings sem unidade comum. “Top CPU” funciona; misturar CPU, memória, temperatura e tráfego num mesmo ranking não produz uma ordem significativa.

Ranking de último valor e ranking histórico respondem perguntas diferentes

Top items pode usar último valor ou agregações como min, max, avg, count, sum, first e last dentro de um intervalo. “Maior tráfego agora” e “maior média nas últimas 24h” podem apontar para ativos diferentes. Rotule claramente qual estatística está sendo exibida.

Gráfico deve mostrar mudança, relação ou tendência

Use gráfico quando a forma temporal importa: crescimento de utilização, degradação óptica, bursts de erro, aumento de latência ou saturação recorrente. Para “temperatura atual = 44 °C”, Item value ou Gauge pode ser mais eficiente. Para investigação, sobreponha métricas que compartilham unidade ou cuja relação é tecnicamente interpretável.

Densidade visual para muitos objetos semelhantes

Honeycomb é útil quando dezenas de entidades equivalentes precisam ser comparadas visualmente em pouco espaço, como OLTs, hosts, interfaces ou estados. O operador reconhece outliers rapidamente. Não use quando cada célula representa métricas com significado muito diferente.

Gauge funciona melhor para proporção contra limite

Utilização percentual, ocupação de disco e consumo em relação à capacidade podem funcionar em gauge. Evite usar gauge apenas porque “parece painel”. Para séries temporais e sazonalidade, gráfico comunica mais.

Navegação pode substituir dezenas de dashboards duplicados

Host navigator combinado com widgets dinâmicos permite selecionar um host e atualizar gráficos, item cards e outros componentes compatíveis. Isso cria uma visão “host cockpit” reutilizável para várias máquinas sem copiar o dashboard inteiro por equipamento.

Map é para relações, não para geografia real

Network maps podem representar hosts, triggers, host groups, outros maps e imagens, conectados por links. Eles são úteis para topologia, dependências, backbone, caminhos e visão hierárquica. Um mapa lógico não precisa imitar quilômetros reais; precisa deixar a relação operacional evidente.

Geomap é para localização geográfica real

O widget Geomap usa Leaflet e posiciona hosts com latitude e longitude válidas no inventário. Pode usar provedores de tiles predefinidos, customizados ou tiles hospedados internamente. Use quando geografia ajuda a interpretar impacto regional, cobertura, sites ou concentração de falhas.

Inventário vira fonte de dados do mapa

Para Geomap, hosts precisam de latitude entre -90 e 90 e longitude entre -180 e 180 em inventário. Coordenadas erradas ou ausentes produzem mapa incompleto. Em ambientes grandes, localização deve vir de processo de inventário confiável, não de preenchimento manual ocasional.

Uma visão nacional não deve mostrar cada porta

Mapas funcionam melhor por níveis. Nível 1: regiões/operadoras. Nível 2: POPs/sites. Nível 3: equipamentos críticos. Nível 4: interfaces ou elementos de acesso quando necessário. Isso reduz clutter e mantém a navegação coerente com a granularidade da decisão.

A linha também pode carregar informação

Em network maps, links e elementos podem mudar aparência conforme triggers e estado. Use isso para backbone e caminhos redundantes, mas mantenha uma legenda consistente. Se cor, espessura e estilo variam sem significado documentado, o mapa se torna arte, não telemetria.

Kiosk mode exige informação autoexplicativa

O modo kiosk remove elementos de navegação e é adequado para telas de NOC. Como ninguém estará clicando o tempo todo, títulos, unidades, contexto temporal e legendas precisam ser legíveis à distância. Texto pequeno e widgets densos que funcionam no notebook podem falhar completamente numa TV.

Um NOC bom não precisa estar permanentemente vermelho

Painéis devem mostrar normalidade com baixo ruído. Vermelho, laranja e animação devem ser reservados para exceções. Se todos os cards têm cor forte mesmo quando OK, o operador perde a capacidade de detectar mudança por percepção periférica.

Agrupe sintomas sob uma hipótese comum

Quando existe falha massiva de operadora, o painel deve mostrar o agregado primeiro e o detalhe abaixo. Isso reduz a tentação de tratar 29 links individualmente. O dashboard deve refletir a arquitetura de Services, tags e dependências já construída nas páginas anteriores.

Resumo sem caminho para detalhe vira painel decorativo

Todo KPI crítico deve permitir chegar ao conjunto que o originou: card da operadora → problemas da operadora → circuitos afetados → host/interface → Latest data/gráfico. O operador não deve precisar redescobrir filtros manualmente após perceber uma anomalia.

Mesma métrica deve ter mesma semântica em todos os painéis

Se verde significa “UP” num painel e “<80%” em outro, tudo bem desde que esteja explícito; porém a mesma dimensão deve manter unidade, escala e nomenclatura consistentes. Evite “Mbps”, “Mbit”, “Mb/s” e “bits/s” usados aleatoriamente para a mesma métrica.

Dashboard também precisa contar o que mudou

Estado atual é central no NOC, mas tendência ajuda a distinguir incidente súbito de degradação progressiva. Combine valor atual com histórico quando isso muda a decisão: potência óptica caindo lentamente, utilização crescendo ao longo de semanas ou latência degradando antes da queda.

Inclua uma página para a saúde do próprio monitoramento

Queue, proxies, preprocessing, banco, server processes, cache e alerting devem ter uma visão própria. Um NOC não pode confiar num dashboard que não informa se o sistema de monitoramento está parcialmente cego.

Uma proposta em cinco páginas

DASHBOARD: NOC

PÁGINA 1 — SITUAÇÃO GERAL
├── Problems High / Disaster
├── Problems by severity
├── Services críticos
├── Sites afetados
└── Saúde do Zabbix

PÁGINA 2 — WAN / OPERADORAS
├── Operadora A — UP / DOWN / %
├── Operadora B — UP / DOWN / %
├── Operadora C — UP / DOWN / %
├── mapa regional
└── problemas WAN

PÁGINA 3 — CORE / BACKBONE
├── network map
├── uplinks
├── BGP
├── perda / latência
└── top interfaces

PÁGINA 4 — ACESSO
├── OLTs
├── PONs
├── uplinks
├── óptico
└── problemas de acesso

PÁGINA 5 — CAPACIDADE
├── top utilização
├── top erros
├── trends
├── CPU / memória
└── crescimento

O que aparece sem rolar a tela

┌─────────────────────────────────────────────────────────┐
│ HIGH / DISASTER                                         │
│ 3 problemas críticos · 2 serviços afetados              │
└─────────────────────────────────────────────────────────┘

┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ OPERADORA A      │ │ OPERADORA B      │ │ OPERADORA C      │
│ 11/40 UP         │ │ 30/30 UP         │ │ 29/30 UP         │
│ DISASTER         │ │ OK               │ │ WARNING          │
└──────────────────┘ └──────────────────┘ └──────────────────┘

┌────────────────────────────┐ ┌────────────────────────────┐
│ PROBLEMAS CRÍTICOS         │ │ SITES AFETADOS            │
│ lista filtrada             │ │ ranking / mapa            │
└────────────────────────────┘ └────────────────────────────┘

Pergunta → widget

Visual para falha isolada versus falha massiva

Mapa bom responde “o que depende de quê?”

                    INTERNET
                       │
            ┌──────────┴──────────┐
            │                     │
         EDGE-01               EDGE-02
            │                     │
            └──────────┬──────────┘
                       │
                     CORE
             ┌─────────┼─────────┐
             │         │         │
           POP-A     POP-B     POP-C
             │         │         │
            OLT       OLT       OLT

Quando centenas de objetos precisam aparecer, crie mapas-filhos e navegação entre níveis em vez de reduzir tudo até ficar ilegível.

Use geografia quando localização muda a hipótese

Um cockpit reutilizável por host

HOST NAVIGATOR
      │
      ├────────► Host card
      ├────────► Problems
      ├────────► Item value — uptime
      ├────────► Graph — CPU
      ├────────► Graph — memória
      ├────────► Graph — tráfego
      └────────► Item history / sensores

Seleciona host uma vez
→ widgets compatíveis usam o host selecionado

Mesma janela temporal, múltiplas evidências

Período do dashboard: 14:00 → 15:00

Graph 1: tráfego WAN
Graph 2: perda ICMP
Graph 3: latência
Graph 4: errors/discards
Graph 5: CPU

Todos usam:
Time period = Dashboard

Resultado:
alterar o período uma vez
→ todos os gráficos navegam juntos

Painéis bonitos que atrapalham a operação

Construir um dashboard NOC mínimo

Teste o dashboard como ferramenta de decisão

Antes de publicar um dashboard

Base factual

Conteúdo construído a partir da documentação oficial Zabbix 7.4 sobre Dashboards, Dashboard widgets, parâmetros dinâmicos, período de tempo, Graph, Top items, Maps, Geomap, permissões e frontend Monitoring. A arquitetura de NOC, hierarquia visual, escolha de widgets, layouts, anti-patterns, laboratórios e recomendações operacionais são síntese editorial própria.

Linha Zabbix 7.4

Zabbix 7.4 ampliou widgets e mapas, incluindo item card/history, edição de widgets em tempo real e melhorias de elementos de mapas. Mantenha dashboards orientados à decisão.