[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 Good read on compatibility issue:
UPD: The above link is broken by now, but here's an archived copy: |
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.
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 . |