[ZBXNEXT-3174] New API/ABI for loadable modules Created: 2016 Mar 04  Updated: 2019 Nov 15

Status: Open
Project: ZABBIX FEATURE REQUESTS
Component/s: Agent (G), Installation (I), Proxy (P), Server (S)
Affects Version/s: None
Fix Version/s: None

Type: Change Request Priority: Trivial
Reporter: Glebs Ivanovskis (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 9
Labels: compatibility, libraries, loadablemodule
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Here is a draft of a new interface between Zabbix and loadable modules. The main idea is to make this interface easily extendible in later versions of Zabbix and to make maintaining backward compatibility easier at the same time.

Loadable module should provide the following interface:

/* this function should perform module initialization and return success/error code */
int	zbx_module_init(void);

/* this function should return a list of custom checks supported by the module */
zbx_item_list_t		zbx_module_item_list(void);

/* this function should set timeout for item checks */
void	zbx_module_item_timeout(int timeout);

/* this function is optional and should free module resources if necessary */
int	zbx_module_uninit(void);

/* this is an example of a function performing custom check, returns success/error code */
int	zbx_module_custom_check(zbx_agent_request_t request, zbx_agent_result_t *result);

Zabbix must provide a header file containing forward declaration of types zbx_item_list_t, zbx_metric_t, zbx_agent_request_t, zbx_agent_result_t and functions used to work with them. Implementation must not be exposed! This will allow to change it without breaking binary compatibility.

/* this defines the version of the header file, should be updated every time new functions are added to API (or old functions are removed) */
#define ZBX_MODULE_HEADER_VERSION	...

/* this function returns version of the library loaded in runtime */
int	zbx_module_library_version(void);

/* this type stores list of custom metrics */
typedef struct zbx_item_list	zbx_item_list_t;

/* this type stores a metric */
typedef struct zbx_metric	zbx_metric_t;

/* this type stores check request */
typedef struct zbx_agent_request	zbx_agent_request_t;

/* this type stores check result */
typedef struct zbx_agent_result	zbx_agent_result_t;

/* this function creates custom check list */
zbx_item_list_t	zbx_item_list_create(void);

/* this function appends custom check to the list */
void	zbx_item_list_append(zbx_item_list_t list, zbx_metric_t metric);

/* this function frees check list resources (Zabbix should make his own copy) */
void	zbx_item_list_destroy(zbx_item_list_t list);

/* this function creates custom check description */
zbx_metric_t	zbx_metric_create(void);

/* possible metric attributes */
#define ZBX_METRIC_ATTR_KEY ...
#define ZBX_METRIC_ATTR_ALLOW_PARAMS ...
/* list can be expanded without breaking compatibility */

/* this function sets custom check attributes */
int	zbx_metric_attr_set(int attribute, void *value);

/* this function frees custom check resources */
void	zbx_metric_destroy(zbx_metric_t);

/* similar functions to manipulate request and result */
...

This functionality should be provided as a library (it can be used by Zabbix own checks as well). No matter how (dynamically or statically) Zabbix and loadable modules will be linked to the library, zbx_module_library_version() can be used to ensure that desired version of API is used.

When this issue is implemented ZBXNEXT-3157 will make sense. And this could be the beginning of ZBXNEXT-2519.

Good read on compatibility issue:
http://www.onlamp.com/pub/a/onlamp/2005/02/17/backwardscompatibility.html (two pages!)

 

UPD: The above link is broken by now, but here's an archived copy:

https://web.archive.org/web/20180424122939/http://www.onlamp.com/pub/a/onlamp/2005/02/17/backwardscompatibility.html



 Comments   
Comment by Vitaly Zhuravlev [ 2017 Jun 02 ]

Based on my experience with developing modules in Zabbix, I would like to add few notes what the second version of the API and module loading mechanics should look like in my opinion.

  • It should return current module version when loaded into zabbix in its log.
  • zabbix_log functions should be made available in the interface, so users can place information to the zabbix log.
  • DebugLevel configuration paramaters should be available to the module, so it can be used to provide or not to provide extended information to the log.
  • To avoid dealing with concurrency problems, it would be cool to have the option to limit module to the single poller only.

I also think that if Zabbix team could port at least one the protocols(JMX, VMWare maybe or IPMI) from the core to the loadable module and ship it that way in the following releases - then it would result in a more effecient and powerful loadable module interface for all. Its source code would also serve as a perfect example on how to properly build zabbix modules.

Comment by richlv [ 2019 Apr 24 ]

The onlamp link is broken by now, but here's an archived copy: https://web.archive.org/web/20180424122939/http://www.onlamp.com/pub/a/onlamp/2005/02/17/backwardscompatibility.html .

Generated at Tue Apr 23 12:07:16 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.