Zabbix のディスク使用量を確認してみる – MariaDB (MySQL) 編

◆ Live配信スケジュール ◆
サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。
⇒ 詳細スケジュールはこちらから
⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください
【5/21開催】Azure OpenAI ServiceによるRAG実装ガイドを公開しました
生成AIを活用したユースケースで最も一番熱いと言われているRAGの実装ガイドを公開しました。そのガイドの紹介をおこなうイベントです!!
https://tech-lab.connpass.com/event/315703/

こんにちは。サイオステクノロジー OSS サポート担当 山本 です。

前回は Zabbix のディスク使用量についてお話ししました。しかし、「元々 Zabbix は大規模監視に向いたツールのはず、そこまで気にする必要はあるの?」「そもそも実際どれくらいの速度でディスクを使用していくの?」といった疑問もあると思います。
(実際、Zabbix の公式ページでも処理自体はホスト数 10万/監視項目数 1億にも対応可能とされています。)

今回は Zabbix が要求するディスク容量について、MariaDB 用いて動かした場合の一例を確認してみます。

■前準備

今回はサンプルとなる環境を作成して、Zabbix の DB の使用領域を確認していきます。用意した環境は以下のようなものです。いずれの環境でも Zabbix の Web インターフェースが利用可能な状態までインストール・初期設定を行なっています。

また、アイテムの監視間隔はデフォルトの 30秒で、保存期間は全てデフォルト (ヒストリ:90日、トレンド:365日、イベント:365日、アラート:365日) のままです。

<共通>
mariadb-server-5.5.60-1.el7_5.x86_64
zabbix-agent-4.0.5-1.el7.x86_64
zabbix-web-4.0.5-1.el7.noarch
zabbix-server-mysql-4.0.5-1.el7.x86_64
zabbix-release-4.0-1.el7.noarch
zabbix-web-mysql-4.0.5-1.el7.noarch

<環境1:初期設定>
・Zabbix 初期設定のみ

<環境2:アイテム150個追加>
・Zabbix エージェントのアイテム 15個 (数値系 11個 / その他4個) を登録したテンプレートを作成
・上記テンプレートのみを適用したホスト 10個 (※監視対象は全てローカル)

1_with_item_settings_1
2_with_item_settings_2

<環境3:30秒ごとに通知>
・ホスト 1個作成 (※監視対象はローカル)
・30秒ごとに「障害」を発生させるように設定したアイテム/トリガーを1つずつ作成
・「障害」発生時にメールを送信するアクションを作成

3_with_alerts_settings_1
4_with_alerts_settings_2
5_with_alerts_settings_3

■ディスク使用量の推移

それでは、Zabbix の DB のディスク使用量を確認してみます。
確認には、以下のコマンドを使用しました。

# mysql -e 'SELECT table_schema AS "Database", SUM(data_length + index_length) / 1024 / 1024 AS "Size (MB)" FROM information_schema.TABLES where table_schema = "zabbix" GROUP BY table_schema'

[0日目]

各サーバに設定を行いました。まだディスク使用量には差はありません。

<環境1:初期設定>
1-none_0day
<環境2:アイテム150個追加>
2-items_0day
<環境3:30秒ごとに通知>
3-alerts_0day

[5日目]

設定数の多い環境2のディスク使用量の伸び方が顕著です。
また、初期設定のみの環境1もディスク使用量は他と比べて緩やかではありますが増加しています。

<環境1:初期設定>
1-none_5day
<環境2:アイテム150個追加>
2-items_5day
<環境3:30秒ごとに通知>
3-alerts_5day

[11~20日目]

設定を追加している 環境2, 環境3 は順調にディスク使用量が増えています。
一方、デフォルト設定の環境1 では、この期間でディスク使用量に殆ど変動がありません。

<環境1:初期設定>
1-none_11day
1-none_15day
1-none_20day
<環境2:アイテム150個追加>
2-items_11day
2-items_15day
2-items_20day
<環境3:30秒ごとに通知>
3-alerts_11day
3-alerts_15day
3-alerts_20day

■検証の結果

それでは、検証の結果を並べてみます。

環境1(初期設定)環境2(アイテム150個追加)環境3(30秒ごとに通知)
0日目10.86 (MB)10.86 (MB)10.86 (MB)
5日目55.75 (MB)286.29 (MB)68.52 (MB)
11日目74.02 (MB)591.26 (MB)111.89 (MB)
15日目77.00 (MB)803.58 (MB)125.02 (MB)
20日目76.00 (MB)1054.84 (MB)134.06 (MB)

環境2(アイテム150個追加) と 環境3(30秒ごとに通知) にも初期設定は含まれているはずなので、環境1(初期設定) のディスク使用量を除いてみると、環境2環境3 の追加した設定の分のディスク使用量を概算できるはずです。
更に、今後も同じペースでディスク使用量が増えていくと仮定して、デフォルトの保存期間 (ヒストリ:90日、トレンド:365日、イベント:365日、アラート:365日) から最終的なディスク使用量の予測を加えてみると以下のようになると推測できます。

環境2(アイテム150個追加) – 環境1環境3(30秒ごとに通知) – 環境1
0日目0 (MB)0 (MB)
5日目230.54 (MB)12.77 (MB)
11日目517.26 (MB)37.87 (MB)
15日目726.58 (MB)48.02 (MB)
20日目978.84 (MB)58.06 (MB)
:
90日目 (推定値)4.5 (GB) 程度?225 (MB) 程度?
365日目 (推定値)4.5 (GB) 程度?1 (GB) 程度?

尤も、実際には環境や各種設定によって値は大幅に変わるものと考えられるため、この検証の数値はあくまで参考程度に考えてください。例えば、前回の記事で紹介した、Zabbix のディスク使用量についての公式ドキュメントの参考値から今回の環境のディスク使用量を概算してみると、環境2 は約 7.5 (GB)、環境3 は約 850 (MB) くらいと、今回の検証とはかなり違う値になります。

■監視設定をしていなかった環境のディスク使用量増加について

ところで、監視設定を行なっていなかった環境1でも徐々にディスク使用量が増えていました。これは Zabbix の初期設定で Zabbix サーバー自身の監視設定が入っていて、そのデータを保存しているからなのですが…実はこのデフォルトの監視設定、100 個近くのアイテムなどが設定されています。

D_default_host

しかし、追加でアイテムを 150個設定した 環境2 では毎日 50 MB ほどディスク使用量が増加し続けていたのに対し、デフォルト設定のままである 環境1 のディスク使用量の増加量は毎日 10 MB 程度と格段に少ないように見えますし、80MB 弱からはディスク使用量の増加が止まっているように見えます。それは何故かと言うと…

D_default_host_items

ご覧の通り、初期設定で入っている Zabbix サーバー自身の監視設定に含まれているアイテムは、いずれもヒストリの保存期間が 1w (1週間) と短く、監視間隔も 1m (1分) ~ 1h (1時間) と長めであるから、と考えられます。
(Web インターフェースから手動で作成するアイテムでは、デフォルトの初期値はヒストリ保存期間 90日 / 監視間隔 30秒)

ヒストリの保存期間が過ぎてからはヒストリのデータを取得するのと同じ間隔で古いヒストリが削除されるため、監視を始めてから1週間後以降はこれらの初期設定のアイテムによるディスク使用量の増加は止まるものと考えられます。また、ディスク使用量の増加速度が遅かったのは、単純に監視間隔が長く、取得するヒストリデータ総数が少なかったためと考えられます。

この例からわかるように、監視間隔とヒストリの保存期間の設定は Zabbix のディスク使用量に大きく影響を与えます。

■Zabbix のデータ削除後のディスク使用量

前回に少し触れていた、データを削除した後の mariaDB のディスク使用量の変化も確認してみます。
「たとえデータベース上のデータを削除したとしても、RDB はディスクの使用領域を解放しない」というものですね。

先の手順で作成した アイテムを150個追加している 環境2 をサンプルに、確認してみます。
予めディスク使用量等のデータを取得しておき、ホストやヒストリが削除された後のものと比べてみます。(削除はインターフェースからのホストの削除と housekeeper の手動実行で行いました。)

・データ削除前
X_before_delete_hosts

・データ削除後
X_after_delete_hosts

ご覧のとおり、削除前後でデータを確認してみると、データベース上で zabbix のデータベースが使用しているディスク領域は 1459 MB → 287 MB と大幅に減少していることが確認できるにも関わらず、ディスク使用量や mariadb のデータベースの実態ファイルである /var/lib/mysql/ibdata1 のファイルサイズは一切減少していないのが確認できます。

ということで、実際にデータ削除後も DB のディスク使用量が減らないことが確認できました。
この状態からどうにかしてディスク使用量を減らしたい場合には……まずは以下のコマンドを実行してください。

# mysql -u -p -e 'SELECT @@innodb_file_per_table'

@@innodb_file_per_table = 1 だった場合

以下のクエリを実行することで、指定したテーブルから余分なディスク領域を解放することができる、とのことです。
(そもそも、こちらの場合はデータベースの実態ファイルは /var/lib/mysql/ibdata1 ではなく、テーブルごとに作成されています。)

OPTIMIZE TABLE <データを削除したテーブル名>

@@innodb_file_per_table = 0 だった場合

今回見ている環境はこちらです。こちらの場合、OPTIMIZE TABLE クエリは効果がありません。

ではこちらの場合どうするかと言うと…DB を一から作成し直すことで対処することができます。
なお、この手順では途中で DB の内容を完全に削除するため、失敗すると監視設定や監視情報は全て消えてしまう可能性があります。また、DB のダンプファイルを使用するため、ダンプファイルを出力できるだけのリソースの余裕が必要となります。万が一この手順を実行しなくてはならなくなった場合には、実施の前に本当に実施するのかを十分確認の上、細心の注意を払って手順を実行してください。

 1. DB のバックアップを作成します。

# mysqldump -A -u&ltDB のユーザー&gt -p&ltDB のパスワード&gt &gt dumpfile

 2. mariadb (MySQL) を停止します。

# systemctl stop mariadb

 3. mariadb (MySQL) の実態ファイル (ibdataX) とログファイル (ib_logfileX) を削除します (この時点で DB の内容が削除されます。)

# rm -f /var/lib/mysql/ib*

 4. mariadb (MySQL) を起動します。

# systemctl start mariadb

 5. 1 で取得した DB のバックアップを適用します。

# mysql -u&ltDB のユーザー&gt -p&ltDB のパスワード&gt &lt dumpfile

以上の手順を実行することで、DB から余分なディスク領域を解放することができます。

実際に試してみたところ、DB の実態ファイル /var/lib/mysql/ibdata1 のサイズが 1.6 GB → 90MB と大幅に減少し、ディスク使用量も削減できていることが確認できました。

X_reduce_diskspace_1

■さいごに

今回は Zabbix が取得するデータのディスク使用量を、実例を使って確認してみました。

あくまで参考程度の情報ですが、どうだったでしょうか。前回は散々「気を付けて!」と言っていましたが、環境次第では気を付けるまでもないかもしれません。ですが、どの程度のディスク容量が必要になるか試算したり、使用量の経過を観察しておくのはトラブルの未然回避につながる可能性もありますので、一度確認しておいても損はないと思います。

同時に、設定次第でディスク使用量を大きく節約できることも確認してもらえたかと思います。Zabbix のデータベースを配置した環境でディスクの容量に懸念がある場合、一度データの保存期間を見直してみてはいかがでしょうか。勿論、だからと言って監視としての意味を為さないような設定をしてしまっては本末転倒なので、要件を確認しながら適切な監視設定を目指しましょう。

ZabbixはZabbix LLCの登録商標です。

アバター画像
About 山本 54 Articles
元サーバサイドエンジニアのサポートエンジニア。「物事は理解できれば活路が見出せる可能性がある」という信条のもと、今日も石橋を叩く。
ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

1人がこの投稿は役に立ったと言っています。


ご覧いただきありがとうございます。
ブログの最新情報はSNSでも発信しております。
ぜひTwitterのフォロー&Facebookページにいいねをお願い致します!



>> 雑誌等の執筆依頼を受付しております。
   ご希望の方はお気軽にお問い合わせください!

Be the first to comment

Leave a Reply

Your email address will not be published.


*


質問はこちら 閉じる