Zabbix基盤の要塞化：PostgreSQLレプリケーション遅延の完全メトリクス化と「監視者なき監視」の極意
世の中の多くのエンジニアリングチームは、監視ツールである「Zabbix」を用いてインフラの生死を見張っている。だが、「Zabbix自身が依存するバックエンドデータベース」や「その高可用性（HA）レプリケーション基盤」が沈黙した時、誰がそれを検知するのか？ この問いに即答できないアーキテクトは、設計の初期段階で敗北していると言っていい。
監視システムは、システム全体の中で最も信頼性が高く、最も強靭でなければならない。本稿では、Zabbixのバックエンドとして広く採用されるPostgreSQLを対象に、ストリーミングレプリケーションの遅延を「ミリ秒単位かつ正確」にメトリクス化する極限のクエリ設計と、Zabbix自身がダウンした際にも検知網を逃れない「外部死活監視」のアーキテクチャを、一切の妥協を排して解説する。
—
1. なぜZabbixのバックエンドDB監視は破綻しやすいのか
Zabbixサーバーは、毎秒数万件のヒストリデータをトランザクションとしてPostgreSQLに叩き込む。この高負荷な書き込み基盤を保護するため、多くの現場ではプライマリ・スタンバイ構成（ストリーミングレプリケーション）を組んでいる。
しかし、ここでエンジニアを絶望させる「構造的ジレンマ」が発生する。
1. レプリケーション遅延の「見かけ上の嘘」：
PostgreSQLのデフォルト機能や単純な `pg_stat_replication` の参照だけでは、ネットワークの瞬断や重いバキューム処理による「真の遅延バイト数・ラグ時間」を正確に把握できない。特にLCR（Log-Sequence Number）の差分計算を誤ると、遅延しているのに「遅延なし」と誤認する死の罠を踏む。
2. 監視者不在のパラドックス：
Zabbixサーバー自体が死ぬ、あるいはバックエンドのPostgreSQLがスプリットブレインやロック競合でフリーズした瞬間、Zabbixによるアラート発報は完全に停止する。「気づいた時にはビジネスが数時間停止していた」という障害の多くは、この「監視対象が監視ツールを兼ねている構造」に起因する。
この2つの急所を、低レイヤのSQLと堅牢な外形監視スクリプトによって完全にハックする。
—
2. PostgreSQLストリーミングレプリケーション遅延の正確なメトリクス化
スタンバイ側（リードレプリカ）の遅延を正確に測定するには、プライマリのWAL生成位置と、スタンバイのreplay（再生）位置のバイト差分、およびタイムスタンプのラグを同時に監視する必要がある。
以下のSQLクエリは、PostgreSQLの内部LSN（Log Sequence Number）関数を駆使し、バイト単位の正確な遅延量と、ミリ秒単位の経過時間を算出するプロダクション品質のクエリである。これをZabbixエージェントのUserParameter（あるいはCustomQuery）としてインジェクトする。
究極のレプリケーション監視SQL（プライマリ側で実行）
SELECT
application_name,
client_addr,
state,
sync_state,
— 1. WALの書き込み・フラッシュ・リプレイの各段階における遅延バイト数
pg_wal_lsn_diff(pg_current_wal_lsn(), sent_lsn) AS
sent_lag_bytes,
pg_wal_lsn_diff(sent_lsn, write_lsn) AS
write_lag_bytes,
pg_wal_lsn_diff(write_lsn, flush_lsn) AS
flush_lag_bytes,
pg_wal_lsn_diff(flush_lsn, replay_lsn) AS
replay_lag_bytes,
— 2. 時間軸での遅延（タイムスタンプベース）
COALESCE(EXTRACT(EPOCH FROM (clock_timestamp() – backend_xmin)), 0) AS
xmin_age_seconds,
— 3. レプリカの最終応答からの経過時間（秒）
EXTRACT(EPOCH FROM (now() – last_msg_receipt_time)) AS
seconds_since_last_heartbeat
FROM
pg_stat_replication;
アーキテクトの急所解説：なぜ `replay_lag_bytes` なのか？
単に `pg_stat_replication` のステータスを見るだけでは不十分だ。`replay_lag_bytes`（プライマリの現在位置と、スタンバイで適用が完了した位置の差）こそが、「データ損失の潜在リスク」および「読み取り整合性の遅れ」を正確に示す唯一の指標となる。この数値をZabbixへ送り、閾値を超えた瞬間にPagerDutyやSlackへ緊急のエスカレーションを飛ばすパイプラインを構築する。
—
3. Zabbixエージェントによる自動メトリクス収集の実装
上記クエリをZabbixから安全かつ高パフォーマンスに取得するため、シェルスクリプトとZabbixエージェントの設定を最適化する。コネクションスパイクを防ぐため、psqlの接続プールやタイムアウトを厳格に管理する。
`/etc/zabbix/zabbix_agentd.d/postgresql_replication.conf`
PostgreSQLストリーミングレプリケーション監視用UserParameter
接続ユーザ（例: zabbix_monitor）には pg_monitor 権限が付与されていること
リプレイ遅延バイト数の取得
UserParameter=custom.pg.replication.replay_lag_bytes,psql -U zabbix_monitor -d postgres -t -c “SELECT COALESCE(pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn), 0) FROM pg_stat_replication WHERE application_name = ‘standby_node_01’;” | tr -d ‘[:space:]’
レプリカのハートビートからの経過時間（秒）
UserParameter=custom.pg.replication.lag_seconds,psql -U zabbix_monitor -d postgres -t -c “SELECT COALESCE(EXTRACT(EPOCH FROM (now() – last_msg_receipt_time)), 999) FROM pg_stat_replication WHERE application_name = ‘standby_node_01’;” | tr -d ‘[:space:]’
> パフォーマンス・ハック:
> 大規模環境では、エージェントが毎回 `psql` プロセスを起動するコスト（fork/execのオーバーヘッド）が無視できなくなる。極限までチューニングを施す場合は、PythonやGoで常駐型のデーモン（またはZabbix Senderを直接叩くスクリプト）を作成し、コネクションを維持した状態でプッシュ型（Zabbix Trapper）でメトリクスを流し込むアーキテクチャへ昇華させるべきだ。
—
4. DB障害時にZabbix自身が検知できなくなるジレンマを防ぐ「外部死活監視」設計
ZabbixサーバーやそのバックエンドDBがクラッシュした時、Zabbix内部のトリガーは完全に沈黙する。この「監視者の盲点」を完全に排除するため、Zabbixのインフラストラクチャの外側から、完全に独立した死活監視機構（Watchdog）を構築する。
ここでは、軽量かつアトミックに動作するPythonスクリプトによる外形監視と、それをAWS Lambdaや別系統のミニマムなコンテナ環境から定期実行する設計を提示する。
独立型外形監視スクリプト (`zabbix_watchdog.py`)
このスクリプトは、以下の2点を同時に検証する。
1. Zabbixフロントエンド/APIの健全性（HTTP 200かつログインセッションが確立できるか）
2. PostgreSQLバックエンドの生死（直接DBに接続し、簡易クエリがミリ秒単位で返るか）
!/usr/bin/env python3
import sys
import psycopg2
import requests
from datetime import datetime
設定値
PG_DSN = “dbname=zabbix user=zabbix_monitor password=’secure_password’ host=db.internal.net port=5432 connect_timeout=5”
ZABBIX_API_URL = “https://zabbix.internal.net/api_jsonrpc.php”
ALERT_WEBHOOK_URL = “https://hooks.slack.com/services/T00/B00/X00” # 緊急通知用直接Webhook
def send_emergency_alert(message):
“””Zabbixを経由できないため、直接Slack等に緊急通知を送る”””
payload = {“text”: f”🚨 【CRITICAL】Zabbixインフラ基盤障害検知: {message} @ {datetime.utcnow().isoformat()}”}
try:
requests.post(ALERT_WEBHOOK_URL, json=payload, timeout=5)
except Exception as e:
print(f”Failed to send emergency alert: {e}”, file=sys.stderr)
def check_postgresql():
try:
conn = psycopg2.connect(PG_DSN)
cur = conn.cursor()
cur.execute(“SELECT 1;”)
cur.fetchone()
cur.close()
conn.close()
return True
except Exception as e:
send_emergency_alert(f”PostgreSQL Backend DOWN or Unresponsive: {str(e)}”)
return False
def check_zabbix_api():
headers = {“Content-Type”: “application/json-rpc”}
payload = {
“jsonrpc”: “2.0”,
“method”: “apiinfo.version”,
“params”: {},
“id”: 1
}
try:
response = requests.post(ZABBIX_API_URL, json=payload, headers=headers, timeout=5)
if response.status_code != 200:
send_emergency_alert(f”Zabbix Frontend returned HTTP {response.status_code}”)
return False
result = response.json()
if “result” not in result:
send_emergency_alert(f”Zabbix API returned invalid response: {result}”)
return False
return True
except Exception as e:
send_emergency_alert(f”Zabbix Frontend/API UNREACHABLE: {str(e)}”)
return False
if __name__ == “__main__”:
pg_ok = check_postgresql()
api_ok = check_zabbix_api()
if not pg_ok or not api_ok:
sys.exit(2)
print(“OK: Zabbix and PostgreSQL backend are healthy.”)
sys.exit(0)
運用アーキテクチャの要諦
- 実行環境の分離：このスクリプトは、監視対象のZabbixサーバーとは完全に異なるネットワークセグメント（例: 別クラウドのVPC、あるいはオンプレミスの別ラックのK8sクラスター）から、CronまたはKubernetes CronJobとして1分毎に実行する。
- フェイルセーフの二重化：万が一Zabbixがダウンした場合、このスクリプトが直接SlackやPagerDutyにアラートを叩き込むため、「誰も気づかない監視の空白期間」を物理的にゼロにする。
—
5. エキスパートの知見：メモリ消費とDBチューニングの極意
ZabbixのバックエンドPostgreSQLにおいて、レプリケーション遅延やパフォーマンス劣化を引き起こす最大のボトルネックは、往々にして「バキューム（Vacuum）の遅延」と「インデックスの肥大化（Bloat）」である。
大量のヒストリデータとトレンドデータが高速に流し込まれる環境では、以下のPostgreSQLパラメータチューニングを怠ると、レプリカとの間に致命的なラグが発生する。
/etc/postgresql/15/main/postgresql.conf の推奨重要パラメータ
1. チェックポイントの平準化（I/Oスパイクによるレプリケーション遅延の防止）
checkpoint_completion_target = 0.9
max_wal_size = 16GB
min_wal_size = 2GB
2. 自動バキュームの積極化（デッドタプルの滞留を防ぎ、LSNの進行をスムーズにする）
autovacuum_max_workers = 6
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.02
autovacuum_vacuum_cost_limit = 1000
autovacuum_vacuum_cost_delay = 2
3. ストリーミングレプリケーション側の許容量確保
プライマリ側でレプリカの切断を防ぐため、保持するWALの容量を十分に確保する
max_slot_wal_keep_size = 32GB
これらのチューニングを施し、本稿で紹介した高精度なLSN遅延監視と外部ウォッチドッグを組み合わせることで、初めて「真に信頼に足るオブザーバビリティ基盤」が完成する。
監視とは、ただツールを導入することではない。「監視インフラストラクチャ自体の脆弱性と向き合い、その信頼性を極限まで高め続けること」。これこそが、一流のアーキテクトに求められる唯一にして絶対の要件である。