Zabbix:可加载模块及模块API

参考《zabbix3.4中文手册》

七、可加载模块

可加载模块提供了一种关于Zabbix性能扩展的选项。

可以通过以下方式扩展Zabbix功能:

    user parameters (代理指标)

    external checks (无代理监控)

    system.run[] Zabbix agent item.

它们能运行的很好,但有一个主要的缺点,即fork()。 Zabbix必须在每次处理用户指标时分配一个新进程,这对于性能不利。这一般来讲不是严重的问题,但是在监控嵌入式系统,具有大量监控参数或具有复杂逻辑或启动时间很长的复杂脚本的情况下,这也许是一个严重的问题。

支持可加载模块提供了扩展Zabbix代理、服务器、代理服务器的方法,同时不牺牲性能。

可加载模块基本上是Zabbix守护程序使用的共享库,并在启动时加载。该库应包含某些功能,以便Zabbix进程可能会检测到该文件确实是可以加载和使用的模块。

可加载模块具有许多优点。卓越的性能和可实现任何逻辑的能力是非常重要的,但更最重要的优势是使用和共享Zabbix模块的开发能力。它有助于可靠的维护,并有助于更轻松、更独立于Zabbix核心代码库提供新功能。

八、模块API

为了将共享库按照Zabbix模块进行处理,它应该执行和导出多个功能。Zabbix模块API目前有六个功能,其中只有一个是强制性的,另外五个是可选的。

1.强制接口

唯一的强制功能是 zbx_module_api_version():

int	zbx_module_api_version(void);

此函数应该返回此模块的API版本,为了模块加载此版本必须匹配Zabbix支持的模块API版本。 Zabbix支持的模块API版本为ZBX_MODULE_API_VERSION。 所以这个函数应该返回一个常数。用于此目的的旧常数ZBX_MODULE_API_VERSION_ONE现在被定义为等于ZBX_MODULE_API_VERSION以保持兼容性,但不推荐使用。

2.可选接口

可选的接口是 zbx_module_init(), zbx_module_item_list(), zbx_module_item_timeout(), zbx_module_history_write_cbs() 和 zbx_module_uninit():

int zbx_module_init(void);

该功能应该对模块进行必要的初始化(如果有的话)。如果成功,应该返回ZBX_MODULE_OK。否则,应该返回ZBX_MODULE_FAIL。在后一种情况下,Zabbix将不会启动。

ZBX_METRIC  *zbx_module_item_list(void);

此功能应返回模块支持的监控项列表。每个监控项都是在ZBX_METRIC结构中定义的,有关详细信息,请参阅下面的部分。列表由ZBX_METRIC结构终止,“key”字段为NULL。

void    zbx_module_item_timeout(int timeout);

如果模块导出zbx_module_item_list(),那么Zabbix使用该函数来指定Zabbix配置文件中由模块实现的监控项检查应该遵循的超时设置。这里,“timeout”参数是以秒为单位。

ZBX_HISTORY_WRITE_CBS   zbx_module_history_write_cbs(void);

该函数应该返回回调函数Zabbix服务器或代理服务器将用于导出不同数据类型的历史记录。回调函数作为ZBX_HISTORY_WRITE_CBS结构的字段提供,如果模块对某种类型的历史不感兴趣,则字段可以为NULL。

int zbx_module_uninit(void);

此功能应执行必要的反初始化(如果有的话),如释放分配的资源、关闭文件描述符等。

模块加载时、Zabbix启动时,所有功能除了zbx_module_uninit()都将被调用一次。在卸载模块时、Zabbix关闭时会调用一次。

3.定义监控项

每个监控项都在ZBX_METRIC结构中定义:

typedef struct

{

    char        *key;

    unsigned    flags;

    int     (*function)();

    char        *test_param;

}

ZBX_METRIC;

 

这里,key是监控项Key(例如,“dummy.random”),标志是CF_HAVEPARAMS或0(取决于监控项是否接受参数),function是实现该项目的C函数(例如,“zbx_module_dummy_random” ),test_param是使用“-p”标志启动Zabbix代理时使用的参数列表(例如,“1,1000”,可以为NULL)。 示例定义如下所示:

static ZBX_METRIC keys[] =

{

    { "dummy.random", CF_HAVEPARAMS, zbx_module_dummy_random, "1,1000" },

    { NULL }

}

实现一个监控项的每个函数应该接受两个指针参数,第一个是AGENT_REQUEST类型,第二个是AGENT_RESULT类型的参数:

int zbx_module_dummy_random(AGENT_REQUEST *request, AGENT_RESULT *result)

{

    ...


    SET_UI64_RESULT(result, from + rand() % (to - from + 1));


    return SYSINFO_RET_OK;

}

如果监控项的值成功获取,这些函数应返回SYSINFO_RET_OK。否则,它们应该返回SYSINFO_RET_FAIL。有关如何从AGENT_REQUEST获取信息以及如何在AGENT_RESULT中设置信息的详细信息,请参阅下面的示例“dummy”模块。

4.提供历史记录导出回调

模块可以指定按类型导出历史数据的函数:Numeric(float),Numeric(unsigned),Character,Text和Log:

typedef struct

{

    void    (*history_float_cb)(const ZBX_HISTORY_FLOAT *history, int history_num);

    void    (*history_integer_cb)(const ZBX_HISTORY_INTEGER *history, int history_num);

    void    (*history_string_cb)(const ZBX_HISTORY_STRING *history, int history_num);

    void    (*history_text_cb)(const ZBX_HISTORY_TEXT *history, int history_num);

    void    (*history_log_cb)(const ZBX_HISTORY_LOG *history, int history_num);

}

ZBX_HISTORY_WRITE_CBS;

每个人都应该以“history_num”元素的“history”数组为参数。 根据要导出的历史数据类型,“history”分别是以下结构的数组:

typedef struct

{

    zbx_uint64_t    itemid;

    int     clock;

    int     ns;

    double      value;

}

ZBX_HISTORY_FLOAT;


typedef struct

{

    zbx_uint64_t    itemid;

    int     clock;

    int     ns;

    zbx_uint64_t    value;

}

ZBX_HISTORY_INTEGER;


typedef struct

{

    zbx_uint64_t    itemid;

    int     clock;

    int     ns;

    const char  *value;

}

ZBX_HISTORY_STRING;


typedef struct

{

    zbx_uint64_t    itemid;

    int     clock;

    int     ns;

    const char  *value;

}

ZBX_HISTORY_TEXT;


typedef struct

{

    zbx_uint64_t    itemid;

    int     clock;

    int     ns;

    const char  *value;

    const char  *source;

    int     timestamp;

    int     logeventid;

    int     severity;

}

ZBX_HISTORY_LOG;

数据写入Zabbix数据库并保存在值缓存中之后,Zabbix服务器或代理服务器历史记录进程将在历史记录同步过程结束时使用回调。

5.构建模块

模块是要在Zabbix源代码树中构建的,因为模块API依赖于在Zabbix头文件中定义的一些数据结构。

可加载模块最重要的头是include/module.h,它定义了这些数据结构。另一个有用的头是include/sysinc.h,它执行包含必要的系统头,这本身就有助于include/module.h正常工作。

为了include/module.h和include/sysinc.h被包括在内,应该首先在.bbbix源代码树的根目录中运行./configure命令(不带参数)。这将创建include/config.h文件,其中包括/sysinc.h依赖。(如果你获得Zabbix源代码作为Subversion存储库检出,则./configure脚本不存在,应首先运行./bootstrap.sh命令生成它。)

在上述情况都考虑到之后,一切都为建立模块准备好了。该模块应包括sysinc.h和module.h,构建脚本应确保这两个文件位于包含路径中。有关详细信息,请参见下面的“dummy”模块示例。

另一个有用的头是include/log.h,它定义了zabbix_log()函数,可用于记录和调试目的。

 

注意:可加载模块仅支持Unix平台,不适用于Windows代理。

在某些情况下,模块可能需要从zabbix_agentd.conf读取相关的配置参数。如果你需要使用模块来使用某些配置参数,那么你应该实现对特定于模块的配置文件的解析。

猜你喜欢

转载自blog.csdn.net/zz17zz/article/details/82219661