ZabbixでMongoDBモニタリングを100%完成させる方法

関連記事 :

モニタリング指標に関する考察（第5編：MongoDB）

（ベアメタル / Kubernetes Pod 環境フル対応、Agent2 プラグイン基盤）

Zabbix 7.4 では、MongoDB モニタリングのためにユーザー独自スクリプトを追加する必要はない。Zabbix Agent2 に内蔵された MongoDB プラグインだけで、WiredTiger、Replication、Connection など主要な指標を自動取得できる。ただし実際の運用環境は次の2つに分かれる。

① MongoDB がベアメタル（物理 / VM）サーバーで稼働
② MongoDB が Kubernetes Pod 内で動作し、Service で公開されている環境

この2つはネットワーク構造が大きく異なるため、Agent2 の設定方式も変わる。本稿は Zabbix 7.4 を基準とした実務ガイドである。

1. 対応バージョン

Zabbix

Zabbix Server/Proxy 7.4 以上（6.x でも動作可能だがプラグイン互換性を考慮）
Zabbix Agent2 MongoDB プラグイン有効化

MongoDB エンジン

MongoDB 4.x ～ 7.x

ReplicaSet モニタリング（Node セッション基盤）

ReplicaSet を正確に監視するには、以下2つの要素が必須となる。

各ノードの性能指標（WiredTiger、Cursor、Connections など）
ReplicaSet 全体の状態（rs.status ベースの集約情報）

しかし、この2つを単一ホストに統合することは不可能である。
そのため ReplicaSet = 各ノードを独立したホストとして登録し、個別に性能指標を収集する方式が正解となる。

※ 注意点
Zabbix は ReplicaSet 専用の「Cluster テンプレート」を提供していない。
（MongoDB cluster by Zabbix agent 2 テンプレートは sharded cluster mongos 専用であり、ReplicaSet とは無関係）

ReplicaSet を監視する場合は、以下のガイドが最も正確な方法となる。

▶ Kubernetes 環境 vs ベアメタル環境の構造的違い

■ Kubernetes 環境で可能な理由

Kubernetes では MongoDB Pod がどのノードで稼働していても、
Zabbix Agent2 がインストールされたノード OS から Service（ClusterIP / LoadBalancer IP）を通して全 Pod にアクセスできる。

まとめると：

Agent2 = ホストノード
MongoDB = Pod
通信 = CNI ネットワークが自動保証

→ そのため ReplicaSet であっても Agent2 内で複数セッションを構成してモニタリングできる。

■ ベアメタル環境ではノードごとに Agent2 を設置するのが基本

物理サーバー（または VM）の ReplicaSet 構成では次のような関係となる。

mongo01 サーバー ↔ mongo01 の Agent2
mongo02 サーバー ↔ mongo02 の Agent2
mongo03 サーバー ↔ mongo03 の Agent2

各 MongoDB はそのサーバー上の Agent2 と 1:1 である必要がある。
他ノードへセッションを構成しても、完全な性能取得ができない場合がある。

→ よってベアメタル ReplicaSet では、全ノードに Agent2 を設置することが正しい方法となる。

▶ Agent2 の mongodb.conf — セッション (Name Session) 定義

ReplicaSet の各ノードへアクセスするため、以下のようにセッションを構成する。

■ ReplicaSet（3ノード）の例

Plugins.Mongodb.Sessions.rs01.Uri=tcp://mongo01_IP:27017
Plugins.Mongodb.Sessions.rs01.User=zbx_monitor
Plugins.Mongodb.Sessions.rs01.Password=<password>

Plugins.Mongodb.Sessions.rs02.Uri=tcp://mongo02_IP:27017
Plugins.Mongodb.Sessions.rs02.User=zbx_monitor
Plugins.Mongodb.Sessions.rs02.Password=<password>

Plugins.Mongodb.Sessions.rs03.Uri=tcp://mongo03_IP:27017
Plugins.Mongodb.Sessions.rs03.User=zbx_monitor
Plugins.Mongodb.Sessions.rs03.Password=<password>

→ ReplicaSet で必要なのはこれだけである。

▶ Zabbix Web UI — Host 構成

■ 各 ReplicaSet ノードを個別ホストとして登録（3ホスト）

ホスト設定例：

Host	Macro 値
mongo01	{$MONGODB.CONNSTRING}=rs01
mongo02	{$MONGODB.CONNSTRING}=rs02
mongo03	{$MONGODB.CONNSTRING}=rs03

各ホストに適用するテンプレート：

MongoDB node by Zabbix agent 2

→ WiredTiger, Cursor, Cache, Connection など、ノード単位の性能を正確に収集。

注意点

ベアメタル： 各物理サーバーに Agent2 必須
Kubernetes： Node OS 側の Agent2 一つで複数 Pod にアクセス可能

▶ Cluster テンプレートはどんな時に使うのか？

ReplicaSet では 使用しない。

Cluster テンプレートの用途は sharded cluster（mongos ベース）のみ。

mongos に適用
mongos が get_shards によりシャードノードを検出
検出された mongod ノードに Node テンプレートを自動適用

→ ReplicaSet には mongos が存在しないため使用不可。

まとめ：

ReplicaSet = Node テンプレートのみ
Sharded Cluster = Cluster + Node テンプレートの組み合わせ

▶ 全体構成まとめ

[mongo01] —— Node テンプレート —— rs01
[mongo02] —— Node テンプレート —— rs02
[mongo03] —— Node テンプレート —— rs03

ReplicaSet のポイント：

Node テンプレート = 個別ノードの性能監視
Kubernetes = Agent2 一つで複数セッション可能
ベアメタル = ノードごとに Agent2 必須
Cluster テンプレート = sharding 専用

▶ 次のガイド（Standalone 基準）

以降の実践ガイドでは ReplicaSet ではなく単一 MongoDB ノードを基準に説明する。
複数ノードでも基本は同じで、少し応用すればよい。

テンプレート：MongoDB Node by Zabbix agent 2
URI：単一ノード
Session：1つだけ構成

2. MongoDB モニタリング用アカウント作成（共通）

MongoDB 認証利用時はモニタリング専用ユーザーを作成する。

use admin

db.createUser({
  user: "zbx_monitor",
  pwd: "<password>",
  roles: [
    { role: "clusterMonitor", db: "admin" },
    { role: "read", db: "local" }
  ]
})

db.getUser("zbx_monitor")

clusterMonitor：状態情報の取得に必要
local DB read：レプリケーション遅延情報に必要

3. Agent2 プラグインのインストールパス確認

MongoDB プラグインが正常にインストールされていれば、以下に配置される。

4. テンプレートマクロ方式 vs Agent2 セッション方式

どちらも動作するが性質が異なる。

✔ テンプレートマクロ方式

Zabbix UI のマクロで Agent2 設定を上書きする方式。

{$MONGODB.CONNSTRING} = tcp://192.168.117.5:27017
{$MONGODB.USER}      = zbx_monitor
{$MONGODB.PASSWORD}  = <password>

利点： UI だけで素早く修正可能
欠点： パスワードが UI に露出する

✔ Agent2 セッション方式（推奨）

# デフォルト値
Plugins.Mongodb.Sessions.*.Uri=
Plugins.Mongodb.Sessions.*.User=
Plugins.Mongodb.Sessions.*.Password=

# 変更値
Plugins.Mongodb.Sessions.example_mongodb.Uri=tcp://192.168.117.5:27017
Plugins.Mongodb.Sessions.example_mongodb.User=zbx_monitor
Plugins.Mongodb.Sessions.example_mongodb.Password=<password>

Zabbix 側では：

{$MONGODB.CONNSTRING} = example_mongodb

プラグイン構成のヒント

(A) Default のみ使用する単一 MongoDB の場合

Plugins.Mongodb.Default.Uri=tcp://...
Plugins.Mongodb.Default.User=...
Plugins.Mongodb.Default.Password=...

(B) Sessions 構造で複数インスタンスを監視する場合

セッション名を変えて複数定義するだけでよい。

5. Kubernetes Pod MongoDB モニタリング

Agent2 はホスト OS 側で実行され、MongoDB は Pod 内で動作する。
ClusterIP は外部からアクセスできないため、Service（NodePort または LoadBalancer）経由が必須。

最も実務的なのは LoadBalancer External IP 方式。

例：

Agent2 → Service External IP → MongoDB Pod
192.168.117.90:27017

Plugins.Mongodb.Sessions.K8s.Uri=tcp://192.168.117.90:27017
Plugins.Mongodb.Sessions.K8s.User=zbx_monitor
Plugins.Mongodb.Sessions.K8s.Password=<password>

Zabbix：

{$MONGODB.CONNSTRING} = K8s

6. 主要監視指標

MongoDB プラグインは以下を取得する。

Connections

現在接続数
最大接続数に対する使用率
トリガーマクロ：{$MONGODB.CONNS.PCT.USED.MAX.WARN}

Cursors

オープンカーソル数
タイムアウト比率
トリガー：{$MONGODB.CURSOR.TIMEOUT.MAX.WARN} 等

WiredTiger

読み書きチケットの利用可能数
{$MONGODB.WIRED_TIGER.TICKETS.AVAILABLE.MIN.WARN}

7. トラブルシューティング

1) ベアメタル環境

URI ミス（tcp:// の欠落、ポート誤り）
mongod.conf の bindIp が 127.0.0.1 → 外部アクセス不可
Firewall による 27017 ポート遮断
SELinux / AppArmor が Agent2 の接続をブロック

2) Kubernetes 環境

NetworkPolicy が Agent2 からのアクセスを拒否している
LoadBalancer External IP の変更
Readiness Probe が失敗し Service から除外されている

8. 結論

Zabbix 7.4 での MongoDB モニタリングは、次の一文に要約される。

「Agent2 が MongoDB に接続できる URI を正しく指定すれば、残りはすべて自動で完了する。」

プラグインパス：/etc/zabbix/zabbix_agent2.d/plugins.d/
6.0 以降、UserParameter は不要
Kubernetes では External IP を利用
最も安定・安全・拡張性が高いのはセッション方式

ベアメタルでも Pod でも、URI が正確であれば Zabbix は環境に左右されない強力な MongoDB 監視基盤となる。

🛠 마지막 수정일: 2025.12.09

💡 お困りですか？
Zabbix、Kubernetes、各種オープンソースインフラの構築・運用・最適化・障害解析が必要であれば、いつでもご連絡ください。

📧 メール: jikimy75@gmail.com
💼 サービス: 導入支援 | 性能チューニング | 障害解析コンサルティング