Abstraction and Cleanup

[splitice]

Does v2 include refactoring into a multi-class application? Possibly a PHP modern "web app" so to speak.

Basically I think this could benifit from:

• Modularization (e.g notification sender - then support for alternative media types e.g slack could be provided)
• composer / packagist (to bring in those sweet dependencies)
• unit tests
• CI

[moudsen]

v2 is about splitting off the message code from the graph code so it can be re-used by other media types like Slack. There is a ticket with Zabbix running to do that for over 10 years (!) now, and the split will create a workaround until creation or adoption of the functionality. I have no intention to take over anything else outside e-mail.

v3 will be on automation of the installation / configuration and upgrade of the module(s) including auto configuration via the Zabbix API for dependent or forced items which currently has to be done manually. The Zabbix code setup does not allow for full integration within Zabbix as a module. This part will also include testing amongst others.

I have no intention to go beyond that level. Several reasons of which the most important ons that the code does not need it (it's all sequential) and very consumable (and fast) in its current format. If I would rebuild, my choice would be to build in GoLang as a daemon. In another project I'm already exactly doing this (replacing/supercharging some of the other functions of Zabbix).

Fact remains that other Zabbix extensibility options (plug-in style) are non-existent and require cooperation of the Zabbix core team. That's hard I can tell you from my own experiences so far ... (and given the outstanding feature requests over a very long time).

[moudsen]

https://support.zabbix.com/browse/ZBXNEXT-562
https://support.zabbix.com/browse/ZBXNEXT-5611
https://support.zabbix.com/browse/ZBXNEXT-6535
https://support.zabbix.com/browse/ZBXNEXT-6548

[splitice]

By running as a webhook this service already runs effectively as a daemon with all the opcache benifits of such. Performance is hence a non-issue assuming the end users PHP installation is configured for such.

I'm well aware of the state of long running open tickets with Zabbix - I've got tickets that are nearly 10 years old myself complete with multiple pactches from myself and others.

You do not need co-operation from zabbix to modularize your code. You do however need to move away from the linear single file design (it's not a good practice anyway).

[moudsen]

It's a shame the Zabbix core team does not seem to move forward with some true innovation. I like the product a lot and would like to put some more effort in it as well for further improvements at several levels (including app-hooks for example) ...

With regards to the modularization: I'll give it a thought towards v2 as I'm splitting off functionality anyway at that point and where I'll make a decision to stick to PHP or switch to Go (for several reasons, including some enhanced monitoring services I've collected into a single daemon) and v3 for having a nice GUI instead of doing this at the techy level on CLI.
The works started out as a "hobby" project and now that interest is growing I can make the switch to the 2nd level of maturity .

Your discussion triggered something else with me: I'm now considering to bundle functions into single code (that will definitely have modularization). Thanks for that.

[splitice]

I'd suggest sticking with PHP if possible. The Zabbix Frontend is already PHP - people know it and are ready for it. Without a strong argument for something like Go it's probably just complexity. I'm guessing such an argument might be made for discord integration or any "bot" integration that utilizes a persisted connection.

[moudsen]

I do have several other reasons for integration into a daemon besides the persistency part but will go along with your argument to stick to PHP. Having this said I'm now considering a refactor of my code however adapting along my roadmap of v2 (splitting obtaining a graph) and v3 (automation) as my current priorities.

[moudsen]

I've decided to stick to PHP and will conduct some refactoring.

The refactor will also include some investigation into the new Zabbix Web Gateway as this is where I would expect the "Graph" facility to go into.

A full class/reusable code will not be likely as I fail to see any benefits for it (the unit is specific for Zabbix) and would also destroy the flow simplicity that's currently crafted (and makes it easier for other developers to adapt/contribute to the flow).

The Graph code will leave this code anyway (either in a separate function or towards the Zabbix Web Gateway).