[작성자:] black K

— 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 に保存する。ここでは…