Zabbix 8.0 LTSの新機能と構築方法!Docker ComposeでOpenTelemetry・MCP連携を試す
2026年11月5日、オープンソースの統合監視ツール「Zabbix 8.0 LTS」が正式にリリースされました。
今回のアップデートでは、従来のインフラ監視に加えて、OpenTelemetryによるアプリケーション性能監視(APM)とMCPによるAIエージェント連携が強化されています。
これにより、サーバーのCPU使用率やメモリだけでなく、APIの応答時間、処理のトレース情報、障害イベントなどを一元的に分析できるようになりました。
本記事では、公式リリースノートをもとにZabbix 8.0 LTSの新機能を紹介し、Docker Composeを使用した環境構築からOpenTelemetry・MCP連携まで解説します。
※本記事の構成はZabbix 8.0.0の公式仕様に基づくローカル検証用サンプルです。YAML構文は確認済みですが、コンテナの起動・統合動作確認は未実施です。本番環境へそのまま適用しないでください。
Zabbix 8.0 LTSとは?
Zabbixは、サーバー、ネットワーク、データベース、クラウドサービスなどを監視できるオープンソースソフトウェアです。
従来はインフラ監視ツールというイメージが強かったものの、Zabbix 8.0ではアプリケーションの監視にも対応範囲が広がりました。
主な新機能を整理します。
| 新機能 | 概要 |
|---|---|
| OpenTelemetry対応 | トレース・メトリクス・ログの収集と可視化 |
| APM | アプリケーションの性能分析 |
| ClickHouse連携 | テレメトリデータの保存・検索 |
| MCP Server | AIエージェントから監視データを利用 |
| Complex Event Processing | イベント相関やグルーピングによるアラート整理 |
| UI改善 | 新テーマやカスタマイズ可能な一覧表示 |
Zabbix 8.0 LTSのフルサポート期限は2029年11月30日、限定サポート期限は2031年11月30日です。
長期運用を前提としたシステムで採用を検討できるバージョンとなっています。
OpenTelemetry対応で何が変わる?
OpenTelemetryは、アプリケーションからトレース、メトリクス、ログといったテレメトリデータを収集するための標準的な仕組みです。
例えば、Web APIの応答が遅い場合、従来のインフラ監視だけでは以下の原因を特定しにくいことがあります。
- データベースのSQL実行が遅い
- 外部APIの応答に時間がかかっている
- アプリケーション内部の処理が遅延している
OpenTelemetryのトレースを利用すると、リクエストの処理経路と各処理の所要時間を確認できます。
Zabbix 8.0では、APMを有効にしたZabbix ProxyがOTLP/gRPCを受信し、ClickHouseへ保存する構成がサポートされています。
注意したいのが、Zabbix Server自体がOTLPを直接受信するわけではないという点です。
今回構築する環境
今回は以下の構成を使用します。
Python / Spring Boot
|
| OTLP/gRPC
v
OpenTelemetry Collector
|
| OTLP/gRPC
v
Zabbix Proxy 8.0
|
v
ClickHouse
|
v
Zabbix Web UI
AIクライアント
|
| MCP / HTTP
v
Zabbix MCP Server
|
v
Zabbix API
Zabbixの基本設定や監視データの管理にはPostgreSQLを使用します。
一方、OpenTelemetryのテレメトリデータにはClickHouseを使用します。
Docker ComposeでZabbix 8.0 LTSを構築する
事前にDocker EngineまたはDocker Desktop、Docker Compose v2.24以降を準備してください。
今回使用するファイルは以下のとおりです。
zabbix-8-lts-lab/
├── compose.yaml
├── otel-collector.yaml
├── send_trace.py
├── .env
└── .gitignore
Docker Composeの基本設定
まず、PostgreSQLとZabbix Serverを定義します。
services:
postgres:
image: postgres:17-alpine
environment:
POSTGRES_DB: zabbix
POSTGRES_USER: zabbix
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
volumes:
- pg-data:/var/lib/postgresql/data
zabbix-server:
image: zabbix/zabbix-server-pgsql:alpine-8.0.0
environment:
DB_SERVER_HOST: postgres
POSTGRES_DB: zabbix
POSTGRES_USER: zabbix
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
depends_on:
- postgres
続いて、ZabbixのWeb画面を追加します。
zabbix-web:
image: zabbix/zabbix-web-nginx-pgsql:alpine-8.0.0
environment:
DB_SERVER_HOST: postgres
POSTGRES_DB: zabbix
POSTGRES_USER: zabbix
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
ZBX_SERVER_HOST: zabbix-server
PHP_TZ: Asia/Tokyo
ports:
- "127.0.0.1:8080:8080"
depends_on:
- zabbix-server
これは基本構成を説明するための抜粋です。全サービスを含むcompose.yamlは付属プロジェクトに収録しています。
パスワードは.envファイルで設定してください。
POSTGRES_PASSWORD=YOUR_LOCAL_POSTGRES_PASSWORD
CLICKHOUSE_PASSWORD=YOUR_LOCAL_CLICKHOUSE_PASSWORD
実際に利用する際は、それぞれ異なる十分に長いパスワードへ置き換えます。
コンテナを起動する
以下を実行します。
docker compose config --quiet
docker compose up -d
docker compose ps
続いて、ブラウザで以下へアクセスします。
http://localhost:8080
Zabbixの初期ログイン情報は以下です。
ユーザー名:Admin
パスワード:zabbix
ログインできたら、初期パスワードを必ず変更してください。
ClickHouseとOpenTelemetryを連携する
Zabbix 8.0では、ClickHouseをAPMデータの保存先として利用できます。
まずClickHouseコンテナを追加します。
clickhouse:
image: clickhouse/clickhouse-server:26.4
environment:
CLICKHOUSE_DB: telemetry
CLICKHOUSE_USER: zabbix
CLICKHOUSE_PASSWORD: ${CLICKHOUSE_PASSWORD}
CLICKHOUSE_DEFAULT_ACCESS_MANAGEMENT: "1"
volumes:
- ch-data:/var/lib/clickhouse
次に、APMを有効化したZabbix Proxyを用意します。
zabbix-proxy:
image: zabbix/zabbix-proxy-sqlite3:alpine-8.0.0
environment:
ZBX_HOSTNAME: otel-proxy
ZBX_SERVER_HOST: zabbix-server
ZBX_STARTAPMCOLLECTOR: "1"
ZBX_APMLISTENPORT: "4317"
ZBX_TELEMETRYPROVIDER_0: '{"provider":"clickhouse","url":"http://clickhouse:8123","db":"telemetry","vault_path":""}'
ZBX_TELEMETRYPROVIDER_0_USERNAME: zabbix
ZBX_TELEMETRYPROVIDER_0_PASSWORD: ${CLICKHOUSE_PASSWORD}
ZBX_TELEMETRYPROVIDER_0_SCHEMA: '{"create":true}'
depends_on:
- zabbix-server
- clickhouse
ZBX_STARTAPMCOLLECTOR=1は、APM Collectorのプロセスを起動する設定です。
ZBX_TELEMETRYPROVIDER_0_SCHEMAでは、ClickHouseの必要なテレメトリ用テーブルを作成する設定にしています。
ただし、コンテナ側の設定だけではAPM収集は完了しません。
Zabbixの管理画面から「Data collection → Proxies」を開き、otel-proxyという名前のアクティブプロキシを作成します。
そのプロキシの「APM」タブで「Data collection enabled」を有効化してください。
APMデータソースの登録
続いて「Administration → Data source」からグローバルデータソースを有効にします。
| 項目 | 値 |
|---|---|
| Database type | ClickHouse |
| URL | http://clickhouse:8123 |
| Database | telemetry |
| Username | zabbix |
| Password | .envで設定した値 |
設定後、Testで接続できることを確認します。
OpenTelemetry Collectorを設定する
続いて、アプリケーションから送信されたトレース情報をZabbix Proxyへ転送します。
otel-collector.yamlを作成します。
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
processors:
batch: {}
exporters:
otlp/zabbix:
endpoint: zabbix-proxy:4317
tls:
insecure: true
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlp/zabbix]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [otlp/zabbix]
logs:
receivers: [otlp]
processors: [batch]
exporters: [otlp/zabbix]
重要なのが次の設定です。
endpoint: zabbix-proxy:4317
OpenTelemetry CollectorからZabbix Proxyへ、OTLP/gRPCを使用してデータを送信します。
今回のサンプルではDockerネットワーク内の平文通信ですが、本番では通信の暗号化と接続制限を検討してください。
Pythonからトレースを送信してみる
実際にアプリケーションからトレースを送信します。
まず必要なライブラリをインストールします。
python -m pip install opentelemetry-api opentelemetry-sdk opentelemetry-exporter-otlp-proto-grpc
次にsend_trace.pyを作成します。
import time
from opentelemetry import trace
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
provider = TracerProvider(
resource=Resource.create({
"service.name": "zabbix-demo-api"
})
)
exporter = OTLPSpanExporter(
endpoint="localhost:4317",
insecure=True
)
provider.add_span_processor(BatchSpanProcessor(exporter))
trace.set_tracer_provider(provider)
tracer = trace.get_tracer(__name__)
with tracer.start_as_current_span("GET /demo"):
with tracer.start_as_current_span("SELECT demo"):
time.sleep(0.15)
provider.force_flush()
provider.shutdown()
実行します。
python send_trace.py
次に、Zabbix管理画面の「APM → Traces」を開きます。
データが正しく収集・保存されていれば、zabbix-demo-apiのトレースと各処理の所要時間を確認できます。
表示されない場合は、以下でログを確認します。
docker compose logs --tail=100 otel-collector
docker compose logs --tail=100 zabbix-proxy
docker compose logs --tail=100 clickhouse
Pythonの送信処理が終了しただけでは保存成功を保証できないため、管理画面での確認まで行いましょう。
Zabbix MCP Serverとは?
Zabbix 8.0では、公式MCP Serverも利用できます。
MCPは、AIエージェントと外部システムを接続するためのプロトコルです。
Zabbix MCP Serverを使用すると、AIから監視データや障害情報を取得できます。
例えば、次のような問い合わせが考えられます。
「現在発生している重大な障害を一覧表示して」
「Webサーバーで発生しているProblemを確認して」
ただし、AIの回答は監視データをもとにした分析であり、障害原因を自動的に確定するものではありません。
Docker ComposeでMCP Serverを起動する
公式のMCP Server用Dockerイメージを使用します。
zabbix-mcp:
image: zabbix/zabbix-mcp-server:alpine-8.0.0
environment:
ZBX_FRONTEND_URL: http://zabbix-web:8080/api_jsonrpc.php
ZBX_ALLOWEDIP: 0.0.0.0/0
ZBX_TLSACCEPT: unencrypted
ZBX_ALLOWTOOL_REGEXP_0: '^(host|hostgroup|trigger|problem)_get$'
ZBX_DENYTOOL_1: '*'
ports:
- "127.0.0.1:8443:8443"
※接続元IPを無制限にする0.0.0.0/0と平文HTTPは、ホスト側の公開ポートをローカルに限定した検証用の設定です。本番では接続元を制限し、TLSを使用してください。
今回のサンプルでは、host_get、hostgroup_get、trigger_get、problem_getだけを許可しています。
これにより、MCPからの操作を読み取り中心に制限します。
APIトークンを作成する
Zabbix MCP Serverでは、Zabbix APIのトークンを認証に利用します。
Zabbix 8.0の新規インストールでは、ユーザーロールに対するAPIアクセスが初期状態で無効になっています。
そのため、以下の設定が必要です。
- MCP専用のユーザーとロールを作成する
- ロールのAPIアクセスを有効にする
- 必要なAPIメソッドとホストグループの閲覧権限を付与する
- 有効期限付きAPIトークンを発行する
管理者権限のAPIトークンをそのまま利用することは避けましょう。
MCP接続を確認する
以下はbashでの例です。
export ZABBIX_API_TOKEN='YOUR_READ_ONLY_ZABBIX_API_TOKEN'
curl -i http://localhost:8443/mcp \
-H "Authorization: Bearer $ZABBIX_API_TOKEN" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
HTTP 200と許可されているツール一覧が返れば、MCPの接続確認ができます。
AIクライアント側では、Streamable HTTPを選択し、MCPのURLとBearerトークンを設定します。
重要なのは、MCPクライアントによっては書き込み操作に対する承認画面が表示されない点です。
公式ドキュメントでは、form elicitationに非対応のクライアントでは変更操作が追加承認なしで実行されると説明されています。
本番環境ではAPIトークンの権限に加えて、MCPのツール公開範囲も制限してください。
本番導入する際の注意点
Zabbix 8.0を実務で利用する場合、単に監視データを収集できるだけでは不十分です。
特に以下のポイントが重要です。
- ClickHouseの容量とデータ保存期間(TTL)
- OpenTelemetry Collectorのバッチ処理と負荷制御
- APIトークンの最小権限と定期更新
- 通信経路のTLS化
- MCPから取得できるログ・監視情報の機密性
- Zabbix自身の稼働監視とバックアップ
ログやメトリクスの属性には、個人情報や認証情報が含まれることがあります。
AIへ監視データを渡す場合も、参照可能な情報を必要最小限にすることが重要です。
まとめ
Zabbix 8.0 LTSでは、OpenTelemetryのAPM機能と公式MCP Serverの登場により、監視基盤としての活用範囲が広がりました。
今回のポイントは以下の3つです。
- OpenTelemetryのデータはAPMを有効化したZabbix Proxyが収集する
- ClickHouseを利用してトレース・メトリクス・ログを管理できる
- MCP Serverを利用して、AIエージェントから監視情報を参照できる
特にWeb APIを開発しているエンジニアにとって、アプリケーションの処理時間とインフラの稼働状態を一元的に確認できるのは魅力的です。
今後、AIによる障害分析や運用支援を取り入れる場合にも、MCPを通じた監視情報の利用は注目したい仕組みです。
参考資料
- Zabbix 8.0.0公式リリースノート
- Zabbix 8.0新機能・アップグレード情報
- Dockerコンテナでのインストール
- Zabbix 8.0 APM公式ドキュメント
- Zabbix MCP Server公式ドキュメント
- Zabbix Proxy公式Dockerイメージ
※最終更新:2026年11月10日
是非フォローしてください
最新の情報をお伝えします
