こんにちは！現場でインフラやオブザーバビリティ（可観測性）に向き合っていると、「監視システムの監視をどうするか」「スケールする環境でZabbixをどう安定稼働させるか」という重い課題に直面しますよね。
今回は、長年オンプレミスの物理・仮想サーバーを支えてきた孤高の監視王「Zabbix」を、現代のコンテナインフラストラクチャ（Docker ComposeおよびKubernetes）上で美しく、かつ強靭に泳がせるためのベストプラクティスを授けましょう。
「コンテナでZabbix？ データが消えそう」「設定が複雑で挫折しそう」なんて心配は無用です。これをマスターすれば、あなたのインフラ運用は劇的に楽になり、深夜のアラート対応に怯える日々から解放されますよ。さあ、一緒にモダンなZabbixの世界へ飛び込みましょう！
—
Zabbixコンテナ化運用の全貌：なぜコンテナなのか？
そもそも、なぜZabbixをコンテナ化するのでしょうか？
従来の方式（RPMやaptでの直接インストール）では、OSのバージョンアップ依存、依存ライブラリの衝突、そして何より「スケールアウトの難しさ」や「環境移行の絶望感」がありました。
公式が提供するDockerイメージを活用すれば、Zabbix Server、Webフロントエンド、そしてデータベース（PostgreSQLやMySQL）を綺麗に分離し、コード（設定ファイル）としてインフラを管理できるようになります。
まずは、最も手軽でありながら本番のミニマム構成としても通用する Docker Compose から始め、Kubernetes (Helm)へとステップアップしていきましょう。
—
1. Docker Composeで構築する本番耐性のあるZabbix環境
「まずはDockerでさくっと動かしたい、でも手抜きはしたくない」。そんなあなたへ贈る、実戦投入可能なDocker Compose構成です。
ここでは、最も堅牢な組み合わせとされる 「Zabbix Server (Alpineベース) + Nginx + PostgreSQL」 の組み合わせを採用します。
ディレクトリ構成
zabbix-docker/
├── .env
├── docker-compose.yml
└──
環境変数設定 (`.env`)
パスワードやバージョンをハードコーディングせず、必ず環境ファイルに切り出します。これがセキュリティの第一歩です。
共通設定
ZBX_VERSION=6.0-latest
データベース設定
POSTGRES_DB=zabbix
POSTGRES_USER=zabbix
POSTGRES_PASSWORD=SuperSecretDatabasePassword123!
Docker Compose設定 (`docker-compose.yml`)
コンテナ永続化（Volumes）の肝となる部分に注目してください。データベースとZabbixのエージェント設定領域を確実にホスト（またはボリューム）へ逃がします。
version: ‘3.8’
services:
# 1. データベース (PostgreSQL)
postgres-server:
image: postgres:15-alpine
restart: always
environment:
POSTGRES_DB: ${POSTGRES_DB}
POSTGRES_USER: ${POSTGRES_USER}
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
volumes:
- pg-data:/var/lib/postgresql/data
networks:
- zabbix-net
healthcheck:
test: [“CMD-SHELL”, “pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}”]
interval: 10s
timeout: 5s
retries: 5
# 2. Zabbix Server
zabbix-server:
image: zabbix/zabbix-server-pgsql:${ZBX_VERSION}
restart: always
ports:
- “10051:10051”
environment:
- DB_SERVER_HOST=postgres-server
- POSTGRES_DB=${POSTGRES_DB}
- POSTGRES_USER=${POSTGRES_USER}
- POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
- ZBX_HISTORYSTORAGETYPE=database
ulimits:
nofile:
soft: 65535
hard: 65535
volumes:
- zabbix-alertscripts:/usr/lib/zabbix/alertscripts
- zabbix-externalscripts:/usr/lib/zabbix/externalscripts
depends_on:
postgres-server:
condition: service_healthy
networks:
- zabbix-net
# 3. Zabbix Web Frontend (Nginxベース)
zabbix-web:
image: zabbix/zabbix-web-pgsql-nginx:${ZBX_VERSION}
restart: always
ports:
- “80:8080”
- “443:8443”
environment:
- ZBX_SERVER_HOST=zabbix-server
- DB_SERVER_HOST=postgres-server
- POSTGRES_DB=${POSTGRES_DB}
- POSTGRES_USER=${POSTGRES_USER}
- POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
- PHP_TZ=Asia/Tokyo
depends_on:
- zabbix-server
networks:
- zabbix-net
volumes:
pg-data:
driver: local
zabbix-alertscripts:
driver: local
zabbix-externalscripts:
driver: local
networks:
zabbix-net:
driver: bridge
起動とHelloWorld的な動作確認
ターミナルを開き、以下のコマンドを叩くだけです。
docker compose up -d
数分後、ブラウザで `http://localhost` にアクセスしてください。
初期IDは `Admin`、パスワードは `zabbix` です。ログインできたら、おめでとうございます！これがコンテナ化されたZabbixの第一歩です。
—
2. Kubernetes (Helm) で実現するスケーラブルな監視基盤
コンテナ運用が大規模化してくると、Docker Composeの単一ホスト運用では耐えられなくなります。そこで登場するのが Kubernetes と公式 Helmチャート です。
プロフェッショナルな環境では、マニフェストをスクラッチで書くのは悪手です。公式がメンテナンスしているHelmチャートを使いこなしましょう。
リポジトリの追加とインストール
まずはZabbix公式のHelmリポジトリを追加します。
helm repo add zabbix-chart https://cdn.zabbix.com/zabbix/integrations/kubernetes/helm
helm repo update
本番用カスタムvalues.yamlの設計
Helmのデフォルト値のままでは、本番環境でデータベースがクラッシュした際にデータが消滅したり、リソース制限が曖昧だったりします。以下の `values-production.yaml` を作成してください。
Zabbix Serverの設定
zabbixServer:
image:
repository: zabbix/zabbix-server-pgsql
tag: 6.0-latest
pullPolicy: IfNotPresent
replicaCount: 1 # HA構成にする場合は2以上へ（要StatefulSetチューニング）
# リソースの適切な割り当て（監視対象数に応じて調整）
resources:
limits:
cpu: “2”
memory: 4Gi
requests:
cpu: “500m”
memory: 1Gi
# 永続ボリューム (PVC) の設定 – 外部スクリプト等を保持
persistence:
enabled: true
storageClass: “gp2” # クラウド環境に応じたStorageClassを指定
accessModes:
- ReadWriteOnce
size: 10Gi
Zabbix Webの設定
zabbixWeb:
image:
repository: zabbix/zabbix-web-pgsql-nginx
tag: 6.0-latest
resources:
limits:
cpu: “1”
memory: 1Gi
requests:
cpu: “200m”
memory: 256Mi
env:
PHP_TZ: “Asia/Tokyo”
データベース（内蔵PostgreSQLを使う場合、本番では外部RDS等を推奨）
postgresql:
enabled: true
auth:
database: zabbix
username: zabbix
password: “KubernetesSecretPassword999!”
primary:
persistence:
enabled: true
storageClass: “gp2”
size: 50Gi # 履歴データの容量に直結するため大きめに
デプロイの実行
以下のコマンドで、Kubernetesクラスター上に監視基盤を一撃で構築します。
helm install zabbix-prod zabbix-chart/zabbix-helm –values values-production.yaml
数分後、`kubectl get pods` ですべてのポッドが `Running` になっていることを確認してください。IngressやPort-forwardを経由して、先ほど同様にWeb UIへアクセスできます。
—
3. 現場で震えるほど重要な「永続化データ管理」の鉄則
コンテナ運用において、最も恐ろしいのは「ポッドの再起動やスケールインに伴うデータの消失」です。Zabbixにおけるデータとは、単なるログではなく「膨大な監視履歴（History/Trends）と設定情報」そのものです。
ここでは、現場で絶対に押さえておきたい3つの鉄則を授けます。
1. データベースのPVC（Persistent Volume Claim）は絶対にケチるな
Zabbixのディスク容量を圧迫する最大の要因は `history` および `trends` テーブルです。Docker ComposeやKubernetesのローカルストレージ（emptyDirなど）を使用することは絶対に避け、必ず信頼性の高いネットワークストレージ（AWS EBS, GCP PD, Azure Disk等）をPVC経由でマウントしてください。
2. データ保持期間（Housekeeping）の適切なチューニング
無限にデータを保存し続けると、どんなに巨大なストレージもすぐにパンクします。Zabbixのフロントエンドから以下を設定してください：
- Administration -> General -> Housekeeping
- 履歴（History）の保存期間: 30日〜90日程度に制限
- トレンド（Trends）の保存期間: 1年程度に制限
コンテナ環境では、データベースの肥大化はパフォーマンス低下だけでなく、バックアップ／リストア時間を致命的に引き延ばします。
3. 設定ファイル・外部スクリプトの外部化
アラート通知スクリプト（Alertscripts）や外部監視スクリプト（Externalscripts）をコンテナイメージの中に直接ビルドしてはいけません。必ずDocker VolumesやKubernetesのConfigMap / PVCを使用して、コンテナのライフサイクルから切り離して管理しましょう。これにより、イメージのアップデートが驚くほど安全になります。
—
おわりに：監視の未来は、あなたの手の中にある
今回は、Docker ComposeとKubernetesを活用したZabbixのコンテナ化運用について、本番を見据えた実践的な知見を解説しました。
コンテナ化されたZabbixは、もはや「手のかかるレガシーな監視ツール」ではありません。インフラのコード化（IaC）の波に乗り、極めてモダンで再現性の高い強力なオブザーバビリティ・プラットフォームへと生まれ変わります。
これをマスターしたあなたなら、どんな環境に放り出されても、揺るぎない監視基盤を素早く構築できるはずです。日々の運用が劇的に楽になる感覚を、ぜひ現場で味わってください。
それでは、素晴らしいオブザーバビリティライフを！