[카테고리:] 日本語

概要 Zabbix の標準通知機能だけでは、リアルタイムな監視対応が難しい。Slack の Webhook を利用すれば、障害発生や復旧通知を即座に受け取ることができる。 本記事は Zabbix 7.4 + Slack Webhook 環境での通知連携を完全に構築するための実務ガイドである。以下の手順どおりに設定すれば、運用環境でもそのまま使用可能だ。 1. 事前チェック 1.1 アウトバウンド通信の許可 Zabbix サーバーから hooks.slack.com:443 への通信が許可されている必要がある。ファイアウォールやプロキシ環境では、このドメインとポートを例外として許可する。 1.2 Slack チャンネルと Webhook の作成 Slack で監視専用チャンネルを新規作成する。チャンネル設定 → 「Add App」→「Incoming Webhooks」を選択 → Webhook URL を発行。 1.3 Webhook の有効性テスト Zabbix サーバーで以下のコマンドを実行し、Webhook が正常に動作するか確認する。 以下のコマンドの webhook url 部分を、Slack で発行された Webhook アドレスに置き換えて実行する。 Slack チャンネルにメッセージが届けば、Webhook は正常に動作している。 2. Zabbix URL…

— Housekeeper無効化とキャッシュ・プロセスチューニングによる最終パフォーマンス完成 概要 このシリーズの最終編では、パーティション構造を適用した後に行うZabbixサーバー内部キャッシュとプロセスのチューニングにより、DBとサーバープロセス間のI/Oバランスを最適化する手順を解説する。 特に、ZabbixのHousekeeper機能を完全に無効化し、CacheSize、HistoryCacheSize、TrendCacheSize、StartDBSyncers などの主要パラメータを調整して、大規模環境でも安定した動作を維持できる構成を目指す。 1) Housekeeper 無効化 Housekeeperは古いデータを定期的に削除するプロセスである。しかし、すでにパーティションベースの自動削除スクリプトを運用している場合、この機能は重複し、不要な負荷を発生させる。 Zabbix 7.4では、Web UIから直接無効化する必要がある。 パス：Administration → Housekeeping 項目 設定値 説明 Events and alerts ☐（オフ） イベントログ自動削除を停止 Services ☐（オフ） SLA関連サービス履歴を保持しない User sessions ☑（オン） ユーザーセッションのみ保持 History ☐（オフ） DBパーティションスクリプトが処理 Trends ☐（オフ） DBパーティションスクリプトが処理 ⚙️ Housekeeperが残っていると、大量削除時にMySQL I/Oが一時停止することがある。パーティション構成を導入している環境では、必ず無効化しておくこと。 2) Zabbixサーバーのキャッシュおよびプロセスチューニング 設定ファイル：/etc/zabbix/zabbix_server.conf 以下の項目を見つけてコメントアウトを解除し、環境に合わせて値を調整する。 項目 説明 推奨値（RAM 128Gの場合） CacheSize 設定キャッシュ（ホスト・テンプレート構造） 256M〜512M HistoryCacheSize リアルタイムメトリックキャッシュ 512M〜1G TrendCacheSize…

— 自動パーティションスクリプトとcron管理による完全自動化 概要 本記事では、第3編で作成したパーティション構造を自動的に維持・管理する手順を解説する。Zabbixはデータ収集量が多いため、毎日・毎月手動でパーティションを追加したり古いデータを削除するのは非効率である。 ここでは次の2つのスクリプトを用いて完全自動化を実現する。 1) 前提条件 2) History 自動化スクリプト ファイルパス：/usr/local/bin/zbx-part-history.sh 保存後、実行権限を付与： 3) Trends 自動化スクリプト ファイルパス：/usr/local/bin/zbx-part-trends.sh 保存後、実行権限を付与： 4) cron 登録 cronファイルを作成： 5) 動作結果サマリー 区分 実行周期 実行権限 MySQLアカウント 主な動作 zbx-part-history.sh 毎日 01:05 (UTC) root (cron) zabbix 翌日のパーティション追加＋90日前削除 zbx-part-trends.sh 毎月1日 01:10 (UTC) root (cron) zabbix 翌月のパーティション追加＋12か月前削除 ログファイルの場所： 6) チェックポイント 7) 次回予告 第5編では、Zabbix Housekeeperを無効化し、CacheSize、HistoryCacheSize、TrendCacheSize、StartDBSyncers などのパラメータを調整してZabbixサーバーのキャッシュとMySQL I/Oバランスを最適化する最終チューニングを解説する。

— file-per-tableへの切り替えとhistory・trendsパーティション構造の構成 概要 本記事では、前編で分離したTablespace構成を基に、Zabbixの主要データ（history, trends）を日単位／月単位パーティションテーブルに変換する手順を扱う。 MySQL 8.0以降では、General Tablespace上にパーティションを構成することはできないため、まず file-per-table 構造へ切り替えた後、パーティションを作成する必要がある。 1) 前提条件 ⚠️ 注意:稼働中の環境ではパーティション適用時にデータI/Oが急増するため、必ずテスト環境で検証してから本番適用を行うこと。 2) General Tablespaceからfile-per-tableへ戻す MySQL 8.0以降では、General Tablespaceに対してパーティションテーブルを作成できない。そのため、各テーブルを必ず innodb_file_per_table 構造へ戻す必要がある。 3) パーティション作成前のポイント 🔹 history と trends の構造的な違い テーブル データ量 用途 一般的なパーティション周期 zabbix.history 秒単位で数百万件以上 リアルタイム短期保存 日単位（1〜3日周期） zabbix.trends 平均／最大／最小などの集計データ 中期〜長期保存 月単位（30日周期） 4) Epoch Time計算の参考 パーティションの境界値はUTC基準のEpoch Timeを使用する。これはタイムゾーンの混乱を防ぎ、cronスクリプトによる自動化を簡略化するためである。 Epoch Timeとは？ Epoch Time（UNIXタイムスタンプ）とは、1970年1月1日00時00分00秒（UTC）からの経過秒数を整数で表した値である。この値は世界中で共通の絶対時間基準であり、サーバーのローカルタイム（例：KST、JST、PSTなど）が異なっても時間比較や自動化スクリプトで混乱しない。 ✅ 初期パーティション作成時に必ず合わせるべき基準（この基準を外すと、後続の Cron スクリプトが生成するパーティション境界値と衝突し →…

— ディスク分離とTablespace構成によるI/O分散 概要 本ドキュメントは、Zabbix DBが次第に遅くなる主な原因の一つであるI/O集中問題を軽減するための実務ガイドである。MySQL 8.x環境でZabbixのhistory・trendsデータを別ディスクに分離し、General Tablespaceを構成してデータ格納パスを明確に分ける手順を扱う。 第1編でZabbix 7.4＋MySQLのインストールとスキーマロードを完了している場合、ここからはディスク構造を分け、テーブルを物理的に分離する段階となる。 1) 前提条件 この作業はMySQLが起動中でも実行可能だが、データディレクトリ追加 → AppArmorポリシー修正 → MySQL再起動 の順に必ず進めること。 2) ディレクトリ作成と権限設定 ディレクトリ作成 権限設定 チェックポイント 3) AppArmorポリシーの修正 MySQLはAppArmorによってアクセス可能なパスが制限されている。新しく作成した /data パスを許可しないと、Tablespace作成時に “access denied” エラーが発生する。 以下の2行を追記する： 保存後、AppArmorを再起動する： チェックポイント 4) MySQL設定にディレクトリを登録 MySQL 8.0.21以降では、Tablespaceを作成できるディレクトリを事前に指定しておく必要がある。 ファイル末尾に以下を追加： 保存してMySQLを再起動： チェックポイント → 値が /data と表示されること。 5) General Tablespaceの作成 次に、各ディスクにTablespaceを作成する。 結果確認 2つのファイルが実際に作成されていることを確認する。もしファイルが見えない場合は、AppArmor設定またはinnodb_directories設定が漏れている可能性がある。 6) 既存テーブルをTablespaceへ移動 Zabbixはインストール時、すべてのデータを /var/lib/mysql/zabbix に保存する。ここでは…

— history・trends 分割ベースのチューニング このドキュメントは、Zabbix 7.4環境でMySQLパーティション構造を適用し、Zabbixパッケージのインストールおよびスキーマロードまでの手順をまとめた実務向けガイドである。 1) 前提および範囲 運用環境でセキュリティ認証（コンプライアンス）を受ける必要がある場合、サポート期間が短いリリースは避けること。EOLに敏感な組織では7.0 LTSで固定するのが安全。 2) Zabbixリポジトリの追加 リポジトリ追加 チェックポイント 3) Zabbixサーバー／フロントエンド／エージェントのインストール サーバー／フロントエンド／エージェントのインストール Zabbix Agent2プラグイン（必要なものだけ選択してインストール） チェックポイント 4) MySQLのインストール チェックポイント 5) DB初期化（DB／ユーザー／権限／関数設定） DB作成とユーザー設定 関数信頼設定（一時的） 説明log_bin_trust_function_creators=1 を一時的に有効化する。理由：Zabbixスキーマには get_host_agent() などの STORED FUNCTION が含まれている。バイナリログが有効な環境では、SUPER権限を持たないユーザーによるFUNCTION作成はブロックされるため、スキーマインポート時に必要となる。 6) Zabbixスキーマのインポート スキーマインポート チェックポイント 7) 関数信頼設定の戻し 説明（セキュリティ）FUNCTION作成の信頼オプションは一時的にのみ使用する。スキーマ作成後はすぐに元に戻すこと。 8) ZabbixサーバーのDB接続設定 以下の項目にDB情報を設定 9) サービス起動 チェックポイント 補足タイムゾーンは、Web(UI)表示用（例: KSTなど）とDBパーティション境界（UTC epoch）で分離されている。パーティション計算は常にUTC基準で行う。UIではローカルタイムゾーンとして表示されるだけである。（詳細なパーティション／自動化は第3～4編で解説） 10) 次回予告 トラブルシューティングチェックポイント

⚠️ バージョン注意（重要）Zabbixはバージョン（7.4 / 7.2 / 7.0 LTSなど）によって Helm Repo URL およびチャートブランチが異なる。以下の例は 7.4 を前提としており、運用中の Zabbix サーバまたはテンプレートのバージョンに合わせて <ZBX_VER> の値を変更すること。 Repo パターン: 0) 前提条件 1) Helm Repo 登録（バージョン選択） 使用する Zabbix バージョンを指定 Namespace 作成 バージョン別 Helm Repo 追加・更新 2) values.yaml の作成と編集（1ファイルのみ） チャートのデフォルト値をローカルに出力し、環境に合わせて編集する。 ※以下の設定例はすべて Zabbix 7.4 基準。 ① kube-state-metrics を特定ノードに配置 kubeStateMetrics ブロックがある場合、kube-state-metrics に修正して以下を設定： Taint ノードに配置する場合は tolerations を追記。 ② Zabbix Proxy…

Zabbix vs Prometheus は、どちらも非常に優れたモニタリングツールである。一般的に、Kubernetes や MSA（マイクロサービスアーキテクチャ）環境では、以下のような理由から Prometheus が好まれる傾向にある。 項目 Prometheus Zabbix 収集モデル HTTP pull（Pushgateway 補助）＋サービスディスカバリ Agent / Agent2、SNMP / Trap、IPMI、JMX、HTTP、VMware など データ／クエリ 時系列データ＋PromQL による集計・トレンド分析 アイテム／トリガー ベースの閾値管理、非周期データの扱いも容易 通知 Alertmanager（グルーピング／抑制／ルーティング） 組み込みの通知・エスカレーション・リモートコマンド 可視化 主に Grafana など外部ツールを利用 組み込みダッシュボード／グラフ／マップ／レポート／Grafana 連携 拡張／保管 長期保存・スケールアウトには Thanos / Cortex / Mimir など追加スタック 単一サーバー＋DB 構成、Proxy による分散収集／隔離、Zabbix 7.0 は Proxy HA 対応 K8s 対応 標準メトリクス（ノード／Pod／アプリケーション）＋Exporter エコシステム…