Zabbixの「死」を回避せよ：データベース肥大化を完封するパーティショニング極限攻略
Zabbixを運用するエンジニアの多くが、ある日突然、地獄の門を叩くことになる。「データベースのレスポンスが極端に低下し、GUIがタイムアウトする」「ハウスキーパー（Housekeeper）がCPUを100%消費し、監視データが欠落し始める」という現象だ。
Zabbixの標準ハウスキーパーは、データの削除において極めて「非効率なクエリ」を投げる。数千万行のテーブルに対する `DELETE FROM history WHERE clock < ...` は、PostgreSQLやMySQLにとって致命的なI/O負荷とインデックス断片化を招く。 本稿では、標準機能に依存する甘えを捨て、DBの物理層からZabbixを支配下に置くための「真の運用解」を提示する。 ---
1. なぜ標準ハウスキーパーは「悪」なのか
Zabbixのハウスキーパーは、内部で大量のDELETEを発行する。これは、巨大なB-Treeインデックスの再構築を伴うため、物理ストレージへの負荷が無視できない。また、行数が膨大になると、DELETE処理中にテーブルロックが発生し、監視データの挿入（INSERT）が待機状態となる。
結論：大規模環境において、ハウスキーパーは「無効化」すべきだ。
`zabbix_server.conf` で以下を設定し、DB側で制御するアーキテクチャへ移行せよ。
ハウスキーパーを無効化する
HousekeepingFrequency=0
—
2. PostgreSQLにおけるパーティショニングの神髄
PostgreSQLを選択している場合、`pg_partman` はもはや必須ツールだ。Zabbixのテーブルを「時間軸」で分割し、古いデータを「DROP TABLE」で物理消去する。これは DELETE 処理とは比較にならないほど高速で、I/O負荷は皆無に等しい。
実装手順の要諦
1. テーブルの拡張: `history`, `history_uint`, `trends` などの主要テーブルを、`clock` カラムをベースにした `RANGE` パーティションへと変換する。
2. `pg_partman` の導入: 拡張機能を作成し、自動パーティション管理をスケジューリングする。
— 拡張の有効化
CREATE EXTENSION pg_partman;
— パーティション管理の設定（例：1日単位でローテーション）
SELECT partman.create_parent(
p_parent_table => ‘public.history’,
p_control => ‘clock’,
p_type => ‘native’,
p_interval => ‘daily’,
p_retention => ’30 days’ — 30日経過後に自動DROP
);
この設定により、Zabbixがデータを書き込むのは「最新のパーティション」のみとなり、インデックスの肥大化を物理的に阻止できる。
—
3. MySQL/MariaDBにおける設計思想
MySQLの場合、`RANGE` パーティションを使用する。注意すべきは、プライマリキーにパーティションキー（clock）を含める必要があるという制約だ。Zabbixの既存テーブル構造を変更するには、ALTER TABLEの際にテーブルロックが発生するため、スタンバイ機での検証またはオンラインマイグレーションツール（`gh-ost` 等）の使用を強く推奨する。
自動メンテナンススクリプトのハック
MySQLのパーティション管理を自動化するPythonスクリプト例を示す。これをCRONで回し、常に未来のパーティションを確保せよ。
!/usr/bin/env python3
import mysql.connector
DBコネクション定義
conn = mysql.connector.connect(user=’zabbix’, password=’…’, host=’localhost’, database=’zabbix’)
cursor = conn.cursor()
def create_next_partition(table_name, clock_val):
# パーティション名の生成（例: p20231027）
partition_name = f”p{clock_val}”
sql = f”ALTER TABLE {table_name} ADD PARTITION (PARTITION {partition_name} VALUES LESS THAN ({clock_val}))”
cursor.execute(sql)
運用上、常に未来の7日分を確保するロジックをここに実装
…
—
4. パフォーマンスを極限まで引き上げる「禁断のチューニング」
データベースだけを最適化しても、Zabbixサーバー本体がボトルネックになっては意味がない。以下のハックを注入せよ。
A. データベースとの接続効率化
`zabbix_server.conf` の `StartDBSyncers` は、ディスクI/Oと相談しつつ、可能な限り大きく設定する。通常は16-32程度から開始し、`zabbix[process,history syncer,busy]` のグラフが80%を超えないように調整する。
B. PostgreSQLの共有バッファ最適化
PostgreSQLにおいて `shared_buffers` は物理メモリの25%程度を割り当てるのがセオリーだが、Zabbix特有の「最新のhistoryデータへの頻繁なアクセス」を考慮し、`effective_cache_size` を物理メモリの75%以上に設定せよ。これにより、OSキャッシュを最大限に活用し、ディスクアクセスを極小化できる。
C. NVMeストレージへの物理配置
高負荷なZabbix環境において、ストレージのI/O Waitは死を意味する。`history` テーブルのみを、WAL（Write Ahead Log）とは別の物理NVMeデバイスへ `TABLESPACE` を分けて配置せよ。書き込み競合を分離するだけで、システム全体のレスポンスが劇的に改善する。
—
最後に：オブザーバビリティのプロとして
Zabbixの真の運用とは、ツールを「使いこなす」ことではない。「いかにしてZabbixを、管理コストのかからない透明な存在にするか」である。
今回紹介したパーティショニングとハウスキーパーの無効化は、単なるDB設定ではない。それは、Zabbixという巨大なシステムを、あなたの手元で完全に制御下に置くための「アーキテクチャ的支配」だ。
インフラは自動化されるべきであり、監視システムそのものが監視対象に負荷をかけるような本末転倒な事態は、今日で終わりにしよう。君の環境が、何千万アイテムの監視下にあっても、GUIがサクサクと動き続けることを期待している。