[ZBXNEXT-2098] Creation of loadable modules using script languages/subagent mechanism Created: 2014 Jan 06  Updated: 2024 Apr 10

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

Type: New Feature Request Priority: Major
Reporter: Marc Schoechlin Assignee: Vadim Ipatov
Resolution: Unresolved Votes: 7
Labels: externalchecks, loadablemodule
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Team: Team A
Sprint: Sprint 14, Sprint 15, Sprint 16, Sprint 17, Sprint 18, Sprint 19, Sprint 20, Sprint 21, Sprint 22, Sprint 23

 Description   

I really welcome the possibility to create loadable modules for zabbix - this might make solutions like https://github.com/digitalmediacenter/mysql_extend obsolete
(which reduces the overhead of fetching hundreds of measurement items by using shared memory segments).

Typically sysadmins are good in writing code with script languages - therefore it would be great to integrate new monitoring functionality by using script languages.
So why not supporting loadable modules which are written in script languages?

MySQL_Extend is a good example - a external check which invokes the mysql commandline hundred times needs a lot of resources at the database server and
provides some other difficulties. The implementation of mysql_extend was a bit too complex for the needed purpose, future enhancements of this tool like parsing the output of "SHOW ENGINE INNODB STATUS" is a real pain if your write this in c. If there is a possibility to write this in python is dramatically more easy

It might be great if zabbix would embed a python, ruby, perl or php interpreter to for implementation of custom modules.
But a old feature request (ZBXNEXT-701), which is closed by this request, requests the implementation of a "subagent protocol" which utilizes a forked process and communication by STDIN/STDOUT to allow a simple implementation of new monitoring mechanisms.

From my point of view this is smarter, because:

  • Agent, Proxy and Server do not have to be linked with a scripting language interpreter
  • There is no no need to care about which language is used by the module (Sheebang is enough)
  • The forked process does not influence the stability of proxy-, server- or agent-processes


 Comments   
Comment by richlv [ 2014 Jun 30 ]

not quite that, but ruby support implemented as a loadable module : https://github.com/BlueSkyDetector/mruby_module_for_zabbix_agent

Comment by Marc [ 2017 Jul 21 ]

In the sense of richlv's comment, these two are possibly worth to mention as well:

Comment by Marc Schoechlin [ 2017 Oct 27 ]

Its nice to have the mruby module - python might be my fist choice

I still think that the invocation of a subprocess would be a really good thing (i described the reasons above) and would boost the capabilities of zabbix dramatically.
I you need someone to discuss implementation ideas or the reasons this feature, please do not hesitate to contact me directly by mail.
(you get my mail address at https://github.com/scoopex)

Generated at Fri Mar 14 18:07:02 EET 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.