Surveillance et alertes de performance réseau Meraki

Meraki Network Monitor

Surveille automatiquement la latence et le taux de perte de paquets du réseau Cisco Meraki. Envoie des alertes via Teams lorsque les performances dépassent les seuils définis, et utilise Redis pour éviter les notifications en double.

23 NodesIndustry Verticalsurveillance réseau alertes de performance Meraki

Aperçu du workflow

Ce workflow n8n constitue un système de surveillance et d’alerte réseau Cisco Meraki, conçu pour surveiller automatiquement les indicateurs de performance réseau (latence et taux de perte de paquets) et envoyer des notifications d’alerte en cas de détection d’anomalies. Le workflow récupère, via l’API Meraki, les données relatives aux organisations, réseaux et statistiques des liaisons montantes, calcule des indicateurs moyens de performance, filtre les sites problématiques et envoie des alertes via Microsoft Teams, tout en utilisant une base de données Redis pour éviter les doublons d’alertes.

Structure du workflow

1. Nœuds déclencheurs

Noms des nœuds :

  • When clicking "Execute Workflow" (déclencheur manuel)
  • Schedule Trigger (déclencheur planifié)

Description fonctionnelle : Ce workflow prend en charge deux modes de déclenchement :

  • Exécution manuelle : déclenchée en cliquant sur le bouton « Exécuter le workflow »
  • Exécution planifiée : exécutée automatiquement selon un calendrier prédéfini (pour une surveillance continue)

2. Phase de collecte des données

2.1 Récupération des informations sur les organisations Meraki

Nom du nœud : Get Meraki Organizations

Description fonctionnelle :

  • Appel de l’API Meraki via une requête HTTP (https://api.meraki.com/api/v1/organizations)
  • Authentification par en-tête HTTP, nécessitant une clé API Meraki configurée
  • Récupération de la liste complète des organisations accessibles au compte

Détails techniques :

  • Type de requête : GET
  • Méthode d’authentification : Authentification par en-tête HTTP
  • En-têtes requis :
    • Authorization : pour l’authentification
    • Accept: application/json : pour spécifier le format JSON en réponse

2.2 Mise en forme des données organisationnelles

Nom du nœud : Get Org Name & ID

Description fonctionnelle :

  • Extraction et renommage des champs clés à l’aide d’un nœud Set
  • Extraction depuis les données brutes :
    • CompanyName : nom de l’organisation
    • OrgID : identifiant de l’organisation

2.3 Récupération des identifiants de réseau

Nom du nœud : Get Network IDs

Description fonctionnelle :

  • Pour chaque identifiant d’organisation, appel de l’API pour obtenir tous les réseaux associés
  • URL dynamique utilisée : https://api.meraki.com/api/v1/organizations/{{ $json.OrgID }}/networks
  • Fournit la liste des réseaux nécessaire à la surveillance ultérieure

2.4 Mise en forme des variables réseau

Nom du nœud : Sets Network Variables

Description fonctionnelle :

  • Extraction et formatage des informations réseau
  • Inclut des champs clés tels que le nom du réseau, son identifiant et son URL

2.5 Récupération des statistiques de liaison montante

Nom du nœud : Get Uplink Loss and Latency

Description fonctionnelle :

  • Obtention des statistiques de performance des liaisons montantes des équipements réseau
  • Comprend :
    • Taux de perte de paquets en pourcentage (Loss Percent)
    • Latence en millisecondes (Latency Ms)
    • Données temporelles (5 derniers points dans le temps)

3. Phase de traitement et d’analyse des données

3.1 Fusion des données

Nom du nœud : Combine latency to its respective Network

Description fonctionnelle :

  • Utilisation d’un nœud Merge pour combiner les informations réseau et les données de performance
  • Champ de correspondance : NetworkID ↔ networkId
  • Mode de fusion : enrichInput1 (enrichissement des données de l’entrée 1)

3.2 Restructuration des données

Nom du nœud : Makes Latency and Loss Filterable

Description fonctionnelle :

  • Réorganisation de la structure des données afin de faciliter le filtrage et l’analyse de la latence et des pertes
  • Extraction des 5 points temporels :
    • TS0-Loss à TS4-Loss : taux de perte pour les 5 instants
    • TS0-Latency à TS4-Latency : latence pour les 5 instants
  • Conservation des métadonnées : nom du réseau, numéro de série, URL, etc.

3.3 Calcul des moyennes

Nom du nœud : Average Latency & Loss over 5m

Description fonctionnelle :

  • Calcul, via un script JavaScript, des moyennes sur les 5 derniers points temporels
  • Calcul de deux indicateurs clés :
    • AverageLoss : taux moyen de perte de paquets
    • AverageLatency : latence moyenne (en millisecondes)
  • Ces moyennes permettent une détection plus fiable des problèmes de performance

Logique du code :

// Calcul du total des pertes et de la latence sur les 5 points
// Division par 5 pour obtenir la moyenne
// Ajout des résultats à l’élément de données

3.4 Filtrage des sites problématiques

Nom du nœud : Filters Problematic sites

Description fonctionnelle :

  • Filtrage, via JavaScript, des sites dépassant les seuils définis
  • Critères de seuil :
    • Latence moyenne > 300 ms
    • ou Taux moyen de perte > 2 %
  • Seuls les sites satisfaisant à l’une ou l’autre condition sont transmis à l’étape suivante

Logique de filtrage :

// Si AverageLatency > 300 ou AverageLoss > 2
// alors le site est marqué comme problématique

4. Phase de déduplication et de notification d’alerte

4.1 Vérification de l’existence d’une alerte

Nom du nœud : Check if Alert Exists

Description fonctionnelle :

  • Interrogation de la base Redis pour vérifier si une alerte a déjà été envoyée pour ce réseau
  • Utilisation du nom du réseau comme clé
  • Si la clé existe, cela signifie qu’une alerte a déjà été envoyée (dans la durée TTL)

4.2 Création de la réponse

Nom du nœud : Create Response

Description fonctionnelle :

  • Traitement, via JavaScript, du résultat de la requête Redis
  • Conversion du résultat en valeur booléenne ou indicateur exploitable
  • Détermination de la nécessité d’envoyer une nouvelle alerte

4.3 Fusion avec déduplication

Nom du nœud : Merge

Description fonctionnelle :

  • Fusion des sites problématiques avec les données d’alertes existantes
  • Champ de correspondance : NetworkName
  • Mode de fusion : conservation de tous les éléments non appariés
  • Logique clé : si le nom du réseau correspond, l’alerte existe déjà et ne sera pas renvoyée ; seuls les nouveaux problèmes (non appariés) poursuivent le flux

4.4 Envoi du message Teams

Nom du nœud : Message Techs

Description fonctionnelle :

  • Envoi d’un message d’alerte via un webhook Microsoft Teams
  • Contenu du message :
    • Nom du réseau
    • Données moyennes de latence et de perte
    • URL du réseau (sous forme de lien cliquable pour accéder directement au site concerné)
  • Notification de l’équipe technique sur le dépassement des seuils de performance

4.5 Enregistrement du journal d’alerte

Nom du nœud : Log the Alert

Description fonctionnelle :

  • Enregistrement de l’alerte dans la base Redis
  • Définition d’un TTL (Time To Live) de 3 heures
  • Logique anti-doublon : si le problème persiste sur le même site sans être résolu pendant 3 heures, une nouvelle alerte sera envoyée après expiration du TTL

5. Nœuds d’information complémentaires

Le workflow inclut plusieurs nœuds Sticky Note (notes adhésives) fournissant des instructions détaillées :

  • Sticky Note3 : explique comment configurer l’authentification API Meraki
  • Sticky Note4 : décrit la logique de fusion des données et de calcul statistique
  • Sticky Note5 : détaille le mécanisme de déduplication des alertes et le processus de notification
  • Sticky Note6 : propose d’autres scénarios d’utilisation (ex. : intégration avec des outils PSA pour créer des tickets)

Schéma du workflow

[Déclencheur] → [Obtenir les organisations] → [Mettre en forme les données org.] → [Obtenir les ID réseau] → [Mettre en forme les données réseau]
                ↓                                                                                          ↓
          [Obtenir les données de liaison montante] ----------------------------------------------------→ [Fusionner les données]
                                                                                                            ↓
                                                                                           [Restructurer données latence/perte]
                                                                                                            ↓
                                                                                              [Calculer moyenne sur 5 min]
                                                                                                            ↓
                                                                                             [Filtrer les sites problématiques]
                                                                                                            ↓
                                                         [Vérifier existence alerte] ← → [Fusion avec déduplication]
                                                                 ↓                              ↓
                                                         [Créer réponse] ----------------------→ [Envoyer message Teams]
                                                                                                            ↓
                                                                                                  [Enregistrer alerte]

Points techniques clés

1. Authentification API

2. Seuils de performance

  • Seuil de latence : 300 ms
  • Seuil de perte : 2 %
  • Ces seuils peuvent être ajustés selon les besoins

3. Mécanisme anti-doublon des alertes

  • Stockage des alertes envoyées dans Redis
  • TTL fixé à 3 heures
  • Aucune alerte redondante pour un même site pendant la durée du TTL

4. Méthodes de traitement des données

  • Collecte des données sur les 5 derniers points temporels
  • Calcul de moyennes pour atténuer les fluctuations ponctuelles
  • Utilisation de nœuds Code (JavaScript) pour le traitement complexe et le filtrage

Cas d’usage

  1. Surveillance de la performance réseau : suivi continu de la latence et des pertes sur les réseaux Meraki
  2. Alertes proactives : notification automatique de l’équipe technique en cas de dégradation
  3. Dépannage : lien direct vers l’URL du réseau pour localiser rapidement le problème
  4. Gestion des alertes : prévention du « bombardement d’alertes », une seule alerte par site toutes les 3 heures

Suggestions d’extension

Selon les indications du Sticky Note6, les extensions suivantes sont possibles :

  1. Intégration avec un système PSA : remplacer le nœud Teams par un outil PSA (ex. : ConnectWise Manage) pour créer automatiquement des tickets plutôt que des messages
  2. Notifications multi-canaux : ajouter des canaux supplémentaires comme e-mail, Slack, etc.
  3. Seuils personnalisés : définir des seuils de performance différents selon les réseaux
  4. Stockage historique : archiver les données de surveillance dans une base de données pour analyse long terme et prévision des tendances

Conclusion

Il s’agit d’un workflow complet d’automatisation de surveillance réseau, exploitant pleinement les capacités de n8n :

  • Intégration d’API externes via requêtes HTTP
  • Transformation et traitement des données (nœuds Set, Code)
  • Fusion de données (nœud Merge)
  • Filtrage conditionnel et logique décisionnelle
  • Notifications externes (webhook Teams)
  • Persistance des données (Redis)

Grâce à cette automatisation et à des alertes intelligentes, l’efficacité de la gestion réseau est considérablement améliorée, réduisant ainsi la charge liée aux vérifications manuelles.