Überwachung und Alarmierung der Meraki-Netzwerkleistung

Meraki Network Monitor

Überwacht automatisch Latenz und Paketverlust im Cisco-Meraki-Netzwerk. Sendet bei Überschreitung festgelegter Schwellenwerte Alarmmeldungen über Teams und verhindert mithilfe von Redis doppelte Benachrichtigungen.

23 NodesIndustry VerticalNetzwerküberwachung Leistungsalarm Meraki

Workflow-Übersicht

Dieser n8n-Workflow ist ein Cisco Meraki Netzwerküberwachungs- und Alarmierungssystem, das automatisch Netzwerkleistungsmetriken (Latenz und Paketverlustrate) überwacht und bei erkannten Problemen Alarmbenachrichtigungen versendet. Der Workflow ruft über die Meraki-API Organisations-, Netzwerk- und Uplink-Statistikdaten ab, berechnet durchschnittliche Leistungskennzahlen, filtert problematische Standorte heraus und sendet Alarmmeldungen über Microsoft Teams, wobei gleichzeitig eine Redis-Datenbank zur Vermeidung von doppelten Alarmen genutzt wird.

Workflow-Struktur

1. Auslöserknoten

Knotennamen:

  • When clicking "Execute Workflow" (Manueller Auslöser)
  • Schedule Trigger (Zeitplanbasierter Auslöser)

Funktionsbeschreibung: Der Workflow unterstützt zwei Auslösemethoden:

  • Manuelle Ausführung: Durch Klicken auf den Button „Workflow ausführen“
  • Zeitgesteuerte Ausführung: Automatische Ausführung gemäß vorgegebenem Zeitplan (für kontinuierliche Überwachung)

2. Datenerfassungsphase

2.1 Abruf der Meraki-Organisationsinformationen

Knotenname: Get Meraki Organizations

Funktionsbeschreibung:

  • HTTP-Anfrage an die Meraki-API (https://api.meraki.com/api/v1/organizations)
  • Authentifizierung über Header; hierfür ist ein Meraki-API-Schlüssel erforderlich
  • Ruft eine Liste aller Organisationen ab, auf die das Konto Zugriff hat

Technische Details:

  • Anfragetyp: GET
  • Authentifizierungsmethode: HTTP-Header-Auth
  • Erforderliche Header:
    • Authorization: Für die Authentifizierung
    • Accept: application/json: Gibt an, dass JSON-Daten zurückgegeben werden sollen

2.2 Aufbereitung der Organisationsdaten

Knotenname: Get Org Name & ID

Funktionsbeschreibung:

  • Nutzt einen Set-Knoten, um wichtige Felder zu extrahieren und umzubenennen
  • Extrahiert aus den Rohdaten:
    • CompanyName: Organisationsname
    • OrgID: Organisations-ID

2.3 Abruf der Netzwerk-IDs

Knotenname: Get Network IDs

Funktionsbeschreibung:

  • Ruft für jede Organisations-ID über die API alle zugehörigen Netzwerke ab
  • Verwendet dynamische URL: https://api.meraki.com/api/v1/organizations/{{ $json.OrgID }}/networks
  • Stellt eine Netzwerkliste für die anschließende Überwachung bereit

2.4 Aufbereitung der Netzwerkvariablen

Knotenname: Sets Network Variables

Funktionsbeschreibung:

  • Extrahiert und formatiert Netzwerkinformationen
  • Enthält wichtige Felder wie Netzwerkname, Netzwerk-ID und Netzwerk-URL

2.5 Abruf der Uplink-Statistikdaten

Knotenname: Get Uplink Loss and Latency

Funktionsbeschreibung:

  • Ruft Leistungsstatistiken der Netzwerkgeräte für die Uplinks ab
  • Enthält:
    • Paketverlustrate in Prozent (Loss Percent)
    • Latenz in Millisekunden (Latency Ms)
    • Zeitreihendaten (der letzten 5 Zeitpunkte)

3. Datenverarbeitungs- und Analysephase

3.1 Datenzusammenführung

Knotenname: Combine latency to its respective Network

Funktionsbeschreibung:

  • Nutzt einen Merge-Knoten, um Netzwerkinformationen mit Leistungsstatistikdaten zu verbinden
  • Übereinstimmungsfeld: NetworkID mit networkId
  • Zusammenführungsmodus: enrichInput1 (Anreicherung der Eingabedaten 1)

3.2 Datenrestrukturierung

Knotenname: Makes Latency and Loss Filterable

Funktionsbeschreibung:

  • Reorganisiert die Datenstruktur, um Latenz- und Paketverlustdaten besser filterbar und analysierbar zu machen
  • Extrahiert 5 Zeitreihendatenpunkte:
    • TS0-Loss bis TS4-Loss: Paketverlustraten der 5 Zeitpunkte
    • TS0-Latency bis TS4-Latency: Latenzen der 5 Zeitpunkte
  • Behält Metadaten wie Netzwerkname, Seriennummer und URL bei

3.3 Berechnung der Durchschnittswerte

Knotenname: Average Latency & Loss over 5m

Funktionsbeschreibung:

  • Berechnet mithilfe von JavaScript-Code den Durchschnitt der letzten 5 Zeitpunkte
  • Berechnet zwei Schlüsselmetriken:
    • AverageLoss: Durchschnittliche Paketverlustrate
    • AverageLatency: Durchschnittliche Latenz (in Millisekunden)
  • Diese Durchschnittswerte dienen einer genaueren Identifikation von Leistungsproblemen

Code-Logik:

// Summiert Paketverlust und Latenz über 5 Zeitpunkte
// Teilt durch 5, um den Durchschnitt zu erhalten
// Fügt das Ergebnis dem Datensatz hinzu

3.4 Filterung problematischer Standorte

Knotenname: Filters Problematic sites

Funktionsbeschreibung:

  • Filtert mithilfe von JavaScript-Code Standorte heraus, die Schwellenwerte überschreiten
  • Schwellenwertkriterien:
    • Durchschnittslatenz > 300 ms
    • oder durchschnittliche Paketverlustrate > 2 %
  • Nur Standorte, die mindestens eines dieser Kriterien erfüllen, werden an den nächsten Schritt weitergeleitet

Filterlogik:

// Wenn AverageLatency > 300 oder AverageLoss > 2
// wird der Standort als problematisch markiert

4. Alarm-Deduplizierung und Benachrichtigungsphase

4.1 Prüfung, ob Alarm bereits existiert

Knotenname: Check if Alert Exists

Funktionsbeschreibung:

  • Fragt die Redis-Datenbank ab, ob für dieses Netzwerk bereits ein Alarm gesendet wurde
  • Verwendet den Netzwerknamen als Schlüssel
  • Existiert der Schlüssel, wurde innerhalb der TTL-Zeit bereits ein Alarm gesendet

4.2 Erstellung der Antwortdaten

Knotenname: Create Response

Funktionsbeschreibung:

  • Verarbeitet das Abfrageergebnis aus Redis mittels JavaScript
  • Wandelt das Ergebnis in einen verwendbaren booleschen Wert oder Kennzeichner um
  • Bestimmt, ob ein neuer Alarm gesendet werden muss

4.3 Deduplizierung durch Zusammenführung

Knotenname: Merge

Funktionsbeschreibung:

  • Führt problematische Standorte mit bereits bestehenden Alarmdaten zusammen
  • Übereinstimmungsfeld: NetworkName
  • Zusammenführungsmodus: Alle nicht übereinstimmenden Elemente beibehalten
  • Wesentliche Logik: Bei Übereinstimmung des Netzwerknamens existiert bereits ein Alarm – kein erneuter Versand. Nur nicht übereinstimmende (d. h. neue Probleme) werden weitergeleitet

4.4 Versand der Teams-Nachricht

Knotenname: Message Techs

Funktionsbeschreibung:

  • Sendet Alarmmeldungen über einen Microsoft Teams-Webhook
  • Nachrichteninhalt umfasst:
    • Netzwerkname
    • Durchschnittsdaten zu Latenz und Paketverlustrate
    • Netzwerk-URL (als Hyperlink, direkter Sprung zum betroffenen Standort möglich)
  • Informiert das technische Team über überschrittene Leistungsschwellenwerte

4.5 Protokollierung des Alarms

Knotenname: Log the Alert

Funktionsbeschreibung:

  • Speichert den Alarm in der Redis-Datenbank
  • Setzt eine TTL (Time-to-Live) von 3 Stunden
  • Deduplizierungslogik: Falls das Problem am selben Standort innerhalb von 3 Stunden nicht behoben wird, wird nach Ablauf der 3 Stunden erneut ein Alarm gesendet

5. Hilfestellende Hinweisknoten

Der Workflow enthält mehrere Sticky-Note-Knoten (Haftnotizen) mit detaillierten Anleitungen:

  • Sticky Note3: Erläutert die Konfiguration der Meraki-API-Authentifizierung
  • Sticky Note4: Beschreibt die Logik hinter Datenzusammenführung und statistischer Berechnung
  • Sticky Note5: Erläutert detailliert den Mechanismus zur Alarm-Deduplizierung und den Benachrichtigungsablauf
  • Sticky Note6: Empfiehlt weitere Anwendungsszenarien (z. B. Integration in PSA-Tools zur Ticket-Erstellung)

Workflow-Diagramm

[Auslöser] → [Organisationen abrufen] → [Organisationsdaten aufbereiten] → [Netzwerk-IDs abrufen] → [Netzwerkdaten aufbereiten]
                ↓                                                                                      ↓
          [Uplink-Daten abrufen] --------------------------------------------------------------→ [Daten zusammenführen]
                                                                                                      ↓
                                                                                        [Latenz- und Verlustdaten restrukturieren]
                                                                                                      ↓
                                                                                           [5-Minuten-Durchschnitt berechnen]
                                                                                                      ↓
                                                                                          [Problematische Standorte filtern]
                                                                                                      ↓
                                            [Alarm vorhanden?] ← → [Deduplizierung durch Zusammenführen]
                                                    ↓                         ↓
                                            [Antwort erstellen] ------------→ [Teams-Nachricht senden]
                                                                                                      ↓
                                                                                             [Alarm protokollieren]

Wesentliche technische Aspekte

1. API-Authentifizierung

2. Leistungsschwellenwerte

  • Latenzschwelle: 300 Millisekunden
  • Paketverlustschwelle: 2 %
  • Diese Schwellenwerte können je nach Bedarf angepasst werden

3. Mechanismus zur Vermeidung doppelter Alarme

  • Verwendet Redis zur Speicherung bereits gesendeter Alarme
  • TTL auf 3 Stunden gesetzt
  • Innerhalb der TTL-Zeit werden keine wiederholten Alarme für denselben Standort gesendet

4. Datenverarbeitungsmethodik

  • Erfasst Daten der letzten 5 Zeitpunkte
  • Berechnet Durchschnittswerte, um kurzfristige Schwankungen zu reduzieren
  • Nutzt JavaScript-Code-Knoten für komplexe Datenverarbeitung und Filterung

Anwendungsszenarien

  1. Netzwerkleistungsüberwachung: Kontinuierliche Überwachung von Latenz und Paketverlust in Meraki-Netzwerken
  2. Proaktive Alarmierung: Automatische Benachrichtigung des technischen Teams bei Leistungseinbußen
  3. Fehlerbehebung: Bereitstellung direkter Netzwerk-URL-Links zur schnellen Lokalisierung von Problemen
  4. Alarmmanagement: Vermeidung von Alarmfluten – pro Standort wird innerhalb von 3 Stunden nur ein Alarm gesendet

Erweiterungsvorschläge

Gemäß Sticky Note6 können folgende Erweiterungen vorgenommen werden:

  1. Integration in PSA-Systeme: Ersetzen des Teams-Nachrichtenknotens durch einen PSA-Tool-Knoten (z. B. ConnectWise Manage), um automatisch Tickets statt nur Nachrichten zu erstellen
  2. Mehrfach-Benachrichtigungskanäle: Zusätzlich zu Teams können auch E-Mail, Slack oder andere Kanäle hinzugefügt werden
  3. Individuelle Schwellenwerte: Unterschiedliche Leistungsschwellen für verschiedene Netzwerke festlegen
  4. Langzeitspeicherung historischer Daten: Speichern der Überwachungsdaten in einer Datenbank zur langfristigen Analyse und Trendvorhersage

Zusammenfassung

Dies ist ein vollständiger, automatisierter Netzwerküberwachungs-Workflow, der die folgenden Funktionen von n8n optimal nutzt:

  • HTTP-Anfragen zur Integration externer APIs
  • Datenumwandlung und -verarbeitung (Set-, Code-Knoten)
  • Datenzusammenführung (Merge-Knoten)
  • Bedingte Filterung und logische Entscheidungen
  • Externe Benachrichtigungen (Teams-Webhook)
  • Datenspeicherung (Redis)

Durch automatisierte Überwachung und intelligente Alarmierung wird die Effizienz des Netzwerkbetriebs deutlich gesteigert und der manuelle Prüfaufwand erheblich reduziert.