現在位置: ホーム / 製品・サービス / 統合システム監視 MIRACLE ZBX / MIRACLE ZBX - Zabbix テック・ラウンジ / Zabbix 3.2以降の新機能解説(Zabbix 4.0を見据えて) その12

Zabbix 3.2以降の新機能解説(Zabbix 4.0を見据えて) その12

こんにちは、MIRACLE ZBXサポートを担当している花島タケシです。 既に Zabbix 4.0.0 alpha1がリリースされて、正式版のリリースが秒読み段階になってきました。 その中の新機能の一つとして、今回は Elasticsearchへのデータの保存について解説します。

Elasticsearchのサポート (Experimentalですが)

ヒストリデータをElasticsearchへ保存できます。

既にZabbix 4.0.0 alpha1がリリースされて、4.0.0の正式版のリリースが秒読み段階になってきました。

今までZabbixにおける監視データはDBへ、Zabbixが定めたスキーマで格納するほかありませんでした。
Zabbixの範囲内で使用する分には問題もなかった(とも言えませんが)のですが、取得した情報の整形という点では不十分であったと思います。

この点を補足するために、Elasticsearchへのデータの保存がサポートされます(Experimentalですが)。

既に3.4.5rc1の段階でElasticsearchに対するコードは導入されており、その後にリリースされた4.0.0alpha1にも当然含まれています。

本ドキュメントは3.4.5rc1のコードを元に解説を行いますが、実装に違いはないでしょう。

どのデータをElasticsearchに収めるべきか?

Elasticsearchはいわゆる全文検索エンジンとなります。

Zabbixでのアイテムのデータタイプは5種類(整数、浮動小数、文字列、ログ、テキスト)ありますが、整数、浮動小数を含めるべきではないでしょう。
実際、数値データを含めることは以下に記しますが有益なことがありません。

 DBとElasticsearchの共用(ストレージエンジンの切り替え)

少しコードを見ていくことにします。

Zabbixサーバは起動直後に MAIN_ZABBIX_ENTRY()内で、各々のデータタイプに対してDBとElasticsearchのどちらを使用するかを、zbx_history_init()をコールしてパラメータに準じて切り替えます。

src/zabbix_server/server.c

 835 int MAIN_ZABBIX_ENTRY(int flags)
 836 {
...
 981   if (SUCCEED != zbx_history_init(&error))
 982   {
 983     zabbix_log(LOG_LEVEL_CRIT, "cannot initialize history storage: %s", error);
 984     zbx_free(error);
 985     exit(EXIT_FAILURE);
 986   }

zbx_history_init()は、src/libs/zbxhistory/history.c に記述されています。

 46 int zbx_history_init(char **error)
 47 {
 48   int i, ret;
 49   /* TODO: support per value type specific configuration */
 50
 51   const char *opts[] = {"dbl", "str", "log", "uint", "text"};
 52
 53   for (i = 0; i < ITEM_VALUE_TYPE_MAX; i++)
 54   {
 55     if (NULL == CONFIG_HISTORY_STORAGE_URL || NULL ==  strstr(CONFIG_HISTORY_STORAGE_OPTS, opts[i]))
 56       ret = zbx_history_sql_init(&history_ifaces[i], i, error);
 57     else
 58       ret = zbx_history_elastic_init(&history_ifaces[i], i, error);
 59
 60     if (FAIL == ret)
 61       return FAIL;
 62   }
 63
 64   return SUCCEED;
 65 }

これ自体の処理は大したことはなく、HistoryStorageURLパラメータ(ElasticsearchのURL)が空か、HistoryStorageTypesパラメータにデータタイプに該当する文字列がない場合、そのデータタイプに対してはzbx_history_sql_init()をコールし、そのデータタイプに対してはDBを用います。

そうでない場合、Elasticsearchを用いるように、zbx_history_elastic_init()をコールします。

なお、HistoryStorageTypesに対するパーズが雑なので、dbloguintextと指定しても大丈夫なはずです…

zbx_history_sql_init()、zbx_history_elastic_init()のどちらも、ほとんど、history_ifaces構造体のメンバーに対応する関数ポインタを指定しているだけです。

それと、トレンドデータの計算をするかしないかのフラグを設定しています。(Elasticsearchではトレンドの計算をしません。)

 実際の書き込み処理

実際にヒストリキャッシュからストレージエンジンへの書き出しは、src/libs/zbxdbcache/dbcache.c : DCmass_add_history()から、一旦ValueCacheを経由して行われます。

src/libs/zbxdbcache/valuecache.c 

2638 void zbx_vc_add_values(zbx_vector_ptr_t *history)
2639 {
2640 zbx_vc_item_t *item;
2641 int i;
2642 ZBX_DC_HISTORY *h;
2643
2644 zbx_history_add_values(history);
...

zbx_vc_add_values()がコールされた直後に、zbx_history_add_values()がコールされます。

この関数は、src/libs/zbxhistory/history.c に記述されており、ストレージエンジン切り替えの中間レイヤーの位置づけです。(3.0では、DB SyncerがDBへデータ挿入した後に、ValueCacheへの挿入を行っていました。)

 100 void zbx_history_add_values(const zbx_vector_ptr_t *history)
 101 {
 102   const char *__function_name = "zbx_history_add_values";
 103   int i, flags = 0;
 104
 105   zabbix_log(LOG_LEVEL_DEBUG, "In %s()", __function_name);
 106
 107   for (i = 0; i < ITEM_VALUE_TYPE_MAX; i++)
 108   {
 109     zbx_history_iface_t *writer = &history_ifaces[i];
 110
 111     if (0 < writer->add_values(writer, history))
 112       flags |= (1 << i);
 113   }
 114
 115   for (i = 0; i < ITEM_VALUE_TYPE_MAX; i++)
 116   {
 117     zbx_history_iface_t *writer = &history_ifaces[i];
 118
 119     if (0 != (flags & (1 << i)))
 120       writer->flush(writer);
 121   }
 122
 123   zabbix_log(LOG_LEVEL_DEBUG, "End of %s()", __function_name);
 124 }

全てのデータタイプに対して、渡された(書き込むための)データ群に対して、データタイプ毎のadd_values()をコールして書き込みをしています。

history_ifaces[]は、Zabbixサーバ起動時にストレージエンジン毎の関数が設定されていました。
したがって、これによりストレージエンジン毎の処理がされることになります。

最後にflush()を行って処理の完結を行っています。
実装されている書き込み、読み出しの中身はともかくとして、簡単な仕組みで切り替えが行えていることがわかります。

ところで、Elasticsearchではトレンドデータの計算が行われていないと上に記しました。

DBを前提とした、既存の実装ではデータの更新前にトレンドデータの計算が行われていました。
これは算出するデータ(最大、最小、平均)を区切りの終了がわからない(区間最後のデータを取得する時刻が不定)ために都度計算する必要があったからです。

この処理が、Elasticsearchでは行われなくなります。(というよりも、データの保存形式上、更新ができない。)

ということは、Elasticsearchを用いた場合一定期間(グラフの描画サイズにも依りますが)を過ぎると、表示されなくなるのでしょうか?

実はそんなことはなく、グラフ表示毎にトレンドデータ相当のための計算が行われます。
当然、WebフロントエンドはPHPで記述されており、サーバサイドの負荷が高くなります。

こういった点から数値データはElasticsearchに保存することはお奨めしません。

なお、Elasticsearchはハウスキーピングの対象とはなっておらず、データ削除はされません。

関連記事

注意事項

本ドキュメントの内容は、予告なしに変更される場合があります。
本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、全ての環境での動作を保証するものではありません。
本ドキュメントの内容に基づき、導入、設定、運用を行なったことにより損害が生じた場合でも、当社はその損害についての責任を負いません。あくまでお客さまのご判断にてご使用ください。

 

MIRACLE ZBX 製品・サポートサービス 詳しくはこちら

MIRACLE ZBX Virtual Appliance V3.0 評価版のお申し込み

製品・サービスについてのお問い合わせ

お問い合わせフォームMIRACLE ZBX製品やサポートサービスについてのご相談やご質問は、「お問い合わせフォーム」よりお気軽にお問い合わせください。