300MbpsのプランなのにZoom会議がカクつく？
システム管理者の方なら、オンライン会議中に接続が不安定になったり、Dockerイメージのダウンロード速度が数百KB/sまで落ち込んだりするという状況は珍しくないでしょう。プロバイダーに問い合わせても、テクニカル担当者からは「信号は正常です」と回答されるだけ。そんな時、ブラウザでの手動スピードテストの結果だけでは、Wi-Fiや個人のデバイスのせいにされてしまい、相手を納得させるには不十分です。
「推測」に頼るのをやめるためには、履歴データを持って対話できる、24時間365日稼働の自動監視システムが必要です。手動で「開始」ボタンを押す代わりに、Speedtest Exporterで測定を自動化し、メトリクスをPrometheusに送り、Grafanaで分かりやすく可視化してみましょう。
構成：監視の「三本柱」
構築を始める前に、各コンポーネントの役割を整理しておきましょう：
- Speedtest Exporter: クライアントとして機能し、定期的にテスト（Ping、ダウンロード、アップロード）を実行して、結果をPrometheus標準形式のメトリクスとして公開します。
- Prometheus: 時系列データベース（Time-series database）です。定期的にExporterからメトリクスを取得し、データベースに保存します。
- Grafana: 表示レイヤーです。Prometheusからデータをクエリしてグラフを描画し、混雑時間帯や夜間のネットワーク遅延の傾向を浮き彫りにします。
Netdataやhtopのようなツールはリアルタイムのトラフィック確認には優れていますが、ISPから実際に提供されている最大帯域幅を把握することはできません。そこでSpeedtest Exporterが必要になります。
Docker Composeによる実践的なデプロイ
OSのPythonライブラリの競合を避けるには、Dockerを使うのが最もクリーンな方法です。以下は、ホームラボや小規模オフィス向けに最適化したdocker-compose.ymlファイルです：
version: '3.8'
services:
speedtest-exporter:
image: miguelndecarvalho/speedtest-exporter
container_name: speedtest-exporter
restart: unless-stopped
ports:
- "9798:9798"
environment:
- SPEEDTEST_INTERVAL=3600 # 60分ごとにテストを実行
prometheus:
image: prom/prometheus
container_name: prometheus
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
ports:
- "9090:9090"
restart: unless-stopped
grafana:
image: grafana/grafana
container_name: grafana
ports:
- "3000:3000"
restart: unless-stopped注意点：ここではSPEEDTEST_INTERVAL=3600（1時間に1回）に設定しています。1〜5分おきといった高頻度な設定は避けてください。測定1回につき、高速な回線では最大500MBの帯域を消費することがあります。頻繁に実行しすぎると自宅の回線自体を圧迫するだけでなく、異常なトラフィックとしてISPから監視されたり、SpeedtestサーバーからIP制限を受けたりする可能性があります。
Prometheusのデータ取得設定
次に、同じディレクトリにprometheus.ymlを作成し、PrometheusがExporterに接続できるように設定します：
global:
scrape_interval: 15s
scrape_configs:
- job_name: 'speedtest'
static_configs:
- targets: ['speedtest-exporter:9798']docker-compose up -dコマンドを実行して起動します。http://localhost:9090にアクセスし、speedtest_download_bits_per_secondと入力して、データが収集され始めているか確認してください。
Grafanaでのグラフ化と「アラート疲れ」問題
Grafanaの管理画面で、URLをhttp://prometheus:9090としてPrometheusをデータソースに追加します。最も簡単な方法は、Dashboard ID 13680をインポートすることです。これで、ダウンロード、アップロード、Pingのプロフェッショナルなダッシュボードがすぐに手に入ります。
アラートに関する実体験からの教訓
アラートに関する実体験からの教訓は、運用において最も頭を悩ませる問題です。当初、私はダウンロード速度が50Mbpsを下回った時にTelegramに通知が飛ぶようにしていました。その結果、家族がNetflixで4K動画を見たり、Steamでゲームをダウンロードしたりするたびに、スマホの通知が鳴り止まなくなりました。測定時にSpeedtestが十分な帯域を確保できなかっただけなのですが、これでは「オオカミ少年」になってしまいます。
実践的な解決策：
1. 単発の測定結果でアラートを出さないこと。Prometheusのavg_over_time関数を使用して、3〜6時間の平均値を計算します。数時間にわたって平均速度が低い場合、それは本当のネットワークトラブルである可能性が高いです。
2. サーバーIDを最寄りのもの（例：東京や大阪の主要プロバイダーのサーバー）に固定すること。これにより、Exporterが勝手に海外のサーバーを選んでしまい、Ping値が高くなったり速度が不安定になったりするのを防げます。
測定精度を高めるための最適化のコツ
Raspberry Pi上でWi-Fi経由でExporterを実行すると、得られる結果は単なる「自宅のWi-Fi速度」になってしまいます。正確に監視するために、以下の点に注意してください：
- 測定デバイスは必ずルーターにLANケーブルで直接接続すること。
miguelndecarvalhoのイメージを使用すること。これはARM（Raspberry Piなど）とx86（サーバー/PC）の両方を適切にサポートしています。- 高速なデータ処理はリソースを消費するため、測定時にデバイスのCPU負荷が高くなりすぎていないことを確認すること。
結論
インターネットの24時間監視は、ISPと交渉する際の「決定的な証拠」になるだけでなく、内部ネットワークの問題を早期に発見するのにも役立ちます。今回の設定やアラート疲れ対策のコツが、皆さんのシステムの効率的な運用に役立てば幸いです。Prometheusのクエリ作成で困ったことがあれば、ぜひコメント欄で教えてください！
