ネットワーク機器が「物言わぬブラックボックス」化する悩み
上司が背後に立って「なぜネットワークが遅いんだ?」と問い詰める中、慌ててCisco Catalystスイッチ一台一台にSSHでログインし、show interface statusコマンドを叩く……そんな経験はありませんか?管理対象が20〜30台規模に膨れ上がると、こうした手動管理は大きな負担となります。
LinuxやWindowsサーバーであればNode Exporterが使えます。しかし、ネットワーク機器(ネットワークアプライアンス)はクローズドなOSであるため、エージェントを追加でインストールすることができません。帯域幅やポートエラー(input/output errors)を監視できていなければ、ネットワーク遅延や輻輳が発生した際に常に後手に回ることになります。
なぜPrometheusはスイッチと直接「話す」ことができないのか?
Prometheusはプル型(pull)のメカニズムで動作し、ターゲットがシンプルなテキスト形式のHTTPエンドポイントを提供することを要求します。対して、新旧問わず多くのネットワーク機器は主にSNMP (Simple Network Management Protocol)を使用しています。
SNMPは非常に複雑なOID (Object Identifier) ツリー構造を持ち、UDP上で動作します。この両者は、いわば「話す言語」が異なります。この問題を解決するために、間に立つ「通訳者」が必要になります。それがSNMP Exporterの役割です。
一般的な監視ソリューションの比較検討
ネットワーク管理者がよく検討するいくつかの選択肢を挙げます:
- Zabbix: SNMP監視における「重鎮」です。しかし、すでにサーバー監視にPrometheusを使用している場合、Zabbixを別途導入するとデータの分断や運用リソースの浪費を招きます。
- Pythonスクリプトによる自作:
snmpwalkを実行してPushgatewayにデータをプッシュする方法です。最初は手軽ですが、デバイス数が増えるとメンテナンスが困難になります。 - SNMP Exporter: Prometheusエコシステムの標準的なソリューションです。軽量で効率的、かつGrafanaとの親和性も抜群です。
Prometheus SNMP Exporterの実践的な導入手順
メトリクスを一元管理できるため、私はSNMP Exporterを推奨しています。以下は、50台以上のコアスイッチおよびアクセススイッチを抱える企業システムに適用した際の手順です。
1. ネットワーク機器でのSNMP有効化
デバイスがSNMPクエリを受け付けるように設定する必要があります。例えば、Ciscoスイッチの場合は以下のコマンドを実行します:
# 設定モードへ移行
conf t
# Community Stringの作成(データ読み取り用のパスワードのようなもの)
snmp-server community MySecretPassword RO
# 監視サーバーのIP(例: 192.168.1.50)からのアクセスのみを許可
access-list 10 permit 192.168.1.50
snmp-server community MySecretPassword RO 10
注意: SNMP v2cまたはv3を優先して使用してください。v1は非常に低速であり、1Gbpsを超える高速ポート用の64ビットカウンタをサポートしていないため、使用を避けるべきです。
2. DockerによるSNMP Exporterの起動
依存関係を気にせず迅速に展開するには、Dockerが最適です。以下のようなdocker-compose.ymlファイルを作成します:
version: '3'
services:
snmp-exporter:
image: prom/snmp-exporter
container_name: snmp-exporter
restart: always
ports:
- "9116:9116"
volumes:
- ./snmp.yml:/etc/snmp_exporter/snmp.yml
3. snmp.ymlファイルの設定
snmp.ymlファイルには数千行のOID定義が含まれるため、手書きは不可能です。通常は、メーカー提供のMIBファイルからConfig Generatorを使用してこのファイルを生成します。
手早く始めるには、Cisco、HP、APCなどをサポートしているサンプルファイルを公式GitHubからダウンロードしてください。新しい機器を購入する際は、後の監視設定をスムーズにするために、ベンダーにMIBファイルの提供を必ず依頼しておくのがコツです。
4. Prometheusへのデバイス登録
prometheus.ymlを開き、新しいジョブを追加します。SNMP Exporterはプロキシとして動作します。PrometheusがExporterにリクエストを送り、Exporterがネットワーク機器に問い合わせを行います。
scrape_configs:
- job_name: 'snmp_network_devices'
static_configs:
- targets:
- 192.168.1.1 # コアスイッチのIP
- 192.168.1.2 # エッジルーターのIP
metrics_path: /snmp
params:
module: [if_mib]
relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- source_labels: [__param_target]
target_label: instance
- target_label: __address__
replacement: 192.168.1.50:9116 # SNMP Exporterが動作しているマシンのIP
5. Grafanaによるデータの可視化
Prometheusの生のテキストデータを見る必要はありません。Grafanaに移動し、「Import Dashboard」からID 11169 を入力してください。これはSNMP用の非常にプロフェッショナルなテンプレートです。
各ポートのイン/アウト帯域幅、Up/Down状態、そして特に重要なエラー率(Error rate)が明確に表示されます。特定のポートでエラー率が急増している場合、そのネットワークケーブルの物理的な故障である可能性が高いと判断できます。
トラブルを避けるための注意点
実際の運用経験から、いくつかのアドバイスがあります:
- データ取得間隔 (Interval): 短すぎないように設定してください(1秒や5秒など)。スイッチのCPUは非力なことが多く、頻繁なSNMPクエリはデバイスのフリーズやCPU使用率のスパイクを招く恐れがあります。30秒〜60秒が妥当です。
- Description(説明文)の活用: スイッチのポートには必ず分かりやすい名前を付けてください(例:
Description: Uplink_To_Server_DB)。SNMP Exporterはこの名前を取得できるため、グラフの可読性が飛躍的に向上します。 - スマートなアラート設定: アラートは重要なアップリンクポートのみに設定することをお勧めします。全ユーザーのポートに対してDown通知を設定すると、通知の嵐で業務に支障をきたすことになります。
このシステムを導入して以来、ネットワークが遅い時に推測に頼る必要がなくなりました。ダッシュボードを一目見るだけで、どこに問題があるか即座に特定できます。ぜひ導入に挑戦して、ネットワークインフラを完全に掌握してください!

