Zabbix 3.2以降の新機能解説（Zabbix 4.0を見据えて）その12 - Elasticsearchへのデータの保存

こんにちは、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はハウスキーピングの対象とはなっておらず、データ削除はされません。

注意事項

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