The Zabbix server will be modified for not accessing the history database directly anymore. In particular, the access to history data will be provided by a separated service that will take care of managing requests for access to the history database through a REST API. The new work-flow for the server will be:

• The Zabbix server will receive a new value.
• The new value will be processed (trigger expressions evaluation, correlations etc).
• The value will be prepared and sent to the history service.
• If the history service is down, values will be buffered in the zabbix server.
• After some seconds, a request with the same data that was not sent will be retried by the zabbix server until the request succeed.
• The value will be stored in the value cache and local history cache.
• The history service will take care of serving the received data through the new REST API.
• Data sent from the zabbix server to the history service will also contain a TTL (time-to-live in seconds) of the value itself. This value will reflect the configuration applied in the zabbix server and used by the housekeeper process for deleting data. When the TTL of the value will expire, the value will be simply removed from the history service.

A new series of REST APIs will be provided by the history service. The zabbix server (and also third party programs), will be able to use those APIs for retrieving history data, store new data in the history service.
The zabbix server will heavily leverage the usage of this APIs for accessing history data and it will be treated by the history service, like any other program willing to access the data.

Below, the list of APIs required for a successful integration with the zabbix server:

The authentication APIs describe below are actually optional and will be reserved for future use:

Survey for feedback on proffered data storage - https://beta.doodle.com/poll/2pdv8c42z6hb3u49