Zabbix 4.0 LTSで追加されたうれしい機能と改善ポイント

本機能はバージョン3.2における目玉機能の一つとして実装されたもので、トリガーによって生成されたイベントに対して、タグを付与することが可能になりました。タグはKey（項目名）とValue（値）で構成され、トリガー設定画面で定義できます。

タグ機能が追加されたことによって、これまでとなにがどう変わるのでしょうか。

これまでのZabbixは、Web画面の可視性や通知設定の最適化を検討した場合、ホストグループやテンプレートによるグルーピング方式とアイテム名、アプリケーション名、トリガー名のネーミングルールの組み合わせで実現方法を模索する必要がありました。

これらは多くの場合、要件を完全に満たすことはできず、継続的な設定変更に対して柔軟性を欠くことが多々あります。

しかしながら、タグ機能が追加されたことにより、タグベースでのフィルターが可能になることによって、グルーピングに依存しない画面表示が可能になり、各ホストの有するトリガーのうち、一部のホスト、単一のトリガーから生成されるイベントだけ通知先を分けたいという要件に対しても、グルーピングやネーミングルールに頭を悩ませることなく、通知条件にタグを指定することにより対応が可能になりました。

また、イベントタグを用いて、イベントの相関関係の機能を利用できるようになっています。イベントの相関関係は、イベントに付与されたタグのKeyとValueを用いてイベントの障害と復旧を関連付けて扱えるようにできる機能です。例えば、ログ監視において特定の文字列が発生したら障害、その後指定の文字列が発生したら復旧といった動作を容易に実現できます。

イベントの相関関係は非常に便利な機能でありますが、設計、設定が非常に複雑になりがちなため、注意が必要です。

バージョン3.0まではトリガーの条件式は障害の条件式しか存在せず、トリガー条件式に一致した場合に障害イベントを生成し、トリガー条件式に一致しなくなった場合に復旧イベントを生成するという仕様でした。

実際にトリガー条件を設計・設定する際には、状況の継続的かつ細かい変動によるアラートのバタつきを抑制するため、障害条件に不一致 = 即復旧という動作を避けたいケースが多々あります。

上記要件を満たすためにこれまでは障害条件、復旧条件をそれぞれ論理式で連結しながら現状のトリガーのステータスに応じて、動作を分岐させる複雑なトリガー条件式を設定する必要がありました。

バージョン4.0にてトリガー復旧条件の簡素化が行われたことにより、これまでの障害の条件式に加えて復旧条件式の設定欄が追加され、複雑な条件式を設定する必要もなく、難しい論理式に頭を悩ませることなく、直感的かつ容易に復旧条件の設定が可能になりました。

Zabbixを運用する上で多くの場合問題となるのはテキストログ監視です。

Zabbix におけるテキストログ監視は、出力されたログ文字列を1行毎処理します。それにより瞬間的に大量のログが出力された場合、Zabbix Agent、Zabbix Server、Zabbix DB、出力された文字列が通知対象であったならば通知に用いるメールサーバーにまで高い負荷を与え、長時間それらの処理に追われることにより最新ログの読み込みが遅延し、真に検知したい最新の検知対象文字列の通知が遅れる事象が発生する可能性がありました。上記に対し、ログ監視アイテムに新たに「maxdelay」パラメータが追加されました。

このパラメーターはログを受信し始めてから何秒以内に最新のログを評価したいかを指定できます。過去のログ読み込み所要時間の実績を元に、現在出力されているログがmaxdelayパラメータで指定されている秒数以内に読み込みが完了しないと判断された場合、指定されている秒数以内に読み込みが完了する箇所まで、ログの読み込みをスキップします。

これにより、上記のような各コンポーネントへの負荷やログ読み込みの滞留、最新の検知対象文字列の通知遅延などを回避できます。

log.countやlogrt.countといった、監視間隔当りのログ発生件数をカウントするアイテムも新規追加され、発生件数ベースでの監視も可能となっています。

また、Zabbix内部プロセスであるAlerterの並列起動が可能になったことで、上記の通知遅延はより発生しづらくなっています。

Zabbixを運用する上でステータスが取得不可となったアイテムへの対策は運用者の頭を悩ませる問題です。

これまでも取得不可アイテムの検知および通知は可能でしたが、条件を個別、柔軟に変更できず、取得不可アイテムが多数発生する環境では実用に耐えませんでした。そこで値の更新有無について監視をするトリガー条件式であるnodata関数を用いて個別のアイテムの取得不可を検知、通知することを検討しますが、残念ながらバージョン3.0までのnodata関数はステータスが取得不可となったアイテムに対しては評価をせず、検知・通知できませんでした。

しかしながら、ついにnodata関数が取得不可のアイテムに対しても評価をするようになりました。これによりバージョン4.0では取得不可アイテムをnodata関数により個別に検知することが可能になり、必要な対象だけ任意の条件で取得不可アイテムの発生を検知、通知することが可能になりました。

Zabbixには監視対象毎に自動的にアイテムやトリガー、グラフを生成する LLD（ローレベルディスカバリ）と呼ばれる自動監視機能があります。

LLDはサーバー内の状況に応じて動的に監視対象や監視内容を変化させ、運用コストを大きく削減できる非常に魅力的な機能です。

しかしながら、LLDで作成された設定は手動で操作できず、設定の変更やチェックボックスを用いた一括更新によるステータス変更、削除ができませんでした。

バージョン4.0では、LLDで作成された設定の手動操作が可能になっています。これによりLLDによって自動で作成されてしまった不要設定の手動削除、ステータスの手動一括更新が可能です。

上記以外にも、マクロ、正規表現機能の強化やトリガーの手動による正常化、Web シナリオのXMLエクスポート、インポート、新たな監視アイテム、APIキーの追加に伴う監視機能の拡充および柔軟性、保守運用性の向上、キャッシングや内部プロセス動作の改善による性能向上、WebUIの最適化による可視性の向上などさまざまな改善が行われています。

VMWare監視やJMX監視のサポートなど、旧LTSバージョンの変更点と比べ大きな機能追加が多くありませんが、これまでよりもより使いやすく、より便利に変わっています。ぜひZabbix 4.0をお試しください。

バージョン4.0になり、ますます便利に使いやすく高性能で魅力的になったZabbixですが、Zabbix APIの仕様変更による一部メソッドとパラメータの廃止、WebインターフェースにおけるIE9、ならび10のサポートを終了するなど、採用やバージョンアップにむけて注意しなければならない点も多くあります。

特にバージョンアップに関しては、十分な調査と検証の上で実施してください。

当社の価値はお客様のビジネスを支える高度なIT技術や運用基盤の提供にあります。
お客様の課題や問題意識を受け止め、IT戦略/企画の立案、実行性のある計画作成から運用整備とデリバリーまで、さまざまな形態のサービス提供をしています。これまで培った運用管理技術とZabbix技術の豊富なノウハウと実績をもとに、実運用に耐えうる高品質なZabbix環境の構築や課題解決をいたします。