See for the official Zabbix site.


Jump to: navigation, search

Support of loadable modules for alternative storage of historical data


Status: Initial draft, do not comment

Owner: Alexei


Traditional SQL engines do not scale well when writing tens and hundreds of thousands of values per second. Also there is no horizontal scalability available out of the box.

Support of alternative storage engines would allow to experiment with different storage engines if implemented as a pluggable module.


Zabbix Server:

  • Support of modules (shared libraries) for enabling alternative history storage
    • A module may have its own configuration parameters in zabbix_server.conf
  • All historical information (history*, trends*) will be processed (stored, read) by the module

Zabbix interface and API:

  • The front-end will communicate to Zabbix Server for retrieving historical data

Zabbix Server

Existing LoadModule directive will be used to enable a module. The module should export the following functions:

 int     zbx_module_api_version();
 # new parameter
 int     zbx_module_init(*config);
 int     zbx_module_uninit();
 # or list of itemids?
 int     zbx_module_history_read(zbx_uint64_t itemid, int period_from, int period_to, int limit);
 int     zbx_module_history_write(history_t *data);
 int     zbx_module_trends_read(zbx_uint64_t itemid, int period_from, int period_to, int limit);
 int     zbx_module_trends_write(history_t *data);

Configuration file:


Zabbix Proxy

Zabbix Proxy will not support alternative storage engines.

Zabbix Interface

The interface will retrieve history by connecting to the server using JSON protocol:




   # same for all values
   # ...

Translation strings

  • New or updated string

Database changes


  • What's new
  • Zabbix Manual

Open questions

  • Will WEB interface always retrieve history from Zabbix server if the module is not enabled?
  • Shall we use module name as a section name in configuration file?


  • N/A