値キャッシュのメモリ効率が改善されました。本リリースでは、同じ量の値でも、より少ない共有メモリでキャッシュできるようになりました。
HOST.PORTマクロは現在、トリガーベースの通知、内部イベントの通知、およびトリガーの名前、トリガーの説明で使用可能です。このマクロは現在、任意の番号のサフィックスをサポートしており、これにより、トリガー条件式に現れる順番にホストを参照できます({HOST.PORT1}, {HOST.PORT2} ...)。
サーバープロキシ通信において、エラーログレコードが改善されました。サーバ、プロキシのログファイルにおいて、いくつかのエラーメッセージが改善されることで、障害に関する情報が更に充実しました。
syslog 中のZabbixアプリケーション名は、RFC 5424が定めるAPP-NAMEを満足するように修正されています。Syslogアプリケーション名の変更を参照してください。
トリガーは現在、メインプロセス、ヒストリ同期プロセスまたはタイマープロセスで一度に1つだけ処理されます。これにより、いくつもの正常イベントが連続するという障害が解消され、大型システムのタイマープロセスのパフォーマンスが改善されます。処理するトリガーはヒストリ同期プロセスによってすでに処理されているので、これらが行う作業が重複することはありません。
ローレベルディスカバリ中のトリガー処理パフォーマンスが改善されました。
ローレベルで発見されたトリガーは削除されず、関連アイテムが発見されなくなっても(これらのアイテムが削除されるまで)動作し続けます。
インターフェースが同じである複数のアイテムに対し、ICMP pingチェック(icmpping、icmppinglossおよびicmppingsec)のスケジュールが同期化されました。以前は、ホストがICMP ping系アイテムを複数備える場合、アイテムごとにfpingユーティリティを呼び出すことが大いにあり得ました。ICMP pingチェックが同期化されたことで、fpingユーティリティを1回呼び出すだけですべてのチェックができます(ただし、これらのチェックはすべて、パケットの数、更新間隔、サイズ、タイムアウト値が同じであることが前提です)。例えば、ホストがicmpping、icmppinglossおよびicmppingsecアイテムを備える場合、fpingを1回呼び出すと3つのパケットのみが送信されます。以前は、fpingを3回呼び出し、9つのパケットが送信されたはずです。
以前は通知レポート中でITEM.LOG.*マクロが置き換えられると、データベースからアイテム設定情報が取得されました。Zabbix 2.2.2以降、この情報は設定キャッシュから取得されます。
本ページは2014/08/05時点の原文を基にしておりますので、内容は必ずしも最新のものとは限りません。
最新の情報は、英語版のZabbix2.2マニュアルを参照してください。