【基礎①】PingとSNMPで機器の"健康診断"｜ネットワーク可観測性エンジニアへの道

皆さん、こんにちは。「ネットワーク可観測性エンジニアへの道」連載、第2回へようこそ。

第1回の序論では、ネットワーク監視の世界で起きている「監視から可観測性へ」という大きなパラダイムシフトについてお話しました。この変化の背景には、従来の監視手法の限界があります。

しかし、新しい技術を学ぶ前に、私たちはまず、これまでネットワーク監視の根幹を支えてきた技術を正しく理解し、その「限界」が何であるかを具体的に知る必要があります。それこそが、次世代の技術を学ぶ上での揺ぎない土台となるからです。

この記事では、ネットワーク監視における最も基本的で重要な2つの要素、PingとSNMPに焦点を当て、その役割と、New Relicを使った具体的な監視設定の方法について解説します。

Ping：ネットワークにおける「もしもし、聞こえますか？」

ネットワークに問題が発生したとき、エンジニアが最初に行うことは何でしょうか。多くの場合、それは対象の機器に対して「Pingを打つ」ことかと思います。

Pingは、ICMPというプロトコルを使い、対象のサーバーやネットワーク機器がネットワーク上で応答を返すか（生きているか）を確認する、最も基本的なコマンドです。これは、人間が誰かに「もしもし、聞こえますか？」と呼びかける行為に似ています。相手から返事があれば、コミュニケーションが取れる状態にあると判断できます。

この「死活監視」は、あらゆる監視の基本です。どんなに高度なデータを収集できたとしても、そもそも機器がネットワーク的に到達不可能であれば意味がありません。

New Relicでは、後ほど紹介するktranslateエージェントを社内ネットワークのサーバーなどに設置することで、そのエージェントの場所から重要なネットワーク機器へのPing疎通性を継続的に監視し、内部的な可用性をチェックすることが可能です。

SNMP：機器の「健康診断書」を定期的に受け取る

Pingで機器が「生きている」ことを確認できたら、次はその「健康状態」を知りたくなります。CPUの使用率は？メモリの空きは？ネットワークの通信量は？こうした詳細なパフォーマンスデータを取得するための伝統的なプロトコルが**SNMP (Simple Network Management Protocol)**です。

SNMPは、長年にわたりネットワーク機器の性能監視における業界標準でした。機器の「健康診断書」を定期的に受け取るように、CPU使用率、メモリ使用率、インターフェースのトラフィック量といった重要な指標（メトリクス）を収集できます。

なぜ今、SNMPの「限界」が語られるのか？

ここで、本連載の核心に触れる重要なポイントがあります。実は、先日開催されたInterop Tokyo 2025において、筆者が各社の担当者に直接ヒアリングした結果、主要なネットワークベンダー各社がSNMP中心の監視から、クラウドプラットフォームとAPIを主軸とした戦略へ大きく舵を切っていることが明らかになりました。

なぜでしょうか？最大の理由は、ネットワークの広帯域化です。

SNMPでトラフィック量などを記録する32bitのカウンターには、「ラップ問題」と呼ばれる有名な課題があります。これは、カウンターが最大値に達するとゼロに戻ってしまう現象です。

1Gbpsの通信速度では、このカウンターは約34秒で一周してしまいます。
10Gbpsにもなると、わずか約3.4秒です。

これほど短い間隔でデータを取りこぼさずに監視を続けるのは、現実的ではありません。この技術的な限界から、各社はSNMPに代わる新たなモニタリング手法への移行を加速させているのです。

しかし、だからといって「SNMPはもう古いから学ばなくてよい」とはなりません。今この瞬間も、世界中の多くのネットワークがSNMPで監視されており、その仕組みを理解することは、トラブルシューティングの現場で必須の知識です。私たちは、その重要性と限界の両方を正確に理解した上で、次の一歩に進む必要があります。

【実践】New Relicとktranslateで監視を始める

それでは、実際にNew Relicを使って監視をセットアップしていきましょう。

Step 1: ktranslateとは？

New RelicでSNMPや後続の連載で解説するFlowなどのネットワークデータを収集するには、ktranslateというエージェントを利用します。これはKentik社によって開発されたオープンソースのテレメトリコレクターで、様々なネットワーク機器からデータを収集し、New Relicプラットフォームへ転送する役割を担います。

コンテナやLinuxパッケージで提供されており、環境に合わせて導入方法を選択できます。

Step 2: 設定ファイルの準備

ktranslateにどの機器を、どの方法で監視させるかを指示するために、設定ファイルを作成します。ここではsnmp-base.yamlというファイル名で作成することにします。

このYAMLファイルに、監視対象となる機器のIPアドレスや、SNMPでアクセスするための情報（コミュニティ名など）を記述していきます。

Step 3: 具体的な設定（snmp-base.yaml）

以下は、Pingによる死活監視と、SNMPによる性能監視の両方を行うための設定ファイルサンプルです。

devices:
  # === Ping監視対象のデバイス ===
  # GoogleのDNSサーバーを死活監視する例
  google-dns:
    device_name: google-dns
    device_ip: 8.8.8.8
    ping_only: true  # これを指定するとPing監視のみ実行

  # === SNMP監視対象のデバイス ===
  # 社内のコアスイッチをSNMPv2cで監視する例
  core-switch-01:
    device_name: core-switch-01
    device_ip: 192.168.1.1
    snmp_comm: public       # SNMPv2cのコミュニティ名を指定
    user_tags:              # 検索しやすいようにタグを付与
      owning_team: network_team
      role: core_switch

global:
  poll_time_sec: 60         # 60秒間隔でポーリング
  # MIBの指定なども可能ですが、今回はデフォルトで進めます

Step 4: ktranslateの起動

設定ファイルが準備できたら、ktranslateを起動します。ここでは代表的な2つの方法を紹介します。

方法1：Dockerで起動する（推奨）

コンテナを利用することで、環境を汚さずに手軽に実行できます。

# APIキーとアカウントIDを環境変数にセット
export NEW_RELIC_API_KEY="YOUR_NEW_RELIC_INGEST_LICENSE_KEY"
export NEW_RELIC_ACCOUNT_ID="YOUR_NEW_RELIC_ACCOUNT_ID"

# Dockerコンテナをバックグラウンドで起動
docker run -d --name ktranslate-npm --restart unless-stopped \
  -v `pwd`/snmp-base.yaml:/snmp-base.yaml \
  -e NEW_RELIC_API_KEY \
  -e NEW_RELIC_ACCOUNT_ID \
  kentik/ktranslate:v2 \
  -snmp /snmp-base.yaml

YOUR_NEW_RELIC_INGEST_LICENSE_KEYとYOUR_NEW_RELIC_ACCOUNT_IDは、ご自身のNew Relicアカウントのものに置き換えてください。 -vオプションで、先ほど作成したsnmp-base.yamlをコンテナ内にマウントしています。

方法2：Linuxパッケージ版を利用する場合

Dockerを利用できない環境では、Debian/RPMといったパッケージを直接サーバーにインストールすることも可能です。

その場合、設定ファイル（snmp-base.yaml）は/etc/ktranslate/ディレクトリに配置し、APIキーなどの環境変数は/etc/default/ktranslateファイルに記述します。

インストール後は、systemdを使ってサービスとして起動・管理します。

# サービスを起動
sudo systemctl start ktranslate

# OS起動時に自動で起動するように設定
sudo systemctl enable ktranslate

Step 5: New Relicでデータを確認

エージェントが無事に起動すると、ktranslateは設定ファイルに基づき、定期的に監視対象へPingやSNMPのポーリングを開始し、その結果をNew Relicへ送信します。

データがNew Relicに届いているかは、Logsメニューなどでcollector.name:"ktranslate"のようなクエリを実行することで確認できます。

そして、収集したデータを組み合わせることで、以下のようなダッシュボードを作成できます。

まとめ

今回は、ネットワーク監視の最も基本的な要素であるPingとSNMPについて解説し、ktranslateエージェントを使った具体的な監視方法を実践しました。

Ping (ICMP): 機器がネットワーク上で応答可能かを確認する「死活監視」の基本。
SNMP: 機器のCPUやトラフィック量などの詳細な「性能情報」を取得するためのプロトコル。
SNMPの限界: 広帯域化に伴う「32bitカウンターのラップ問題」など、技術的な限界から、業界はAPIベースの新しい手法へ移行しつつある。
ktranslate: DockerやLinuxパッケージで導入でき、YAMLファイルで設定するだけでPingやSNMPのデータをNew Relicに送信できる強力なエージェント。

これらの「古典的」とも言える技術は、今なお多くの現場で稼働している重要な監視手法です。その仕組みと限界を正しく理解することが、次世代の可観測性を学ぶ上での確かな一歩となります。

次回予告

PingとSNMPで収集できるパフォーマンスデータは、いわば機器の「バイタルサイン」です。しかし、問題の原因が必ずしもこれらの数値に表れるとは限りません。時には、機器自身が発する「つぶやき」に耳を傾ける必要があります。

次回、【基礎②】Syslogで機器の"つぶやき"を聞くでは、パフォーマンスデータだけではわからない障害の予兆や原因を、機器が出力するSyslogから読み解くテクニックを解説します。ご期待ください。

By 伊藤覚宏, LeadTechnicalSupportEngineer

New Relic株式会社　リードテクニカルサポートエンジニア OSSの運用監視ソフトウェアの日本におけるテクニカルサポート、テクニカルトレーニングの立ち上げを行い、VMwareベースのクラウドサービス開発、AWSテクニカルサポート、クラウドアーキテクトを経て現職。テクニカルサポート、テクニカルトレーニング、運用コンサルを専門領域としてお客様の運用負荷軽減を目指す。得意分野は運用設計、クラウド設計、OSSソフトウェア。

本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。

780+ インテグレーションを導入し、スタック監視を無料で開始しましょう

詳細を見る

In this article