SIOS Tech. Lab | エンジニアのタメになるOSS・クラウド・認証の技術トピックス 
こんにちは。サイオステクノロジー OSS サポート担当 山本 です。
唐突ですが、Zabbix を使っていて直面する問題は概ね 3種類に分けられるのではないか、と考えています。「思った通りに設定できない」「Zabbix を使っていたら disk full になってしまった！！」「その他諸々」。この3つです。
今回は Zabbix が要求するディスク容量について、考えてみます。
■Zabbix の housekeeper と RDB
「Zabbix がどれだけディスク容量を要求するのか」について確認する前に、Zabbix の housekeeper 機能についてと、RDB のある性質を確認しておかなければなりません。
housekeeper は Zabbix のプロセスの一つで、デフォルトでは 1時間に 1度 DB 上の保存期間の過ぎたデータを 5000レコードまで削除してくれます。この housekeeper によって Zabbix で使用している DB が無限に膨張し続けることは防がれますが、これはあくまで「保存期間」をベースに動作するものなので、「適正な保存期間内でディスクを食い尽くしてしまう」事態に対しては無力です。
(※データの保存期間は Zabbix の設定です。後のセクションで確認します。)
housekeeper の設定は、zabbix_server.conf (/etc/zabbix/zabbix_server.conf) で行えます。以下の説明のとおり、「何時間ごとに実行するか」「一回でどれだけ削除できるか」の設定を行うことができます。設定を変える場合、zabbix_server の再起動も忘れずに。
zabbix_server.conf
377 ### Option: HousekeepingFrequency
378 # How often Zabbix will perform housekeeping procedure (in hours).
379 # Housekeeping is removing outdated information from the database.
380 # To prevent Housekeeper from being overloaded, no more than 4 times HousekeepingFrequency
381 # hours of outdated information are deleted in one housekeeping cycle, for each item.
382 # To lower load on server startup housekeeping is postponed for 30 minutes after server start.
383 # With HousekeepingFrequency=0 the housekeeper can be only executed using the runtime control option.
384 # In this case the period of outdated information deleted in one housekeeping cycle is 4 times the
385 # period since the last housekeeping cycle, but not less than 4 hours and not greater than 4 days.
386 #
387 # Mandatory: no
388 # Range: 0-24
389 # Default:
390 # HousekeepingFrequency=1
391
392 ### Option: MaxHousekeeperDelete
393 # The table "housekeeper" contains "tasks" for housekeeping procedure in the format:
394 # [housekeeperid], [tablename], [field], [value].
395 # No more than 'MaxHousekeeperDelete' rows (corresponding to [tablename], [field], [value])
396 # will be deleted per one task in one housekeeping cycle.
397 # SQLite3 does not use this parameter, deletes all corresponding rows without a limit.
398 # If set to 0 then no limit is used at all. In this case you must know what you are doing!
399 #
400 # Mandatory: no
401 # Range: 0-1000000
402 # Default:
403 # MaxHousekeeperDelete=5000
続いて RDB についてですが、以下のページたちをご確認ください。
・Defragmenting InnoDB Tablespaces – MariaDB Knowledge Base
・ディスク容量の復旧 – PostgreSQL 9.6.5文書
(※MySQL は公式ドキュメントから該当する記述が見つけられませんでしたが、基本的には同じようです。)
これらのページに書いてあるとおり、Zabbix でも使われている著名な RDB は「レコード (DB 上のデータ) を削除しても、RDB は基本的にディスク領域を解放しない」らしいのです！(※後にデータを保存する時のための予約スペースとして保持され続けます。)
つまり、「Zabbix のデータベースのせいでディスク容量がいっぱいになっちゃった！」という時点で、disk full 対策は既に手遅れとなっている可能性が非常に高いです。バックアップを取って一度データベースを丸ごと削除してから再構成するなどのリカバリ手段はありますが、基本的に手間がかかるうえに disk full が近い状態だと負荷の問題で実行できないこともあり、データを損失する危険なども伴う作業となりますので、予めこうならないようにしておくことがすごく大事、ということですね。
■Zabbix が使うデータベースの容量
さて、本題である Zabbix が使うデータベースの領域についてです。
と言っても、厳密に求めるのは困難なので、今回は公式ドキュメントの記述を参考に、概算値で考えていきます。
データベース構造に詳しい方は、例えばこのようなページを使用することでより詳細に計算ができるかもしれません。
基本的に問題となりがちのは「ヒストリ (アイテムで取得したデータ)」「トレンド (アイテムで取得したデータのサマリ)」「イベント (トリガーの履歴)」「アラート (アクションの履歴)」の4つです。
・アイテム
まずはアイテムについてです。まずはこちらをご覧ください。
お馴染みのアイテム設定画面ですね。画像は「アイテムの作成」ボタンから新規アイテムの設定を行う画面になります。ここで着目してほしいのは、以下の項目とそのデフォルト値です。
監視間隔：30s
ヒストリの保存期間：90d
トレンドの保存期間：365d (※データ型が「数値」系の場合のみ設定可)
これらの値から、デフォルトではアイテム1つでどれだけの数のデータが保持されるかを計算してみましょう。
まずはアイテムで取得したデータの履歴である「ヒストリ」から。
90 (日) * 24 (時間) * 60 (分) * 60 (秒) / 30 (秒) = 259200 (個)
続いて、「数値」のデータを1時間ごとの平均値/最大値/最小値などのサマリとして纏めている「トレンド」の数です。
365 (日) * 24 (時間) = 8760 (個)
そして、公式ドキュメントによれば、数値系のアイテムのヒストリは 1個約 90 byte (40～数百byte程度)、ログ・文字列等なら内容によって大きく変動しますが 1個約 500 byte 程度で、トレンドは 1個約 90 byte とされています。つまり…
数値系アイテム：(259200 * 90) + (8760 * 90) = 24116400 (byte) ≒ 23 (MB) 文字系アイテム：259200 * 500 = 129600000 (byte) ≒ 124 (MB)
これだけの容量が、デフォルト設定では1アイテム毎に必要になるわけです。例えば、4つのホストで数値系のアイテムを10個ずつ設定すると、それだけで 1GB 必要になる計算ですね。
これらは「30秒に1つの値を取得する」場合の例です。例えば Zabbixエージェント(アクティブ) のログ系のアイテムは 30秒で 1つのデータを取得するわけではないので、これを制限なしで取得していると…環境にもよるとは思いますが、物凄い勢いでディスクを消費する未来が用意に想像できます。
そんなわけで、アイテムの監視間隔や保存期間を適切に設定したり、適切な取得内容を設定するようにすることは非常に重要なのです。幸い、これらの設定は「アイテムの設定画面」という見えやすい場所にありますので、設定の際には忘れずにチェックするようにしましょう。
・トリガー&アクション
続きまして、障害の履歴である「イベント」と、アクションの履歴である「アラート」についてです。
Zabbix では「トリガー」の条件を満たすデータを受け取った時、「障害」として記録する機能があります。その履歴は「監視データ」の「障害」画面から確認することができます。
この画面で「障害の履歴」を確認できるのは、当然データベース上に記録が残っているからですが、勿論これも容量を食います。公式ドキュメントによれば、障害発生時には約 250byte、障害解決時には約 80byte の合わせて約 330byte が障害の発生毎に必要になるとされています。
また、「トリガー」に対して「アクション」を設定していた場合「障害」発生時に関連するアクションが実行されますが、これにも履歴があります。ドキュメント上には記載がありませんが、メールの内容や実行されたコマンドの内容まで記録されていますので、勿論内容次第ではありますがこれも 500byte 程度は必要になると考えたほうがよいでしょう。
つまり、「障害」が一回発生すると (330 + <動作したアクション数> * 500) byte が必要になると考えられるわけです。これらの履歴はデフォルトで 1年間保持されますので、これに 1年間で発生する障害数を掛けただけの容量が、トリガーとアクションの履歴のために必要になります。
例えば、毎日通知メールを伴う障害が 1回ずつ発生すれば、((330 + 500) * 365) = 302950 (byte) ≒ 296 (KB) 程度必要となります。
「障害」の発生頻度は設定と対象の環境に大きく依存するため、これでどれだけの容量が必要になるかは環境毎に判断する必要がありますが、日常的に「障害」が起こるような設定や不必要な通知設定はディスク容量を大きく要する、ということは認識しておいてください。
なお、「イベント」と「アラート」の保存期間は「管理」＞「一般設定」＞「データの保存期間」から変更することができます。トリガー毎やアクション毎に個別で設定することはできませんので、ご注意ください。
なお、このページの「削除処理を有効」のチェックをうっかり解除してしまうと、その項目のデータは housekeeper による自動削除が無効となります。ディスク使用量は確実に右肩上がりになってしまうことが容易に想像できますので、理由がない限りチェックを外さないようにしましょう。
■最後に
今回は、Zabbix で必要になるディスク容量について確認してみました。
ちょっとおどかすような内容でしたが、いざ困ってからでは遅い内容なのです。逆にこれらを把握できていれば、適切に設定することでディスク使用量は大幅に削減できる可能性があります。
また、最初に紹介したとおり Zabbix は housekeeper で古いデータを自動的に削除してくれるので、項目ごとのディスク使用量は基本的に一定以上になることはありません。なので、適切な設定を保っている限り、ディスク使用量は気にしなくても大丈夫でしょう。
ディスク使用量に怯えたり、逆に disk full が実際に発生してしまって監視を正しく行えなくなってしまっては本末転倒、普段から適正な設定を心がけましょう。
Be the first to comment