Merakiネットワークパフォーマンス監視とアラート

Meraki Network Monitor

Cisco Merakiネットワークの遅延とパケットロス率を自動で監視し、パフォーマンスがしきい値を超えた際にTeams経由でアラートを送信します。また、Redisを使用して重複通知を防止します。

23 NodesIndustry Verticalネットワーク監視パフォーマンスアラートMeraki

ワークフロー概要

この n8n ワークフローは、Cisco Meraki ネットワーク監視・アラートシステムであり、ネットワークのパフォーマンス指標（遅延とパケットロス率）を自動的に監視し、問題を検出した際にアラート通知を送信します。ワークフローは Meraki API を介して組織、ネットワーク、アップリンク統計データを取得し、平均パフォーマンス指標を計算した上で問題のあるサイトをフィルタリングし、Microsoft Teams でアラートメッセージを送信します。同時に Redis データベースを使用して重複アラートを防止します。

ワークフロー構成

1. トリガーノード

ノード名：

  • When clicking "Execute Workflow"（手動トリガー）
  • Schedule Trigger（スケジュールトリガー）

機能説明： このワークフローは以下の2種類のトリガー方式をサポートしています：

  • 手動実行：「ワークフローを実行」ボタンをクリックして手動でトリガー
  • スケジュール実行：事前に設定された時間スケジュールに従って自動実行（継続的な監視用）

2. データ収集フェーズ

2.1 Meraki 組織情報の取得

ノード名： Get Meraki Organizations

機能説明：

  • HTTP リクエストにより Meraki API (https://api.meraki.com/api/v1/organizations) を呼び出し
  • Header 認証方式を使用（Meraki API キーの設定が必要）
  • アカウントがアクセス権を持つすべての組織リストを取得

技術詳細：

  • リクエストタイプ：GET
  • 認証方式：HTTP Header Auth
  • 必須ヘッダー：
    • Authorization: 認証用
    • Accept: application/json: JSON 形式でのレスポンスを指定

2.2 組織データの整形

ノード名： Get Org Name & ID

機能説明：

  • Set ノードを使用して重要なフィールドを抽出・リネーム
  • 元データから以下の情報を抽出：
    • CompanyName: 組織名
    • OrgID: 組織 ID

2.3 ネットワーク ID の取得

ノード名： Get Network IDs

機能説明：

  • 各組織 ID に対して API を呼び出し、その配下の全ネットワークを取得
  • 動的 URL 使用：https://api.meraki.com/api/v1/organizations/{{ $json.OrgID }}/networks
  • 後続のネットワーク監視のためにネットワークリストを提供

2.4 ネットワーク変数の整形

ノード名： Sets Network Variables

機能説明：

  • ネットワーク情報を抽出・整形
  • ネットワーク名、ネットワーク ID、ネットワーク URL などの主要フィールドを含む

2.5 アップリンク統計データの取得

ノード名： Get Uplink Loss and Latency

機能説明：

  • ネットワークデバイスのアップリンクパフォーマンス統計を取得
  • 以下を含む：
    • パケットロス率（Loss Percent）
    • 遅延（Latency Ms）
    • 時系列データ（直近5時点分のデータ）

3. データ処理・分析フェーズ

3.1 データ結合

ノード名： Combine latency to its respective Network

機能説明：

  • Merge ノードを使用してネットワーク情報とパフォーマンス統計データを結合
  • 照合フィールド：NetworkID と networkId
  • 結合モード：enrichInput1（入力1のデータを拡張）

3.2 データ再構成

ノード名： Makes Latency and Loss Filterable

機能説明：

  • データ構造を再編成し、遅延およびパケットロスデータをフィルタリング・分析しやすくする
  • 5つの時系列データポイントを抽出：
    • TS0-Loss ～ TS4-Loss：5時点のパケットロス率
    • TS0-Latency ～ TS4-Latency：5時点の遅延
  • ネットワーク名、シリアル番号、URL などのメタデータを保持

3.3 平均値の計算

ノード名： Average Latency & Loss over 5m

機能説明：

  • JavaScript コードを使用して直近5時点の平均値を計算
  • 以下の2つの主要指標を算出：
    • AverageLoss：平均パケットロス率
    • AverageLatency：平均遅延（ミリ秒）
  • これらの平均値を用いてパフォーマンス問題をより正確に特定

コードロジック：

// 5時点の総パケットロス率と総遅延を計算
// 5で割って平均値を算出
// 結果をデータ項目に追加

3.4 問題のあるサイトのフィルタリング

ノード名： Filters Problematic sites

機能説明：

  • JavaScript コードを使用して閾値を超えるサイトをフィルタリング
  • 閾値基準：
    • 平均遅延 > 300 ミリ秒
    • または 平均パケットロス率 > 2%
  • いずれかの条件を満たすサイトのみが次のステップに渡される

フィルタリングロジック：

// AverageLatency > 300 または AverageLoss > 2 の場合
// そのサイトは問題ありとマークされる

4. アラート重複防止・通知フェーズ

4.1 アラートの存在確認

ノード名： Check if Alert Exists

機能説明：

  • Redis データベースを照会し、該当ネットワークへのアラートが既に送信済みかどうかを確認
  • ネットワーク名をキーとして使用
  • キーが存在する場合、TTL 期間内に既にアラートが送信済みであることを意味する

4.2 レスポンスデータの作成

ノード名： Create Response

機能説明：

  • JavaScript を使用して Redis の照会結果を処理
  • 結果を利用可能な真偽値または識別子に変換
  • 新しいアラートを送信すべきかを判定

4.3 重複除去のマージ

ノード名： Merge

機能説明：

  • 問題のあるサイトと既存アラートのデータをマージ
  • 照合フィールド：NetworkName
  • マージモード：不一致項目をすべて保持
  • 重要なロジック：ネットワーク名が一致する場合、アラートは既に存在しているため送信しない。一致しないもの（＝新規問題）のみが後続処理に進む

4.4 Teams メッセージの送信

ノード名： Message Techs

機能説明：

  • Microsoft Teams Webhook を通じてアラートメッセージを送信
  • メッセージ内容：
    • ネットワーク名
    • 平均遅延およびパケットロス率データ
    • ネットワーク URL（ハイパーリンク形式で問題サイトに直接ジャンプ可能）
  • 技術チームにパフォーマンス閾値超過のサイトを通知

4.5 アラートログの記録

ノード名： Log the Alert

機能説明：

  • アラートを Redis データベースに記録
  • TTL（生存時間）を3時間に設定
  • 重複防止ロジック：同一サイトの問題が3時間以内に解決されない場合、3時間後に再度アラートを送信

5. 補足説明ノード

ワークフローには複数の Sticky Note（付箋）ノードが含まれており、詳細な使用方法を説明しています：

  • Sticky Note3：Meraki API 認証の設定方法を解説
  • Sticky Note4：データ結合および統計計算のロジックを説明
  • Sticky Note5：アラート重複防止メカニズムと通知フローを詳細に説明
  • Sticky Note6：他の活用シーン（例：PSA ツールとの連携によるチケット自動作成）を提案

ワークフロー図

[トリガー] → [組織取得] → [組織データ整形] → [ネットワークID取得] → [ネットワークデータ整形]
                ↓                                                    ↓
          [アップリンクデータ取得] --------------------------------→ [データ結合]
                                                                        ↓
                                                        [遅延・ロスデータ再構成]
                                                                        ↓
                                                           [5分間の平均値計算]
                                                                        ↓
                                                          [問題のあるサイトをフィルタリング]
                                                                        ↓
                                            [アラート存在確認] ← → [重複除去マージ]
                                                    ↓                   ↓
                                            [レスポンス作成] ------------→ [Teamsメッセージ送信]
                                                                        ↓
                                                                 [アラートログ記録]

主要技術ポイント

1. API 認証

2. パフォーマンス閾値

  • 遅延閾値：300 ミリ秒
  • パケットロス閾値：2%
  • これらの閾値は実際の要件に応じて調整可能

3. アラート重複防止メカニズム

  • 送信済みアラートを Redis に保存
  • TTL を3時間に設定
  • TTL 期間中は同一サイトへの重複アラートを送信しない

4. データ処理方法

  • 直近5時点のデータを収集
  • 平均値を計算して瞬間的な変動の影響を軽減
  • 複雑なデータ処理およびフィルタリングに JavaScript コードノードを使用

利用シーン

  1. ネットワークパフォーマンス監視：Meraki ネットワークの遅延およびパケットロス状況を継続的に監視
  2. プロアクティブなアラート：パフォーマンス低下時に技術チームへ自動通知
  3. トラブルシューティング：ネットワーク URL の直接リンクにより問題箇所を迅速に特定
  4. アラート管理：アラートの過剰送信を防止し、3時間以内に同一サイトへのアラートは1回のみ送信

拡張提案

Sticky Note6 の説明に基づき、以下の拡張が可能です：

  1. PSA システムとの統合：Teams メッセージノードを PSA ツールノード（例：ConnectWise Manage）に置き換え、メッセージ送信ではなく自動でチケットを作成
  2. マルチチャネル通知：Teams に加え、メールや Slack など他の通知チャネルを追加
  3. カスタム閾値：ネットワークごとに異なるパフォーマンス閾値を設定
  4. 履歴データ保存：監視データをデータベースに保存し、長期的な分析およびトレンド予測に活用

まとめ

これは完全なネットワーク監視自動化ワークフローであり、n8n の以下の機能を最大限活用しています：

  • 外部 API との HTTP リクエスト統合
  • データ変換・処理（Set ノード、Code ノード）
  • データ結合（Merge ノード）
  • 条件フィルタリングおよび論理判断
  • 外部通知（Teams Webhook）
  • データ永続化（Redis）

自動化監視とスマートなアラートにより、ネットワーク運用効率が大幅に向上し、手動チェックの作業負荷が軽減されます。