本記事は備忘のための記事です。なので細かい検証とかまで深くできているわけではないので参考までにとどめてください。
Zabbix3.0系での話です。(おそらく4.0とかでも似たような挙動だとは思います。)
ネット上の記事だと、「ValueCacheは危険」的なものをちらほらと見かけるので、改めてValueCacheの挙動について整理しておきます。
ValueCacheは大量の監視データの処理の際に、トリガー評価を非常に高速に行い、DBへの負担を激減させるために有効な仕組みなので、ぜひ仕様を理解して効果的に活用しましょう。
ValueCacheとは
ValueCacheとは、Zabbixのトリガー条件を評価する際に活用されるキャッシュです。
Zabbixは監視結果を受信すると、一旦、HistoryCacheと呼ばれるメモリ領域に格納します。
そのHistoryCacheのデータをDBに同期する際、並行してトリガー評価が行われる仕組みとなります。
この時、トリガーの評価のためだけに都度DBからデータをSELECTすると非常にDBとのやり取りが増えることから、受信データをDBに書き込むと同時にValueCacheという共有メモリ領域にデータを書き出します。
こうすることで、トリガー評価の際、まずValueCache上(共有メモリ上)にあるデータを取得して評価することができ、DBにアクセスすることなく評価を完結させることができます。
ValueCacheはZabbixの2.2のバージョン以降で利用できるものです。
なお、トリガー評価はZabbix Serverで統一して行うので、Zabbix ProxyにはこのValueCacheの仕組みはありません。
ValueCacheを使うことによる効果
ValueCacheを有効にするとトリガーの評価にかかる処理が劇的にスピードアップします。
トリガーの評価処理は、Zabbix Serverの各種プロセスの内、DB syncerプロセスが担当します。
DB syncerプロセスはHistoryCache内のデータをDBに書込処理を行うのと並行して、ValueCacheに値を書き出し、トリガーの条件式を評価、イベント(障害、正常)の発行、アクション情報を確認してエスカレーション情報を登録まで行います。
ValueCacheをうまく使えていないと、DB syncerのプロセスの各処理に時間がかかり、大量のヒストリデータを扱う際に処理が滞ることとなります。
ValueCache有効時と無効時のパフォーマンスの違い
とあるログ監視のアイテムに突如数万件のデータがバースト的に監視されてしまった場合、ValueCache有効時と無効時でどれぐらい処理量に差が出るかの参考値です。
マシンの性能や監視結果のログデータサイズ、DBのチューニング度合い等により様々異なりますが、簡易な環境であまりチューニングもしていない状況だと以下のレベルで性能差が出てきます。
| ValueCache | 1分間に処理できるヒストリデータ件数目安 |
|---|---|
| 有効時 | 30,000件～40,000件程度 |
| 無効時 | 2,000件～3,000件程度 |
ValueCacheの内部構造
ValueCacheの全体サイズ
ValueCacheはzabbix_server.confのValueCacheSizeで全体量を定義できます。
ここで設定したサイズの共有メモリがZabbix Serverの起動時に確保されることとなります。
- 0: ValueCacheの内部機能を利用しない
- 最小値: 128KB
- 最大値: 64GB
ValueCacheへのデータ登録
ValueCacheにデータが登録されるのは主に以下の3つのタイミングです。
- History Cacheに格納されているデータをDBに同期する時に格納
- トリガーの評価時に評価に必要なデータがValueCache上になかった場合、DBから取得して格納
- アクション実行時のマクロ展開で必要なデータがValueCache上になかった場合、DBから取得して格納
1. History Cacheに格納されているデータをDBに同期する時に格納
DB syncerがHistory Cache上のデータをDBに書き込む際、各監視結果の内、トリガー評価で利用する対象のものについて、データをValueCache上に書き込みます。1件のデータを処理する毎に都度ValueCacheに書き込みます。
2. トリガーの評価時に評価に必要なデータがValueCache上になかった場合、DBから取得して格納
トリガーの条件式に、過去のデータを活用した評価を行うような書き方になっている場合、評価を行う際に必要となる過去データがValueCache上に存在しなければ、DBから取得しValueCacheに登録します。
{ホスト名:アイテムキー.avg(#5)}>100
このような条件式の場合、過去5回分の監視結果の平均値を求めることになるので過去5回分のデータがValueCache上に登録されている必要があります。
3. アクション実行時のマクロ展開で必要なデータがValueCache上になかった場合、DBから取得して格納
基本的には上記の2.の挙動と同じです。マクロの中で過去のデータも含めて取得して展開するようなものがあると、こちらに必要な分のデータもValueCache上に保存します。
ValueCacheからのデータ削除
ValueCache上のデータは、上記2.や3.の処理時に、ValueCacheからデータを取得したタイミングで不要な古いデータが削除されるようになっています。各アイテム毎に、トリガー評価やマクロ展開に必要となるデータの範囲がどれぐらいであるかの情報(「このアイテムは過去1時間分の情報が必要」等)を保持しています。
この範囲に従って、それ以上に古いデータを取得処理の際に削除します。この処理により、ValueCacheにデータが溜まり続けるのを防いでいます。
Low memoryモード
上記のように追加処理や削除処理を繰り返しながら効率良くトリガー評価等を行っているのですが、場合によってはValueCacheが消費され枯渇するケースも発生します。ValueCacheから新規でメモリを確保しようとした際、空き容量不足で確保に失敗すると、ValueCacheのモードがNormalモードからLow memoryモードにスイッチします。
Low memoryモードになった場合、直近のデータ(直近1日以内にアクセスのあるものでヒット率の高いもの)はValueCache上に確保してトリガー評価処理のパフォーマンスの維持をしつつ、新規で入ってくるデータについてはValueCacheに登録を行わないような挙動になります。
新規で値がValueCacheに格納されなくなる=評価の都度DBへの問合せが発生することになります。
そうなると、ValueCacheを無効にした時のようにパフォーマンスが低下します。
Low memoryモードからの復帰には、丸1日経過するか、Zabbix Serverを再起動させなければいけません。
一応内部の処理では、Low memoryモードになる直前に、一旦空き容量を確保するため、直近1日以上アクセスのないキャッシュは解放するようですが、根本的にアイテム数が多かったり、トリガー評価式で大量の監視データを使うケースでは、ValueCacheSizeが小さいとLow memoryモードになってしまうので、ValueCacheの最大サイズのチューニングが必要です。
ログ監視のバースト時の注意
また、ログ監視を行っていて、突如大量のログ検知が発生した場合には注意です。
Zabbixの内部プロセスでは、トリガー評価時に不整合が発生しないよう、現在評価中のValueCacheのデータには「保留」のステータスを割り振るようです。
この場合、ValueCache上からのデータ削除処理がパスされ、データが残り続けるようです。
また、ログ監視でバーストが発生すると、同一のトリガーに対してログの件数分評価が大量発生することになります。
そのため、長時間に渡って1つのDB Syncerプロセスが該当のトリガーをロックして他のDB syncerプロセスで処理させないようにするため、DB syncerの処理をスケールさせることもできない状態に陥ります。
シーケンシャルにバーストした各ログを処理し続け、その間ValueCacheにログデータが書き込まれ続けることになるため、ValueCacheの枯渇を招きやすい状況になってしまいます。
もしこういった状況が発生し得るのであれば、最悪のケースを想定したValueCacheのサイズ見積が必要となります。
ValueCacheの状態を監視
実際に運用を始めた後、ValueCacheがどのような状態で稼働しているのかを監視するには、Zabbixの内部監視の機能が活用できます。
| アイテムキー | 監視内容 |
|---|---|
| zabbix[vcache,cache,hits] | ValueCacheのヒット数 |
| zabbix[vcache,cache,misses] | ValueCacheの非ヒット数 |
| zabbix[vcache,cache,requests] | ValueCacheへのリクエスト数 |
| zabbix[vcache,cache,mode] | ValueCacheのモード(0:Normal,1:Low memory) |
| zabbix[vcache,buffer,free] | ValueCacheの空きサイズ |
| zabbix[vcache,buffer,pfree] | ValueCacheの空き率 |
| zabbix[vcache,buffer,used] | ValueCacheの使用中サイズ |
| zabbix[vcache,buffer,pused] | ValueCacheの使用率 |
| zabbix[vcache,buffer,total] | ValueCacheの全体サイズ |
この辺りのデータを見つつ、DB syncerプロセスの状況を見つつ状況を眺めると状態がわかります。
まとめ
文章ばかりの記事になりましたが、ValueCacheの紹介でした。中小規模で特に普通に監視をしていればデフォルトの設定のままでもValueCacheは特に問題にならないかと思います。ですが、環境が大規模だったり、監視データが高頻度で多量化してくると、気にかけた方が良い点かと思います。