基本のpingから有償ツールまで
ネットワーク監視システムで最適パフォーマンスを得るためには
ネットワーク監視システムは大量の帯域幅を使用する可能性がある。最適なパフォーマンスを得るためには、どう設定すればいいのか考えてみよう。
ネットワーク監視システムは、タスク実行のために大量の帯域幅を使用する可能性がある。監視対象のデバイスが多くなれば、できるだけ最新の監視情報を入手するため、監視システムがネットワーク上の実働トラフィックからより多くの帯域幅を横取りするようになる。では、最適なパフォーマンスが得られるようにするには、ネットワーク監視システムをどのように設定すればいいのか考えてみよう。
最適パフォーマンスを得るための設定――基本編
ネットワーク監視システムの最も基本的な形態がpingプログラムである。「ping host1」と入力して、どんな結果が返されるかを見るというのは、多くの読者にとっておなじみの手法だろう。だが、pingがホストの存在の有無を通知するためにバックグラウンドで何をしているのか、考えたことはないかもしれない。
Windowsの場合、デフォルトでは、pingは指定されたホストに32バイトのパケットを4つ送信し、各パケット送信後に応答が返るのを待つ。最後に、失われたパケットの割合（％）、最大応答時間、最小応答時間、平均応答時間を計算する。例えば、以下のような具合だ。
Z:> ping corerouter
Pinging corerouter [10.253.100.1] with 32 bytes of data:
Reply from 10.253.100.1: bytes=32 time=1ms TTL=255
Reply from 10.253.100.1: bytes=32 time<1ms TTL=255
Reply from 10.253.100.1: bytes=32 time<1ms TTL=255
Reply from 10.253.100.1: bytes=32 time<1ms TTL=255
Ping statistics for 10.253.100.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milliseconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
Z:>
これはかなり基本的な――たぶん少し退屈な――情報のように思えるが、ここが重要なポイントだ（と筆者は確信している）。
pingではスイッチを使用して各種の設定を行うことができる。以下に具体例を示す。
- ping -n {count} → pingパケットを送信する回数を指定する（デフォルトは4回）。
- ping -w {milliseconds} → 各パケット送信後の応答待ち時間を指定する。
- ping -l {bytes} → 各pingパケットのバイト数を指定する。
つまり、以下のように指定すれば、大量のトラフィックをホストに送信することができるわけだ。
Ping -l65500 -t killtherouter
これにより、誰かがpingの停止を指示するまで、このホストに6万5500バイトのパケットが送信されるのである。
ネットワーク監視システムは何をするのか？
pingは最も基本的なタイプのネットワーク監視ツールだが、設定を最適化することにより、ネットワークのパフォーマンスを低下させることなくネットワーク情報を収集することができるという点では、ほかのすべてのネットワーク監視システムと同様である。
では、現在出回っている各種のネットワーク監視ツールを見ていくことにしよう。比較的人気が高いツールとしては、以下のようなものがある。
- PRTG
- Cacti
- WhatsUp Gold
- Nagios（旧称：netsaint）
注意しなければならないのは、厳密な意味で「ネットワーク監視」と言うとき、それはネットワークノードの純粋な動作／停止情報を意味するということである。しかし今日のほとんどのネットワーク監視システムは、ノードの動作／停止状態だけでなく、ノードのパフォーマンスやネットワークのパフォーマンスも監視する。これらのデータはすべてデータベースに保存されるので、データの解析、通知、グラフ化が可能である。
ネットワーク監視には多くの側面がある。デバイスの状態、デバイスのインベントリ、パフォーマンス監視、通知、傾向の把握、侵入検知など多数の機能をネットワーク監視のカテゴリーに含めるネットワーク管理者もいる。
これらの機能はすべて、ネットワーク監視ツールとしての要件を満たすだけでなく、ネットワークパフォーマンス監視ツールとしての要件をも満たすものだと言える。
どんなカスタマイズができるのか？
今日のネットワーク監視システムでは、ほとんどすべての機能をカスタマイズすることが可能だ。しかしどのように調整すれば、最大のパフォーマンスが得られるのだろうか。今日のほとんどのネットワーク監視システムは、ノードが「そこに存在するか」という情報だけでなく、SNMPを使ってさらに詳しい情報を収集する。SNMPを利用することにより、これらのシステムはパフォーマンス情報を収集し、ネットワークインタフェースが停止あるいは作動すると通知を受けることができる。
一般に、以下の機能がカスタマイズ可能だ。
- どのネットワークノードを監視するか（例：コアルータ、アプリケーションサーバなど）
- ネットワークノード上のどのインタフェースを監視するか（例：ルータ上のGigE0/0インタフェース、サーバ上のCPU 1など）
- デバイスのポーリングを行う頻度（例：10秒ごと、60分ごとなど）
- ホストシステムがネットワークノードのポーリングを行う際にどれだけの情報を収集するか
- 収集したデータをどのように計算し、保存する（またはしない）か。例えば、直前の5分間の平均応答時間を計算し、個々の応答時間は保存しないで平均応答時間だけを保存するなど
どのように設定すれば最適なパフォーマンスが得られるか？
筆者は、上で紹介したネットワーク監視／パフォーマンス監視アプリケーションはすべて使用した。どれも気に入ったが、その中でも何かにつけて利用し、筆者の一番のお気に入りになったものが1つある。それはPaesslerの「PRTG」というプログラムだ。この製品は、単一のネットワークノード（1台のルータまたは1台のサーバ）およびそのノードの1つのインタフェース（つまり1台のルータ上の1個のインタフェース）を監視するだけであれば、無償で利用できる。加えて、PRTGは比較的安価で、使い勝手も良い。もちろん、完全に無償のネットワーク監視／パフォーマンス監視アプリケーションもあるが（NagiosやCactiなど）、PRTGほどシンプルで使いやすいものはない。
ネットワークの監視にどれだけの帯域幅を使用するかは、どれくらいの帯域幅が利用可能であるのか、そして会社にとってのネットワーク情報のリアルタイム更新がどれくらい重要であるかによって決まる。例えば、PRTGのようなアプリケーションを使用する場合、コアルータを10秒ごとにポーリングすればいいのか、それとも4万3200秒ごとにポーリングするように設定すればいいのだろうか。LAN上の1台のルータだけを監視するのであれば、10秒ごとにポーリングを行って接続性とパフォーマンスのデータを収集しても問題はない。しかし監視対象のデバイスが1万台あり、既に忙しいネットワークリンク上でこれらのデバイスのポーリングを10秒ごとに行ったりすると、大量の不要なトラフィックを発生させることになる。これはネットワークパフォーマンスの問題を引き起こし、メリットよりもデメリットの方が大きくなるだろう。
PRTGの設定画面を以下に示す。
ここでは、平均グラフの時間設定について説明しよう。上図にあるように、デフォルトの平均グラフ作成の対象時間は5分である。平均グラフの対象時間を5分から20秒に変更すると、グラフの様子は大きく変化するはずだ。
次に、どのグラフを表示させるか、どのデータの平均を取るかという設定例を紹介しよう。
最後に筆者のアドバイスを以下に記す。
- ネットワークデバイスのポーリング頻度の設定では、帯域幅の要求を抑制するようにバランスを図ること
- ネットワークの監視によって実際にどれだけのトラフィックが生成されているかを把握するためにWireshark（旧称：Ethereal）などのネットワークプロトコルアナライザを利用し、必要に応じてポーリングの頻度を調整する
- 一般に、LAN上のデバイスはWAN上のデバイスよりもはるかに頻繁にポーリングできる
- データの平均取得時間を長く設定すると、データのピークを見逃してしまう可能性があることに注意する。発生時間が短かったピークのデータが平均の中に埋もれてしまうからだ
本稿筆者のデビッド・デイビス氏は、IT業界で15年間のキャリアを持つ。現在、非上場の小売会社でシステム／ネットワーク管理部門を統括しており、余暇にIT関連の執筆を行っている。これまでに100本以上の記事、8つのプラクティステスト、4つのビデオ講座を執筆し、共著書が1冊ある。保有資格には、CCIE（シスコ認定インターネットワークエキスパート）#9369、CWNA（認定無線ネットワークアドミニストレーター）、MCSE（マイクロソフト認定システムエンジニア）、CISSP（公認情報システムセキュリティプロフェッショナル）、Linux+、CEH（認定倫理的ハッカー）などがある。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
事例
[ポールトゥウィン株式会社] 開発スピードと品質を両立、DONUTSが実践する「ハイブリッドなQA体制」の構築術 -
製品レビュー
[ポールトゥウィン株式会社] 開発スピードと品質は両立できる？ DONUTSの「ジョブカン」に学ぶQA戦略 -
市場調査・トレンド
[レッドハット株式会社] 「プラットフォームエンジニアリング」調査レポート：利点・課題・未来像を詳説 -
市場調査・トレンド
[レッドハット株式会社] 生成AI活用のためのテクノロジー基盤、構築に際しての7つの検討事項とは？ -
製品資料
[レッドハット株式会社] ビジネスの現場へのAI導入と活用、何から始めてどのように進めるべきか？
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
【漫画付き】ひとり情シス協会が明かす、RAG導入でしくじる企業「2つの共通点」
-
2
1200万円のSaaS導入を回避 スギ薬局「運用費10万円」のAIエージェント構築術
-
3
OpenAIがコスト半減のGPT-6新モデル投入 Claude猛追とOSS包囲網で激化する価格戦
-
4
Microsoft製品でここまで自動化できる 情シスがやめられる手作業10選
-
5
「Microsoft 365」が乗っ取られる 跡形もなくMFAを破る手口
-
6
全社標準Copilotに絶望？ MS Copilotで問い合わせ6割減できた企業は何が違った
-
7
AI全部入り「Microsoft 365 E7」に企業が二の足を踏む訳 移行意向はわずか4％
-
8
Netflixのバックエンドは「ほぼJava」 3000超のアプリを支える開発基盤の裏側
-
9
「AI活用を前提とした業務PCへの移行」に関するアンケート
-
10
「RAGの利用」に関するアンケート
ホワイトペーパーランキング PR
-
1
DX／AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
2
バックアップは“取っているから大丈夫”なのか？ ランサムウェア時代の備え方
-
3
システムの保守がモダン化を阻む？ 「変えない判断」から脱却する方法とは
-
4
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
5
5分で分かる Microsoft 365のデータ損失に備えるためのバックアップの仕組み
-
6
「NAS」「SAN」「DAS」は何が違う？ いまさら聞けないストレージの基礎
-
7
ネットワーク遅延の原因、「パケットロス」の基礎知識と効果的な解決策
-
8
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
9
ソフトウェア開発の属人化と手戻りをどう防ぐ？ 速さと品質を両立させる方法
-
10
ランサムウェア攻撃“究極の対策”はこれだ
TechTargetジャパン SNS
@techtarget_itmをフォロー
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー