オープンソース監視システムZabbixの新しいバージョンのリリースを発表したいと思います。 このリリースでは、次のような基本的に新しい機能が提供されます。
- 追加のイベントフィールド（タグ）
- 手動の問題解決
- イベント相関
- ネストされたホストグループ
- 事故の発生とその回復のための個々の条件の決定
- トリガー式の非厳密な計算
- 履歴データを外部ストレージに複製するためのロード可能なモジュールのインターフェース
...などなど。 catの下で、いくつかの革新について簡単に説明します
イベントタグ
新しいバージョンには、トリガーイベント（タグ）の表示、フィルタリング、およびその他のアクションの基盤があります。 トリガーを設定するときに初めてそれらに遭遇したとき：
そして、新しい[
監視]-> [問題]セクションで再度確認できます。
タグは、表示時または自動アクションの条件（および通知とそのエスカレーションの送信条件）でのフィルタリングに使用できる追加のイベントフィールドと考えてください。最も重要なことは、これらを使用してさまざまな事故を相関させることができます。
イベント相関
1つのデータアイテムを使用して、多くの無関係なイベントを追跡できるようになりました。 Zabbixの一意の識別子はタグの値になります。これにより、特定の問題の発生とその終了を通知するイベントを組み合わせることができます。 したがって、複数のアプリケーションが1つのログファイルに書き込む場合でも問題ありません。各アプリケーションの事故は、互いに干渉することなく作成および復元されます。 この機能のもう1つの便利なアプリケーションは、SNMPトラップの処理です。
グローバル相関
また、完全に異なるトリガーから、さらには異なるネットワークノードで発生するイベントを相互接続する機会もありました。 新しい構成セクション「イベント相関」では、重大な事故、見たいまさに事故であり、アクションを必要とするものが、崩壊する症状の流れにdrれることを許可しません。 過剰な着信イベントはすべて相関され、視界から除去されます。 はい、これはタグに基づいて構成することもできます。
ネストされたホストグループ
ネストされたホストグループを使用すると、監視オブジェクトの階層を作成できます。
これにより、Zabbix内のナビゲーションとアクセス制御の両方が簡素化されます。
新しいクイックオープン作業画面
現在の問題と現在の問題はすべて、（監視イベントの代わりに）新しい監視問題セクションで利用できます。 データベースの問題の履歴は移動し、新しいバージョンは現在の問題とは別になり、パフォーマンスが大幅に向上しました。 柔軟なフィルターを使用すると、必要な情報をすばやく見つけることができ、タイムラインを使用して時間内に移動できます。
手動クラッシュクロージャ
これがZabbixで可能になりました。 問題のリストから古いイベントや無関係なイベントを削除するとともに、夜間に（もちろん修復後）失敗したバックアップに関するアラームを確認して閉じたり、ログファイルから重大なエラーを読み取ったりします。 この場合、テンプレートで設定するときに、トリガーが対応するdawで以前にマークされた問題のみを閉じることができます。
単純化されたヒステリシスと事故回復のための別の条件
問題のフラッシュに対抗するには、Zabbixの初期の段階では、非常に理解しにくい表現、たとえば次の形式の表現を使用する必要がありました。
({TRIGGER.VALUE}=0 and {server:temp.last()}>20) or ({TRIGGER.VALUE}=1 and {server:temp.last()}>15)
気温が20度前後で変動した場合、事故のクラッシュと戦うのに役立ちました。事故は20度で発生しましたが、温度が15を下回った後にのみ回復しました。
これですべてが簡単になりました。
トリガー設定の別のオプションウィンドウで、事故の終了の基準を宣言できます。
それがすべてであり、{TRIGGER.VALUE}を使用したインサイドアウトロジックはありません。
LLDを介して作成されたデータ項目、トリガー、およびグラフを表示する
小さいながらも非常に便利な機能が欠けていました-低レベル検出（LLD）で作成されたオブジェクトを操作する機能も実装されました。 リストされたものはすべて、通常のオブジェクトと同様に削除、無効化、表示できるようになりました。
LLD検出フィルターから漏れる可能性のあるさまざまな破片の除去が簡単になるため、セットアップ中のマウスクリックを大幅に節約できると思います。
再設計されたアクション設定画面
アクション設定ページが再設計されました。 現在、事故の終了時に実行する必要があるすべての操作（アラートまたはスクリプトの実行）は、個別のタブで構成されています。 ここでは、メンテナンスモードにあるネットワークノードからの通知遅延を処理するメカニズムが再設計されました。
Web監視スクリプトのインポート/エクスポート
値マップを3.0にインポート/エクスポートする機能を追加した後、Webスクリプトはアンロードされたままでした。 現在、この不正は解消され、Web検証ソリューションをXMLにアップロードして、他のZabbixサーバーに後でアップロードするためのすべての手順を実行することもできます。
share.zabbix.comに Web監視テンプレートが登場することを期待してい
ますNOTSUPPORTEDデータ要素のトリガー関数
nodata（）関数は、データ項目が利用できなくなったときにトリガーを容易にするために再設計されました。
さらに、関数
date（） 、
dayofweek（） 、
dayofmonth（） 、
now（） 、
time（）は、一般にデータ項目の値にあまり依存せず、常にデータ項目の状態の独立性を計算するようになりました。
さて、そして最も重要なことですが、論理ORの少なくとも一部をチェックできるようになるまで、トリガーは
UNKNOWN状態になりません。 これにより、同じイベントのデータを収集するいくつかの異なる方法を組み合わせて（たとえば、SNMPカウンターを収集してログファイルを読み取るなど）、データ要素の1つにアクセスできないために動作しないことを恐れずに集約アラームを作成できます。
急成長するログファイルの操作
急成長しているログファイルを操作するための新しいオプションが追加されました。 このようなファイルの主な問題は、特定の状況でログに書き込まれる膨大な数のメッセージです。
すべての行をZabbixエージェントで分析する必要があり、フィルターに一致する行がZabbixサーバーに送信されるため、大量の遅延により大幅な遅延が発生する可能性があり、さらに多数の繰り返し行がデータベースに書き込まれます。
このようなログを処理するために、新しいパラメーター
maxdelayが追加されました 。これは、新しい着信メッセージを分析する時間枠を設定します。
すべての行を期日でソートできないことが判明した場合、古いメッセージはスキップされ、より新しいメッセージが優先されます。
また、Zabbixエージェントの新しいデータ要素
log.countおよび
logrt.countが追加されました。これらは、それら自体ではなく、処理された行の数を返します。
count（）関数での正規表現のサポート
非常に小さいが快適な追加。
count（）関数は、すべてのタイプのデータ項目に対してregexpおよびiregexp演算子を使用する機能を獲得しました。
したがって、特定の期間に収集された、正規表現に対応する値の数をカウントできるようになりました。
マクロ値の変換
{ITEM.LASTVALUE}などのマクロの値を変更できるようになりました。 regsubおよびiregsub関数を使用すると、たとえば、ログファイルから行の一部を抽出し、その結果をイベントタグまたはアラートテキストで使用できます。
詳細
ドキュメンテーションの以下のリンクをクリックすると、これらおよびその他の革新について詳しく知ることができます。
このバージョンは、
ここからダウンロードでき
ます 。 更新手順は非常に簡単
です 。
こちらで確認でき
ます 。 MySQLおよびPostgreSQLでパーティション化を使用する場合にのみ追加のアクションが必要になる場合があります。新しいバージョンでスキーマに
加えられた変更
は 、パーティション化テーブルの現在の設定と互換性がない場合があります。