SNMP Trap と Heartbeat監視 ─ 仕組みと設計上の役割を整理する

はじめに

インフラ監視には大きく2つのパターンがある。

• ポーリング型：監視側が定期的に対象に問い合わせる
• イベント駆動型：対象側から異常を通知してくる

SNMP Trap は後者の代表例であり、Heartbeat はノード間の死活を相互確認するための仕組みである。本記事では両者の技術仕様・動作フロー・設計上の位置づけを整理する。

---

1. SNMP の基礎

SNMP とは

SNMP（Simple Network Management Protocol）はネットワーク機器やサーバのステータスを管理するためのプロトコルで、UDP を使用する。

バージョン	特徴
SNMPv1	基本的な GET/SET/Trap。認証はコミュニティ文字列のみ
SNMPv2c	バルク転送やエラー処理を強化。認証はコミュニティ文字列のまま
SNMPv3	認証（Auth）と暗号化（Priv）をサポート。現在の推奨バージョン

ポーリング型との比較

通常の SNMP ポーリングは、監視サーバが定期的に対象機器へ GET リクエストを送り状態を取得する。

---

2. SNMP Trap

概要

SNMP Trap はポーリング型とは逆方向で、機器側からイベント発生を能動的に通知する仕組みである。問い合わせを待たずに即時通報できるため、障害検知のリードタイムを短縮できる。

使用ポートは UDP/162（Trap 受信側）。

動作フロー

Trap の種類（主要なもの）

Trap 名	意味
coldStart	エージェントが初期化・起動した
warmStart	エージェントが再起動した（設定は保持）
linkDown	インタフェースがダウンした
linkUp	インタフェースがアップした
authenticationFailure	認証失敗（不正なコミュニティ文字列など）
Enterprise Trap	ベンダー独自の通知（ディスク障害・温度超過など）

RHEL での受信設定

RHEL では net-snmp パッケージに含まれる snmptrapd が Trap を受信する。

# パッケージインストール
dnf install net-snmp

# 受信設定（/etc/snmp/snmptrapd.conf）
authCommunity log,execute,net public
traphandle default /usr/bin/snmptthandler

# サービス起動
systemctl enable --now snmptrapd

# ログ確認
journalctl -u snmptrapd -f

SNMPv3 での Trap 設定例

# SNMPv3 ユーザー作成
net-snmp-config --create-snmpv3-user -ro -A authpass -X privpass -a SHA -x AES trapuser

# snmptrapd.conf
createUser -e <engineID> trapuser SHA authpass AES privpass
authUser log,execute,net trapuser

---

MIB（Management Information Base）と OID の関係

MIB とは

SNMP の通信プロトコルレベルでは、Trap の内容は OID（Object Identifier）と呼ばれる数値の羅列として送受信される。MIB はこの数値と人間が読める名前を対応づける定義ファイルである。

# OID（数値）のまま              MIB で解釈した名前
1.3.6.1.6.3.1.1.5.3     →     SNMPv2-MIB::linkDown
1.3.6.1.6.3.1.1.5.4     →     SNMPv2-MIB::linkUp
1.3.6.1.2.1.2.2.1.8     →     IF-MIB::ifOperStatus

MIB の要否

側	MIB の要否	理由
送信側（エージェント）	不要	OID 数値として Trap を送出する
受信側（snmptrapd）	運用上必須	ないと OID が数値のまま残り、障害内容の判読・アラート対応が困難になる

MIB なし / あり の受信ログ比較

# MIB なし（OID が数値のまま）
snmptrapd: 2026-03-12 10:23:44 localhost [UDP: [127.0.0.1]:54321]:
  1.3.6.1.2.1.1.3.0 = Timeticks: 12345
  1.3.6.1.6.3.1.1.4.1.0 = OID: 1.3.6.1.6.3.1.1.5.3

# MIB あり（名前に変換される）
snmptrapd: 2026-03-12 10:23:44 localhost [UDP: [127.0.0.1]:54321]:
  DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: 12345
  SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-MIB::linkDown

MIB の配置方法（RHEL）

# 標準 MIB の配置先
/usr/share/snmp/mibs/

# ベンダー提供の MIB を追加する場合（機器付属の .mib ファイル）
cp VENDOR-DEVICE.mib /usr/share/snmp/mibs/

# /etc/snmp/snmp.conf で読み込み対象を追加
echo "mibs +VENDOR-DEVICE-MIB" >> /etc/snmp/snmp.conf

# 全 MIB を読み込んで snmptrapd を起動（確認用）
snmptrapd -m ALL -f -Lo

Enterprise Trap と MIB

ベンダー独自の Enterprise Trap（ディスク障害・温度超過など）は、標準 MIB には定義されていない。対応する MIB ファイルをベンダーから入手し受信側に配置しないと、OID が数値のまま残り障害種別の特定ができない。

---

3. Heartbeat（ハートビート）

概要

Heartbeat は複数のノード間で定期的に生存確認パケットを送受信し、相手ノードの死活を監視する仕組みである。応答が途絶えた場合（Heartbeat ロスト）、クラスタソフトウェアや監視システムが障害と判断してフェイルオーバーや通知を行う。

動作フロー

Syslog への記録

Heartbeat ロストは Syslog に記録される。以下は Pacemaker / Corosync 構成の例。

Mar 12 10:23:44 server01 corosync[1234]: [TOTEM] A processor failed, forming new configuration.
Mar 12 10:23:45 server01 pacemaker-controld[5678]: notice: Node node02 state is now lost
Mar 12 10:23:45 server01 pacemaker-schedulerd[9012]: warning: Node node02 is unclean
Mar 12 10:23:46 server01 pacemaker-controld[5678]: notice: Initiating stop operation on node02

主な利用場面

場面	実装例
Linux HA クラスタ	Pacemaker + Corosync
仮想化基盤	VMware vSphere HA
コンテナ基盤	Kubernetes の livenessProbe
ロードバランサ	AWS ELB ヘルスチェック
DNS フェイルオーバー	Route 53 ヘルスチェック

Corosync のパラメータ例

# /etc/corosync/corosync.conf（抜粋）
totem {
    token:          5000      # Heartbeat タイムアウト（ミリ秒）
    token_retransmits_before_loss_const: 10  # 再送試行回数
    join:           60
    consensus:      6000
}

---

4. SNMP Trap と Heartbeat の比較

観点	SNMP Trap	Heartbeat
通信方向	単方向（機器 → 監視サーバ）	双方向（ノード間）
検知の契機	異常イベント発生時に送信	定期パケットの途絶で検知
主な対象	NW機器・ハードウェア	クラスタノード・アプリプロセス
プロトコル	UDP/162（SNMP）	TCP/UDP（実装依存）
通知の性質	「異常が起きた」という通報	「生存継続中」の継続確認

---

5. 監視設計における位置づけ

インフラ監視はオブザーバビリティの3本柱（Metrics / Logs / Traces）と対応させると整理しやすい。

AWS上での対応サービス

オンプレの仕組み	AWS での対応
SNMP Trap（機器障害通知）	CloudWatch Alarm + SNS
SNMP ポーリング（CPU・メモリ等）	CloudWatch Metrics（EC2デフォルト）
Heartbeat（HA構成）	ELB ヘルスチェック / Route 53 ヘルスチェック
Heartbeat（コンテナ）	ECS ヘルスチェック / Kubernetes livenessProbe
Syslog 集約	CloudWatch Logs Agent / Fluent Bit → CloudWatch Logs

---

まとめ

• SNMP Trap はイベント駆動型の障害通知。機器側から能動的に Trap を送信し、snmptrapd が受信する。SNMPv3 を使用することで認証と暗号化が可能。
• MIB は OID 数値を人間が読める名前に変換する定義ファイル。送信側には不要だが、受信側に配置しないと障害内容の判読が困難になる。ベンダー独自の Enterprise Trap には対応する MIB を別途入手して配置する必要がある。
• Heartbeat は定期的な生存確認パケットによるノード死活監視。応答途絶が Syslog に記録され、クラスタソフトウェアがフェイルオーバーを判断する際の根拠となる。
• 両者は検知の性質が異なる。SNMP Trap は「何が起きたか」の通報、Heartbeat は「生きているか」の継続確認である。設計時はどちらの異常検知パスが必要かを明確にした上で監視方式を選択する。