Monitoramento e alertas de desempenho da rede Meraki
Meraki Network Monitor
Monitora automaticamente a latência e a taxa de perda de pacotes da rede Cisco Meraki, enviando alertas pelo Teams quando o desempenho exceder os limites definidos, utilizando Redis para evitar notificações duplicadas.
Visão Geral do Fluxo de Trabalho
Este fluxo de trabalho n8n é um sistema de monitoramento e alerta de rede Cisco Meraki, projetado para monitorar automaticamente métricas de desempenho da rede (latência e taxa de perda de pacotes) e enviar notificações de alerta quando forem detectados problemas. O fluxo obtém dados de organizações, redes e estatísticas de uplink por meio da API Meraki, calcula métricas médias de desempenho, filtra locais com problemas e envia alertas via Microsoft Teams, utilizando ainda um banco de dados Redis para evitar alertas duplicados.
Estrutura do Fluxo de Trabalho
1. Nó Gatilho
Nomes dos Nós:
When clicking "Execute Workflow"(gatilho manual)Schedule Trigger(gatilho agendado)
Descrição da Funcionalidade: Este fluxo suporta dois modos de acionamento:
- Execução manual: ativado ao clicar no botão "Executar Fluxo de Trabalho"
- Execução agendada: executado automaticamente conforme programação pré-definida (para monitoramento contínuo)
2. Fase de Coleta de Dados
2.1 Obter Informações das Organizações Meraki
Nome do Nó: Get Meraki Organizations
Descrição da Funcionalidade:
- Realiza uma requisição HTTP à API Meraki (
https://api.meraki.com/api/v1/organizations) - Utiliza autenticação por cabeçalho (Header), exigindo a configuração de uma chave de API Meraki
- Obtém a lista de todas as organizações às quais a conta tem acesso
Detalhes Técnicos:
- Tipo de requisição: GET
- Método de autenticação: Autenticação por Cabeçalho HTTP
- Cabeçalhos obrigatórios:
Authorization: para autenticaçãoAccept: application/json: especifica que os dados devem ser retornados em formato JSON
2.2 Organizar Dados das Organizações
Nome do Nó: Get Org Name & ID
Descrição da Funcionalidade:
- Utiliza o nó Set para extrair e renomear campos-chave
- Extrai dos dados brutos:
CompanyName: nome da organizaçãoOrgID: ID da organização
2.3 Obter IDs de Rede
Nome do Nó: Get Network IDs
Descrição da Funcionalidade:
- Para cada ID de organização, chama a API para obter todas as redes associadas
- Utiliza URL dinâmica:
https://api.meraki.com/api/v1/organizations/{{ $json.OrgID }}/networks - Fornece a lista de redes necessária para o monitoramento subsequente
2.4 Organizar Variáveis de Rede
Nome do Nó: Sets Network Variables
Descrição da Funcionalidade:
- Extrai e formata informações de rede
- Inclui campos essenciais como nome da rede, ID da rede e URL da rede
2.5 Obter Estatísticas de Uplink
Nome do Nó: Get Uplink Loss and Latency
Descrição da Funcionalidade:
- Obtém estatísticas de desempenho do uplink dos dispositivos de rede
- Inclui:
- Percentual de perda de pacotes (Loss Percent)
- Latência em milissegundos (Latency Ms)
- Dados em série temporal (últimos 5 pontos temporais)
3. Fase de Processamento e Análise de Dados
3.1 Mesclar Dados
Nome do Nó: Combine latency to its respective Network
Descrição da Funcionalidade:
- Usa o nó Merge para combinar informações de rede com estatísticas de desempenho
- Campo de correspondência:
NetworkIDcomnetworkId - Modo de mesclagem: enrichInput1 (enriquecer dados da entrada 1)
3.2 Reestruturar Dados
Nome do Nó: Makes Latency and Loss Filterable
Descrição da Funcionalidade:
- Reorganiza a estrutura dos dados para facilitar filtragem e análise de latência e perda
- Extrai 5 pontos de dados em série temporal:
TS0-LossaTS4-Loss: taxas de perda nos 5 pontos temporaisTS0-LatencyaTS4-Latency: latências nos 5 pontos temporais
- Mantém metadados como nome da rede, número de série e URL
3.3 Calcular Médias
Nome do Nó: Average Latency & Loss over 5m
Descrição da Funcionalidade:
- Utiliza código JavaScript para calcular a média dos últimos 5 pontos temporais
- Calcula duas métricas principais:
AverageLoss: taxa média de perda de pacotesAverageLatency: latência média (em milissegundos)
- Essas médias permitem identificar problemas de desempenho com maior precisão
Lógica do Código:
// Calcula a soma total da perda e da latência nos 5 pontos temporais
// Divide por 5 para obter a média
// Adiciona os resultados aos itens de dados
3.4 Filtrar Locais com Problemas
Nome do Nó: Filters Problematic sites
Descrição da Funcionalidade:
- Usa código JavaScript para filtrar locais cujas métricas ultrapassem os limites definidos
- Critérios de limite:
- Latência média > 300 ms
- ou Perda média > 2%
- Apenas locais que atendam a pelo menos um critério avançam para a próxima etapa
Lógica de Filtragem:
// Se AverageLatency > 300 ou AverageLoss > 2
// então o local é marcado como problemático
4. Fase de Desduplicação e Notificação de Alertas
4.1 Verificar se o Alerta Já Existe
Nome do Nó: Check if Alert Exists
Descrição da Funcionalidade:
- Consulta o banco de dados Redis para verificar se já foi enviado um alerta para essa rede
- Usa o nome da rede como chave
- Se a chave existir, significa que um alerta já foi enviado (dentro do período TTL)
4.2 Criar Dados de Resposta
Nome do Nó: Create Response
Descrição da Funcionalidade:
- Usa JavaScript para processar o resultado da consulta ao Redis
- Converte o resultado em um valor booleano ou identificador utilizável
- Determina se é necessário enviar um novo alerta
4.3 Mesclar para Desduplicação
Nome do Nó: Merge
Descrição da Funcionalidade:
- Combina dados de locais problemáticos com informações sobre alertas já existentes
- Campo de correspondência:
NetworkName - Modo de mesclagem: mantém todos os itens sem correspondência
- Lógica-chave: se houver correspondência no nome da rede, o alerta já existe e não será reenviado; apenas novos problemas (sem correspondência) prosseguem
4.4 Enviar Mensagem no Teams
Nome do Nó: Message Techs
Descrição da Funcionalidade:
- Envia mensagem de alerta via webhook do Microsoft Teams
- Conteúdo da mensagem inclui:
- Nome da rede
- Dados médios de latência e perda de pacotes
- URL da rede (como link clicável para acesso direto ao local com problema)
- Notifica a equipe técnica sobre locais com desempenho abaixo do esperado
4.5 Registrar Log do Alerta
Nome do Nó: Log the Alert
Descrição da Funcionalidade:
- Registra o alerta no banco de dados Redis
- Define TTL (tempo de vida) de 3 horas
- Lógica anti-duplicação: se o mesmo problema persistir na mesma rede por mais de 3 horas sem resolução, um novo alerta será enviado após esse período
5. Nós de Observação Auxiliares
O fluxo contém diversos nós Sticky Note (notas adesivas) com instruções detalhadas:
- Sticky Note3: explica como configurar a autenticação da API Meraki
- Sticky Note4: descreve a lógica de mesclagem de dados e cálculo estatístico
- Sticky Note5: detalha o mecanismo de desduplicação de alertas e o fluxo de notificação
- Sticky Note6: sugere outros cenários de uso (por exemplo, integração com ferramentas PSA para criação automática de chamados)
Diagrama do Fluxo de Trabalho
[Gatilho] → [Obter Organizações] → [Organizar Dados da Organização] → [Obter IDs de Rede] → [Organizar Dados de Rede]
↓ ↓
[Obter Dados de Uplink] ----------------------------------------------------------→ [Mesclar Dados]
↓
[Reestruturar Dados de Latência/Perda]
↓
[Calcular Média de 5 Minutos]
↓
[Filtrar Locais com Problemas]
↓
[Verificar Existência de Alerta] ← → [Mesclar para Desduplicação]
↓ ↓
[Criar Resposta] ----------------------------→ [Enviar Mensagem no Teams]
↓
[Registrar Log do Alerta]
Pontos Técnicos Essenciais
1. Autenticação na API
- É necessário gerar uma chave de API no Meraki Dashboard
- Documentação de referência: https://documentation.meraki.com/General_Administration/Other_Topics/Cisco_Meraki_Dashboard_API
- Utiliza autenticação por cabeçalho HTTP
2. Limites de Desempenho
- Limite de latência: 300 milissegundos
- Limite de perda de pacotes: 2%
- Esses limites podem ser ajustados conforme as necessidades reais
3. Mecanismo Anti-Duplicação de Alertas
- Usa Redis para armazenar alertas já enviados
- TTL definido como 3 horas
- Durante o período TTL, alertas duplicados para o mesmo local não são reenviados
4. Métodos de Processamento de Dados
- Coleta dados dos últimos 5 pontos temporais
- Calcula médias para reduzir o impacto de flutuações momentâneas
- Utiliza nós de código JavaScript para processamento complexo e filtragem de dados
Casos de Uso
- Monitoramento de desempenho de rede: monitoramento contínuo da latência e perda de pacotes nas redes Meraki
- Alertas proativos: notificação automática à equipe técnica quando há degradação de desempenho
- Solução de problemas: fornece link direto para a URL da rede, permitindo localização rápida do problema
- Gestão de alertas: evita "bombardeio" de alertas, enviando apenas uma notificação a cada 3 horas por local
Sugestões de Expansão
Conforme indicado no Sticky Note6, é possível realizar as seguintes expansões:
- Integração com sistemas PSA: substituir o nó de mensagem do Teams por um nó de ferramenta PSA (ex.: ConnectWise Manage) para criar chamados automaticamente em vez de apenas enviar mensagens
- Notificação multicanal: além do Teams, adicionar canais como e-mail, Slack etc.
- Limites personalizados: definir diferentes limites de desempenho para redes distintas
- Armazenamento histórico: salvar os dados de monitoramento em um banco de dados para análise de longo prazo e previsão de tendências
Conclusão
Trata-se de um fluxo de trabalho automatizado completo de monitoramento de rede, que aproveita plenamente as seguintes capacidades do n8n:
- Integração com APIs externas via requisições HTTP
- Transformação e processamento de dados (nós Set e Code)
- Mesclagem de dados (nó Merge)
- Filtragem condicional e tomada de decisões lógicas
- Notificações externas (webhook do Teams)
- Persistência de dados (Redis)
Por meio do monitoramento automatizado e alertas inteligentes, este fluxo aumenta significativamente a eficiência da operação de redes, reduzindo drasticamente a necessidade de verificações manuais.