Conceitos¶
Esta página define o vocabulário que aparece em toda a plataforma. Leitura rápida (10 minutos) que serve de referência para as outras docs.
Se você ainda não logou, comece pelo Primeiro acesso.
Visão de conjunto¶
A plataforma gira em torno de três ideias:
- Você tem recursos (servidores, bancos, containers, dispositivos) que precisam ser observados.
- Componentes chamados coletor e agente trazem dados desses recursos para a SpecialOne.
- Quando algo sai do esperado, a plataforma gera um alerta e roteia para os canais configurados pelas suas regras.
O restante da página detalha cada termo.
Tenant¶
Ambiente lógico isolado dentro da plataforma. Cada cliente, unidade de negócio ou ambiente (produção, homologação) costuma ser um tenant diferente.
Dados de um tenant nunca aparecem em outro: hosts, alertas, dashboards e regras ficam no escopo daquele tenant. Quando o seu usuário tem acesso a mais de um, a barra superior mostra o tenant atual e permite trocar. Veja Primeiro acesso → Trocar de tenant.
Hub (Coletor)¶
Serviço leve instalado na rede do cliente que conversa com a SpecialOne em nome do ambiente local. Também aparece em algumas telas como Collector.
O hub é o ponto de saída único de dados de monitoramento da sua rede para a plataforma. Ele:
- Recebe métricas dos agentes instalados nos hosts.
- Conecta direto em bancos, APIs, storages e dispositivos de rede que não têm agente.
- Mantém uma fila local caso a comunicação com a SpecialOne caia, sem perder coleta.
Ambientes simples usam um hub só. Redes segmentadas (DMZ, datacenters em locais físicos diferentes) costumam ter mais de um.
Agente¶
Software instalado dentro de um host Linux ou Windows que coleta métricas locais (CPU, memória, disco, processos, serviços, logs) e envia para o hub.
O agente é a forma padrão de monitorar servidores. Para bancos, APIs e dispositivos de rede a coleta é feita direto pelo hub via protocolo nativo (SNMP, JDBC, HTTPS), sem agente.
Host¶
Qualquer recurso monitorado pela plataforma. O termo cobre vários tipos:
- Servidores físicos ou virtuais (Linux, Windows).
- Bancos de dados.
- Containers (nós Docker, clusters Kubernetes).
- Dispositivos de rede (switches, roteadores, firewalls).
- Aparelhos de DCIM (nobreaks, ar condicionado).
- Checagens sintéticas (URLs públicas).
Cada host tem um nome, tipo, conjunto de métricas sendo coletadas e um conjunto de alertas que avaliam essas métricas.
Métrica¶
Cada leitura individual coletada de um host. CPU média do último minuto é uma métrica. Espaço livre em /var é outra. Latência média da última transação no banco é outra.
Métricas têm um nome, intervalo de coleta e unidade. Você raramente cria métricas manualmente: elas vêm prontas dos perfis de monitoramento aplicados ao host.
A lista de métricas ativas de um host fica em Infraestrutura → Hosts → (host) → Configuração → Métricas Coletadas.
Alerta¶
Tem dois sentidos na plataforma, ambos chamados alerta:
- Definição do alerta: regra que combina uma ou mais métricas com uma condição (ex: "CPU acima de 90% por 5 minutos"). É o que você cria, edita e desabilita.
- Alerta em aberto (também aparece como problema em algumas telas): evento gerado quando a condição da definição é atendida. É o que você trata no dia a dia.
Toda definição de alerta tem:
- Mensagem descrevendo a condição (ex: "High CPU utilization").
- Severidade (informação, médio, alto, crítico).
- Host ao qual está associada.
- Tags para roteamento e filtragem.
- Estado: habilitado ou desabilitado.
Quando dispara, o alerta em aberto recebe ainda um início e, quando resolvido, um fim.
Os alertas em aberto aparecem em três lugares principais: cartões do Painel de Controle, página Alertas (em aberto agora) e Histórico de Alertas (já resolvidos).
Severidade¶
Nível de gravidade de um alerta. A plataforma usa quatro:
| Severidade | Quando usar | Exemplo típico |
|---|---|---|
| Informação | Sinal que vale acompanhar sem urgência. | Job de backup finalizou. |
| Médio | Condição anormal, sem impacto imediato no usuário final. | Tempo de resposta acima da média. |
| Alto | Degradação real, exige tratamento rápido. | Réplica de banco fora de sincronia. |
| Crítico | Indisponibilidade ou risco iminente. | Host fora do ar, fila travada. |
A severidade orienta para qual canal e em qual horário o alerta deve ser entregue. Isso é decidido pelas regras de notificação.
Perfil de monitoramento¶
Conjunto reutilizável de métricas e alertas aplicado a hosts do mesmo tipo. "Linux server", "MySQL", "Switch Cisco" são exemplos de perfis.
Quando você cadastra um host novo e atribui um perfil, ele herda automaticamente as métricas e alertas daquele perfil. Mudanças no perfil se propagam para os hosts que o usam.
Edição local clona do perfil
Ao editar uma métrica ou alerta pela tela de um host específico, a plataforma cria uma cópia local daquela definição naquele host. Essa cópia para de receber atualizações do perfil. É útil para fazer um ajuste pontual sem afetar todos os hosts, mas vale lembrar para não esquecer um host preso a uma versão antiga do perfil.
Canal de notificação¶
Destino para onde os alertas saem da plataforma. Cada canal é uma integração configurada: Slack, Microsoft Teams, Telegram, WhatsApp, email, webhook, push no app mobile.
Você pode ter quantos canais quiser. Times costumam ter canais separados por área (infra, banco, rede) para não inundar um único Slack com tudo.
Regra de notificação¶
Define qual alerta vai para qual canal e quando. Uma regra combina condições (severidade, tags, hosts, horário) com um ou mais canais de destino.
Exemplos:
- Tudo "crítico" de banco vai para o Slack #db-oncall, sem janela de silêncio.
- Tudo "médio" de infra cai no email do time, só em horário comercial.
- Webhook do ITSM recebe "alto" e "crítico" para abrir ticket automático.
Regras são o que evita o famoso "ninguém viu o alerta porque foi no canal errado".
Manutenção¶
Janela de tempo em que alertas de um conjunto de hosts são suprimidos (não geram notificação). Útil para deploys, troca de hardware, ajustes planejados.
Durante a manutenção a plataforma continua coletando dados, mas não dispara avisos para os canais. Quando a janela termina, o comportamento volta ao normal automaticamente.
Dashboard¶
Painel visual personalizado com gráficos, contadores e listas. A plataforma já entrega o Painel de Controle pronto (visão geral do ambiente), e cada usuário pode montar dashboards próprios em Meus Dashboards.
Discovery¶
Processo automático que encontra recursos novos no ambiente sem você precisar cadastrar um a um. Pode descobrir:
- Hosts em uma faixa de rede.
- Bancos em um servidor já monitorado.
- Containers em um cluster Kubernetes.
Após a descoberta, os recursos aparecem para revisão antes de entrarem no monitoramento regular. Você decide o que aceita.
Trilha de auditoria¶
Registro do que cada usuário fez na plataforma: quem criou ou editou um canal, quem suprimiu um alerta, quem alterou uma regra. Disponível em Administração → Trilha de Auditoria.
Onde isso aparece¶
| Termo | Onde você encontra na UI |
|---|---|
| Tenant | Barra superior, ao lado do nome do usuário. |
| Hub, Agente | Administração → Agentes & Hubs. |
| Host | Infraestrutura → Hosts, Aplicações → Bancos de dados e congêneres. |
| Métrica, Alerta | Dentro do detalhe de um host, sub-abas Métricas Coletadas e Alertas Configurados na aba Configuração. |
| Alerta em aberto | Observar & Explorar → Alertas (abertos) e Histórico. |
| Canal, Regra | Notificações → Canais e Notificações → Regras. |
| Manutenção | Administração → Manutenções. |
| Dashboard | Painel de Controle e Meus Dashboards. |
Próximos passos¶
-
Quickstart
Coloque esses conceitos em prática num tour guiado de 15 minutos pela interface.
-
Adicionar um host
Instale o agente em um servidor e veja as métricas chegando no painel.