2.3 分散監視環境

Zabbix Proxyを活用した大規模・分散環境での効率的な監視実装

分散監視の概要

分散監視環境は、地理的に分散した拠点や大規模なインフラを効率的に監視するためのアーキテクチャです。Zabbix Proxyを中心とした分散構成により、ネットワーク効率化、可用性向上、管理の簡素化を実現します。

分散監視が必要となる場面

地理的分散環境

  • 多拠点企業: 本社・支社・工場の統合監視
  • 国際展開: 複数国家・地域での運用
  • クラウド活用: マルチリージョン・ハイブリッド構成
  • サービスプロバイダー: 顧客別・地域別の分散監視

技術的制約のある環境

  • ネットワーク制約: 低帯域・高レイテンシ回線
  • セキュリティ要件: DMZ配置・ファイアウォール制限
  • 可用性要求: 通信断耐性・独立稼働要件
  • スケール要求: 大量デバイス・高頻度監視

分散監視のメリット

メリット詳細効果
ネットワーク効率化WAN帯域の節約通信コスト削減
レスポンス向上ローカル監視によるレイテンシ削減監視精度向上
可用性向上通信断時の独立稼働事業継続性確保
管理統合中央からの一元管理運用効率化
スケーラビリティプロキシによる負荷分散大規模対応

Zabbix Proxyの詳細機能

プロキシの役割と責務

Zabbix Proxyは、Zabbix Serverとエージェントの中間に位置し、効率的な分散監視を実現します。

主要な機能

  1. データ収集の代行

    • ローカルエージェントからのデータ収集
    • SNMPデバイスの監視
    • 外部チェックの実行
  2. データバッファリング

    • 一時的な通信断への対応
    • バッチ化による効率的な転送
    • データ保護機能
  3. 設定の中継

    • サーバーからの設定情報配信
    • エージェント設定の管理
    • テンプレート配布

プロキシの動作モード

アクティブプロキシ

プロキシがサーバーに能動的に接続する方式

設定例(zabbix_proxy.conf)
conf
# アクティブプロキシ設定
ProxyMode=0  # 0=アクティブ
Hostname=proxy-tokyo
Server=zabbix.company.com
ServerPort=10051

# データベース設定
DBHost=localhost
DBName=zabbix_proxy
DBUser=zabbix_proxy
DBPassword=proxy_password

# バッファリング設定
ProxyLocalBuffer=720   # 30日間(時間)
ProxyOfflineBuffer=24  # 1日間(時間)
ConfigFrequency=3600   # 設定取得間隔(秒)
DataSenderFrequency=60 # データ送信間隔(秒)
適用場面
  • NAT環境: プロキシが内部ネットワークに配置
  • ファイアウォール制約: アウトバウンド通信のみ許可
  • DMZ配置: セキュリティ要件が厳格な環境
  • クラウド環境: 動的IPアドレス環境

パッシブプロキシ

サーバーがプロキシに能動的に接続する方式

設定例(zabbix_proxy.conf)
conf
# パッシブプロキシ設定
ProxyMode=1  # 1=パッシブ
Hostname=proxy-osaka
ListenPort=10051
ListenIP=0.0.0.0

# データベース設定
DBHost=localhost
DBName=zabbix_proxy
DBUser=zabbix_proxy

# パフォーマンス調整
StartPollers=10
StartTrappers=5
CacheSize=64M
HistoryCacheSize=32M
適用場面
  • 企業内ネットワーク: 直接接続可能な環境
  • 固定IP環境: 静的なネットワーク構成
  • 高セキュリティ環境: インバウンド制御が可能
  • 管理集約: サーバー側からの能動管理

プロキシのデータベース設計

サポートデータベース

データベース用途特徴
SQLite軽量・組み込み用途設定不要、単一ファイル
MySQL/MariaDB中規模環境汎用的、管理しやすい
PostgreSQL大規模・高負荷環境高性能、高機能

SQLite設定(軽量環境)

conf
# SQLite設定(最軽量)
DBName=/var/lib/zabbix/zabbix_proxy.db

# 軽量化設定
LogSlowQueries=0
StartPollers=5
StartTrappers=3
CacheSize=32M

MySQL設定(中規模環境)

sql
-- プロキシ用データベース作成
CREATE DATABASE zabbix_proxy CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
CREATE USER 'zabbix_proxy'@'localhost' IDENTIFIED BY 'proxy_password';
GRANT ALL PRIVILEGES ON zabbix_proxy.* TO 'zabbix_proxy'@'localhost';

-- パフォーマンス最適化
SET GLOBAL innodb_buffer_pool_size = 512M;
SET GLOBAL max_connections = 200;

PostgreSQL設定(大規模環境)

sql
-- プロキシ用データベース作成
CREATE USER zabbix_proxy WITH PASSWORD 'proxy_password';
CREATE DATABASE zabbix_proxy OWNER zabbix_proxy;

-- PostgreSQL最適化
ALTER SYSTEM SET shared_buffers = '512MB';
ALTER SYSTEM SET effective_cache_size = '2GB';
ALTER SYSTEM SET max_connections = 200;

大規模環境での設計考慮点

アーキテクチャパターン

1. 階層型分散構成

[本社] Zabbix Server
    ├─ [地域A] Regional Proxy
    │   ├─ [拠点A1] Local Proxy → [機器群]
    │   └─ [拠点A2] Local Proxy → [機器群]
    ├─ [地域B] Regional Proxy
    │   ├─ [拠点B1] Local Proxy → [機器群]
    │   └─ [拠点B2] Local Proxy → [機器群]
    └─ [地域C] Regional Proxy
        ├─ [拠点C1] Local Proxy → [機器群]
        └─ [拠点C2] Local Proxy → [機器群]
階層型のメリット
  • スケーラビリティ: 無制限の拠点展開
  • 管理効率: 地域単位での運用管理
  • 耐障害性: 地域レベルでの独立性
  • ネットワーク最適化: 段階的な集約

2. 機能別分散構成

[中央] Zabbix Server
    ├─ [インフラ] Infrastructure Proxy → [サーバー群]
    ├─ [ネットワーク] Network Proxy → [NW機器群] 
    ├─ [アプリ] Application Proxy → [アプリ群]
    ├─ [セキュリティ] Security Proxy → [セキュリティ機器群]
    └─ [クラウド] Cloud Proxy → [クラウドリソース]
機能別分散のメリット
  • 専門性: 各領域に特化した監視
  • 責任分界: 明確な運用責任分担
  • 独立性: 他システム障害の影響を最小化
  • 最適化: 各分野特有の要件対応

容量設計とサイジング

プロキシ性能要件

軽量構成(~1,000台)
yaml
CPU: 2コア
メモリ: 4GB
ストレージ: 50GB
ネットワーク: 100Mbps

推奨設定:
  StartPollers: 10
  StartTrappers: 5
  CacheSize: 64M
  HistoryCacheSize: 32M
中規模構成(1,000~5,000台)
yaml
CPU: 4コア
メモリ: 8GB
ストレージ: 200GB
ネットワーク: 1Gbps

推奨設定:
  StartPollers: 20
  StartTrappers: 10
  CacheSize: 128M
  HistoryCacheSize: 64M
大規模構成(5,000台~)
yaml
CPU: 8コア以上
メモリ: 16GB以上
ストレージ: 500GB以上
ネットワーク: 1Gbps以上

推奨設定:
  StartPollers: 50
  StartTrappers: 20
  CacheSize: 256M
  HistoryCacheSize: 128M

データ転送量の見積もり

javascript
// 転送量計算例
監視対象: 1,000台
平均アイテム数: 50個/
収集間隔: 60秒
データサイズ: 100バイト/

計算:
1,000台 × 50アイテム × (3600秒/60秒) × 100バイト
= 300MB/時間
= 7.2GB/

圧縮率: 約70%削減
実際の転送量: 約2.2GB/

高可用性とスケーリング

プロキシの冗長化

アクティブ・スタンバイ構成
yaml
構成:
  Primary Proxy: proxy-primary.site-a.com
  Secondary Proxy: proxy-secondary.site-a.com
  
切り替え条件:
  - Primary応答なし(5分間)
  - データベース障害検出
  - 手動切り替え指示

データ同期:
  - リアルタイムDB複製
  - 設定ファイル同期
  - 証明書・キー同期
ロードバランサー構成
haproxy
# HAProxy設定例
backend zabbix_proxies
    balance roundrobin
    option httpchk GET /
    server proxy1 10.1.1.10:10051 check
    server proxy2 10.1.1.11:10051 check
    server proxy3 10.1.1.12:10051 check

スケールアウト戦略

水平分散
yaml
分散方法:
  - ホストグループ別分散
  - IP範囲別分散
  - サービス種別分散
  - 地理的分散

実装例:
  Proxy-Web: Webサーバー専用
  Proxy-DB: データベースサーバー専用
  Proxy-Network: ネットワーク機器専用
動的スケーリング
bash
#!/bin/bash
# プロキシ自動スケーリングスクリプト

CURRENT_LOAD=$(zabbix_get -s proxy-monitor -k system.cpu.util)
THRESHOLD=80

if [ "$CURRENT_LOAD" -gt "$THRESHOLD" ]; then
    # 新しいプロキシインスタンス起動
    docker run -d --name proxy-scale-$(date +%s) \
        -e ZBX_HOSTNAME=proxy-scale-$(date +%s) \
        -e ZBX_SERVER_HOST=zabbix.company.com \
        zabbix/zabbix-proxy-mysql
        
    # ロードバランサー設定更新
    echo "server proxy-scale-$(date +%s) new-proxy-ip:10051 check" >> /etc/haproxy/haproxy.cfg
    systemctl reload haproxy
fi

ネットワーク設計とセキュリティ

通信フローの最適化

通信ポートとプロトコル

yaml
サーバー → プロキシ:
  ポート: 10051/tcp
  プロトコル: Zabbix protocol
  方向: サーバー → プロキシ(パッシブモード)

プロキシ → サーバー:
  ポート: 10051/tcp
  プロトコル: Zabbix protocol  
  方向: プロキシ → サーバー(アクティブモード)

プロキシ → エージェント:
  ポート: 10050/tcp
  プロトコル: Zabbix protocol
  方向: プロキシ → エージェント

プロキシ → SNMP機器:
  ポート: 161/udp
  プロトコル: SNMP
  方向: プロキシ → SNMP機器

ファイアウォール設定

本社(サーバー側)
bash
# iptables設定例
# プロキシからの接続許可
iptables -A INPUT -p tcp --dport 10051 -s 192.168.100.0/24 -j ACCEPT

# Web管理画面
iptables -A INPUT -p tcp --dport 80 -s 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 192.168.0.0/16 -j ACCEPT

# データベースアクセス(ローカルのみ)
iptables -A INPUT -p tcp --dport 3306 -s 127.0.0.1 -j ACCEPT
拠点(プロキシ側)
bash
# エージェントからの接続許可
iptables -A INPUT -p tcp --dport 10051 -s 10.0.0.0/8 -j ACCEPT

# 本社サーバーへの接続許可
iptables -A OUTPUT -p tcp --dport 10051 -d zabbix.company.com -j ACCEPT

# ローカルSNMP監視
iptables -A OUTPUT -p udp --dport 161 -d 10.0.0.0/8 -j ACCEPT

暗号化とセキュリティ

TLS/SSL通信の設定

証明書ベース認証
bash
# CA証明書作成
openssl genrsa -out ca.key 4096
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

# プロキシ証明書作成
openssl genrsa -out proxy.key 4096
openssl req -new -key proxy.key -out proxy.csr
openssl x509 -req -days 365 -in proxy.csr -CA ca.crt -CAkey ca.key -out proxy.crt
プロキシ設定
conf
# TLS設定(zabbix_proxy.conf)
TLSConnect=cert
TLSAccept=cert
TLSCAFile=/etc/zabbix/ca.crt
TLSCertFile=/etc/zabbix/proxy.crt
TLSKeyFile=/etc/zabbix/proxy.key
サーバー設定
conf
# TLS設定(zabbix_server.conf)
TLSCAFile=/etc/zabbix/ca.crt
TLSCertFile=/etc/zabbix/server.crt
TLSKeyFile=/etc/zabbix/server.key

PSK(Pre-Shared Key)認証

PSKキー生成
bash
# PSKキー生成(32バイト)
openssl rand -hex 32 > /etc/zabbix/proxy.psk
echo "proxy001" > /etc/zabbix/proxy.psk.id
設定例
conf
# プロキシ設定
TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=proxy001
TLSPSKFile=/etc/zabbix/proxy.psk

# サーバー側でPSK情報を登録
# Administration → Proxies → [プロキシ名] → Encryption

ネットワーク監視とトラブルシューティング

通信状態の監視

sql
-- プロキシ通信状態確認
SELECT 
    h.host,
    h.status,
    hi.lastaccess,
    hi.lastclock,
    CASE 
        WHEN hi.lastaccess < UNIX_TIMESTAMP(NOW() - INTERVAL 5 MINUTE) 
        THEN 'OFFLINE' 
        ELSE 'ONLINE' 
    END as proxy_status
FROM hosts h
LEFT JOIN host_inventory hi ON h.hostid = hi.hostid  
WHERE h.status IN (5,6);  -- プロキシホスト

パフォーマンス監視

bash
#!/bin/bash
# プロキシパフォーマンス監視スクリプト

PROXY_HOST="proxy-tokyo"
LOG_FILE="/var/log/zabbix/proxy_monitor.log"

# 処理キュー確認
QUEUE_SIZE=$(echo "SELECT COUNT(*) FROM proxy_history;" | mysql -N zabbix_proxy)

# データ転送遅延確認  
LAST_DATA=$(echo "SELECT MAX(clock) FROM proxy_history;" | mysql -N zabbix_proxy)
CURRENT_TIME=$(date +%s)
DELAY=$((CURRENT_TIME - LAST_DATA))

# ログ出力
echo "$(date): Queue=$QUEUE_SIZE, Delay=${DELAY}s" >> $LOG_FILE

# アラート条件
if [ $QUEUE_SIZE -gt 10000 ] || [ $DELAY -gt 300 ]; then
    echo "ALERT: Proxy performance issue detected" | \
    mail -s "Proxy Alert: $PROXY_HOST" [email protected]
fi

実践的な実装例

多拠点企業での実装

要件

  • 本社: 東京(中央サーバー)
  • 拠点: 大阪、名古屋、福岡(各プロキシ)
  • 監視対象: 各拠点100台、計400台
  • ネットワーク: VPN接続、帯域制限あり

実装アーキテクチャ

yaml
本社(東京):
  - Zabbix Server
  - Central Database (MySQL Cluster)
  - Web Interface
  - Management Network

大阪拠点:
  - Zabbix Proxy (Active)
  - Local Database (MySQL)
  - 100台のサーバー・機器

名古屋拠点:
  - Zabbix Proxy (Active)  
  - Local Database (MySQL)
  - 100台のサーバー・機器

福岡拠点:
  - Zabbix Proxy (Active)
  - Local Database (MySQL)
  - 100台のサーバー・機器

設定例

サーバー設定(東京本社)
conf
# zabbix_server.conf
DBHost=db-cluster.tokyo.local
DBName=zabbix
DBUser=zabbix
DBPassword=zabbix_password

# プロキシ用設定
StartPollers=50
StartTrappers=20
CacheSize=512M
HistoryCacheSize=256M

# ログ設定
LogFile=/var/log/zabbix/zabbix_server.log
LogLevel=3
プロキシ設定(大阪拠点)
conf
# zabbix_proxy.conf
ProxyMode=0  # アクティブモード
Hostname=proxy-osaka
Server=zabbix.tokyo.company.com
ServerPort=10051

# データベース
DBHost=localhost
DBName=zabbix_proxy_osaka
DBUser=zabbix_proxy
DBPassword=osaka_proxy_password

# バッファ設定(VPN断対策)
ProxyLocalBuffer=2160  # 90日間
ProxyOfflineBuffer=168 # 7日間

# パフォーマンス調整
StartPollers=20
StartTrappers=10
CacheSize=128M
HistoryCacheSize=64M

クラウド・ハイブリッド環境

AWS環境での実装

yaml
構成:
  On-Premise:
    - Zabbix Server
    - Primary Database
    
  AWS ap-northeast-1:
    - Zabbix Proxy (EC2)
    - RDS MySQL (Proxy DB)
    - VPC with Private Subnets
    
  AWS us-west-2:
    - Zabbix Proxy (EC2)
    - RDS MySQL (Proxy DB)
    - VPC with Private Subnets

接続:
  - Site-to-Site VPN
  - Direct Connect (バックアップ)
  - TLS暗号化通信

Docker環境での実装

yaml
# docker-compose.yml (プロキシ)
version: '3.8'
services:
  zabbix-proxy:
    image: zabbix/zabbix-proxy-mysql:6.4-alpine-latest
    environment:
      - ZBX_HOSTNAME=proxy-docker-cluster
      - ZBX_SERVER_HOST=zabbix.company.com
      - ZBX_SERVER_PORT=10051
      - DB_SERVER_HOST=mysql-proxy
      - MYSQL_USER=zabbix_proxy
      - MYSQL_PASSWORD=proxy_password
      - MYSQL_DATABASE=zabbix_proxy
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./zbx_env/etc/zabbix/zabbix_proxy.d:/etc/zabbix/zabbix_proxy.d:ro
    ports:
      - "10051:10051"
    depends_on:
      - mysql-proxy

  mysql-proxy:
    image: mysql:8.0
    environment:
      - MYSQL_ROOT_PASSWORD=root_password
      - MYSQL_DATABASE=zabbix_proxy
      - MYSQL_USER=zabbix_proxy
      - MYSQL_PASSWORD=proxy_password
    volumes:
      - mysql-data:/var/lib/mysql
    command: mysqld --character-set-server=utf8mb4 --collation-server=utf8mb4_bin

volumes:
  mysql-data:

運用管理とベストプラクティス

日常運用

監視項目

yaml
プロキシ自体の監視:
  - システムリソース(CPU、メモリ、ディスク)
  - データベース状態
  - ネットワーク接続状態
  - プロセス稼働状況

通信品質監視:
  - サーバー・プロキシ間レイテンシ
  - データ転送量・遅延
  - エラー率・再送率
  - 接続断発生頻度

データ品質監視:
  - データ取得成功率
  - アイテム無効率
  - トリガー誤検知率
  - 通知配信成功率

定期メンテナンス

bash
#!/bin/bash
# プロキシ定期メンテナンススクリプト

# データベース最適化
mysql -uzabbix_proxy -p zabbix_proxy -e "OPTIMIZE TABLE history_uint;"
mysql -uzabbix_proxy -p zabbix_proxy -e "OPTIMIZE TABLE trends_uint;"

# ログローテーション
logrotate /etc/logrotate.d/zabbix-proxy

# 古いデータ削除(90日以前)
OLD_DATE=$(date -d "90 days ago" +%s)
mysql -uzabbix_proxy -p zabbix_proxy -e "
DELETE FROM history_uint WHERE clock < $OLD_DATE;
DELETE FROM history_str WHERE clock < $OLD_DATE;
"

# パフォーマンス統計
echo "$(date): Maintenance completed" >> /var/log/zabbix/maintenance.log

トラブルシューティング

一般的な問題と対策

1. プロキシ接続断
bash
# 診断コマンド
zabbix_get -s proxy-host -p 10051 -k agent.ping

# 対策
1. ネットワーク接続確認
2. ファイアウォール設定確認  
3. プロキシプロセス状態確認
4. ログファイル確認
2. データ転送遅延
sql
-- 遅延確認クエリ
SELECT 
    COUNT(*) as pending_items,
    MIN(clock) as oldest_data,
    MAX(clock) as latest_data,
    (UNIX_TIMESTAMP() - MIN(clock)) as delay_seconds
FROM proxy_history;
3. メモリ不足
bash
# メモリ使用状況確認
free -h
ps aux | grep zabbix_proxy | awk '{print $4}' | sort -n

# 対策設定
CacheSize=256M          # 増加
HistoryCacheSize=128M   # 増加
StartPollers=10         # 削減(必要に応じて)

パフォーマンス最適化

システムレベル最適化

bash
# OS最適化
echo 'net.core.rmem_max = 134217728' >> /etc/sysctl.conf
echo 'net.core.wmem_max = 134217728' >> /etc/sysctl.conf
echo 'vm.swappiness = 10' >> /etc/sysctl.conf
sysctl -p

# ファイルシステム最適化
mount -o remount,noatime /var/lib/mysql

データベース最適化

sql
-- MySQL最適化
SET GLOBAL innodb_buffer_pool_size = 1073741824;  -- 1GB
SET GLOBAL innodb_log_file_size = 268435456;      -- 256MB
SET GLOBAL max_connections = 200;
SET GLOBAL query_cache_size = 67108864;           -- 64MB

-- インデックス最適化
ANALYZE TABLE history_uint;
ANALYZE TABLE trends_uint;

まとめ

分散監視環境は、現代企業の複雑なITインフラを効率的に監視するために不可欠です:

分散監視の価値

  1. スケーラビリティ: 無制限の拠点・デバイス対応
  2. 可用性: 通信断耐性と独立稼働
  3. 効率性: ネットワーク最適化と運用自動化
  4. 統合性: 中央集権的な管理と可視化

実装時の重要ポイント

  1. アーキテクチャ設計: 要件に応じた適切な構成選択
  2. セキュリティ: 暗号化通信と認証の確実な実装
  3. パフォーマンス: 適切なサイジングと最適化
  4. 運用設計: 監視・保守・トラブルシューティング体制

この分散監視の基盤を理解することで、第3部以降のより実践的な実装・設定作業に取り組むことができます。


参考リンク

← 前へ: 2.2 データフローとプロセス | 目次に戻る →