採用情報

お問い合わせ

BLOG

Zabbix テック・ラウンジ

2018 年 04 月 10 日

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

関連記事

Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 1
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 2
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 3
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 4
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 5
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 6
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 7
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 8
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 9
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 10
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 11
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 12
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 13
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 14
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 15
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 16
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 17
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 18
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 19
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 20
Zabbix 3.2 以降の新機能解説(Zabbix 4.0 を見据えて) その 21

注意事項

  • 本ドキュメントの内容は、予告なしに変更される場合があります。
  • 本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、全ての環境での動作を保証するものではありません。
  • 本ドキュメントの内容に基づき、導入、設定、運用を行なったことにより損害が生じた場合でも、当社はその損害についての責任を負いません。あくまでお客さまのご判断にてご使用ください。
CentOS 7 延長サポートサービス
デジタルトランスフォーメーションのための電子認証基盤 iTrust
SSL/TLS サーバー証明書 SureServer Prime