ZABBIX and the kitchen sink (1.4 Roadmap thoughts)

[dminstrel]

Hello,

while reading the roadmap to 1.4, I can't help be concerned by the inclusion of a ticket tracking feature. Part of the UNIX mentality is having many specialized tools that do few things but do them very well. I'm curious: is the goal to make ZABBIX the best NMS software or to make it a one-stop-shop solution for IT management? There already are several excellent ticket tracking applications (Bugzilla, Request Tracker, Trac, etc).

My fear is that by widening the feature set (maybe add a wiki, project tracking, software inventory, document management, etc.) , the ZABBIX team risks diluting their efforts and invest energy reinventing the wheel instead of improving the core features of an already great piece of software. Another problem is that many of us already use ZABBIX alongside wikis and ticket tracking applications. Having ZABBIX reproduce those features risks future confusion.

What IMHO would be nice would be some sort of interoperability. E.g., plugins or wrappers in ZABBIX to talk to the most popular ticket tracking systems already available.

That said, I'm really psyched by the rest of the roadmap. I look forward to having more a more advanced IT Services module. A quick request: would it be possible to have a comments field that could display on the Maps underneath hostnames (Eg : "Mail server" or "firewall").

Cheers,

Jonathan

[abi]

hi Jonathan,

Hello,
My fear is that by widening the feature set (maybe add a wiki, project tracking, software inventory, document management, etc.) , the ZABBIX team risks diluting their efforts and invest energy reinventing the wheel instead of improving the core features of an already great piece of software. Another problem is that many of us already use ZABBIX alongside wikis and ticket tracking applications. Having ZABBIX reproduce those features risks future confusion.

yes, thats exactly what my thoughs were!

What IMHO would be nice would be some sort of interoperability. E.g., plugins or wrappers in ZABBIX to talk to the most popular ticket tracking systems already available.

indeed!

[Alexei]

I don't think that adding ticket tracking functionality may hurt ZABBIX somehow. ZABBIX is all-in-one monitoring solution. Issue tracking is essential
part of any monitoring infrastructure.

I agree, plugins may exist for integratoin with 3rd party tools, however I feel
that there are many users around interested in something more integrated,
having same interface, same database, etc. It also simplifies implementation and maintenance very much.

[mucknet]

FWIW, I too agree, that I would like zabbix to kept to an IT monitoring solution instead of an all around IT management solution. Part of the reason I like zabbix is for its simplicity, and core competency.

[charles]

I think you should go the modular route with plugin support etc. No-one with real helpdesk needs wants a second helpdesk for zabbix, and I doubt yours will be better than the one they already use (certainly not initially anyway).

charles

[Alexei]

Anyone pro-built-in-helpdesk here? Seriously, I have no intention to extend ZABBIX so that it becomes unmanageable and complex piece of software. Absolutely not! Contrawise our main direction is to make the software as simple as possible. Core monitoring functions is our primary focus and it always will be.

I agree, the plugin architecture is extremely important and it will be introduced.

Please no worries!

[ghislain]

i vote for no ticket system

i think otrs or other systems do the job, a real ticket system is a hell complex to get it right. I think better to have an api to reach the alerts than to write a ticket system inside zabbix.

In fact the zabbix way to be able to call script or launch email can be enough to link it to a ticket system. Perhaps an API to make the ticket system "acknoledge" alerts or such is more appropriate.

Thanks for the product again, i think like lots of project you should not want to have everything inside, the real force of a product to me is that :

1/ it does his job very well
2/ it is built to be INSERTED into existing structure ( user auth can be redirected to anther DB auth scheme or LDAP and perhaps PAM ). plugins can be written to access data, API are here etC..

This way you have a wonderfull tool that can be used in the system of everybody. And nothing prevent zabbix to make the things like tickets etc..using his own API


Just my 2 cents !

regards,
Ghislain.

[abi]

In fact the zabbix way to be able to call script or launch email can be enough to link it to a ticket system.

indeed, i - for example - can create tickets by sending E-Mail's
to our HelpDesk system. This works pretty well and each time an
Trigger gets hit were getting a Call to process. No need to have
the same feature in zabbix, we wouldnt use it anyway.

Like said before, Ticketing Systems are HELL of complex (when
it comes to workflows, etc. etc...)

[schneck]

more info for scripts

i vote for no ticket system

seconded. (or thirded? :-)

In fact the zabbix way to be able to call script or launch email can be enough to link it to a ticket system.

What I've been looking for (but to lazy to implement) is additional {VARIABLES} like HOSTID, etc. to pass to scripts, so that the script can figure out some more things from the database (eg, how long a host has been down, are there any other problems with this host, etc)

Perhaps an API to make the ticket system "acknoledge" alerts or such is more appropriate.

Yes, this might be useful! Maybe pass an unique {ACTIONID} to the script and have a way to send an ack-trap to 10051@zabbix_server?

Thanks for the product again

Also seconded.

\B.

[Wolfgang]

Hello,

I sorry to say that i also vote against an intregated ticket system
Why? (yes, most has been already said already)

-ticket systems can be(come) really complex. So i can imagine that the zabbix-ticket-system-part has to compare against the best/other ticketsystem out and i am sure - it can't win. The sad downside of it is: It will have an impact on the entire zabbix product from a userpoint of view, and effect the image of the excellent monitoring part. (i have seen this happening so often...)

-companies working with a ticket system, usally have already one. So where to handle the tickets? I do not believe that one would like to run multiple ticket-systems.

-the purpose of the ticket system (as i understood in the roadmap) would be to open and manage a case when any trigger creates an alarm. Given that one would like to handle this via an automatic system (as we do in some cases, like restart exchange etc.), one would need also a sort of api similar to an integration in a ticket system to achive this.


Having said this, i second the approach to extend for example macros/variables or provide an api instead of starting a new ticketsystem within zabbix. This approach would:
-allow an easy integration for existing ticketsystems, (using a wrapper, email interface or api to zabbix).
-allow more sophisticated automatic handling of alarms. (escalation management)
-allow integration in other cms systems (similar to external ticketsystems), given they can handle external information.

Just my 2cent

Wolfgang

[richlv]

well, i also was surprised to see that item in the roadmap
zabbix still has a room to improve as a monitoring solution, and creating a ticketing/issue/whatever system that does not suck is a monstrous task.

the thing is, even if zabbix includes some built-in system, it _will_ at some point become inadequate and it will be easier to migrate to another solution than extend zabbix.

now, having a good integration with some of the best systems (that probably means starting with bugzilla ) would be very, very welcome.

[grabber]

I would agree with this absolutely 100%, too many times have really good applications been forced in to adding more features to the detriment of it's core function.

Hello,

while reading the roadmap to 1.4, I can't help be concerned by the inclusion of a ticket tracking feature. Part of the UNIX mentality is having many specialized tools that do few things but do them very well. I'm curious: is the goal to make ZABBIX the best NMS software or to make it a one-stop-shop solution for IT management? There already are several excellent ticket tracking applications (Bugzilla, Request Tracker, Trac, etc).

My fear is that by widening the feature set (maybe add a wiki, project tracking, software inventory, document management, etc.) , the ZABBIX team risks diluting their efforts and invest energy reinventing the wheel instead of improving the core features of an already great piece of software. Another problem is that many of us already use ZABBIX alongside wikis and ticket tracking applications. Having ZABBIX reproduce those features risks future confusion.

What IMHO would be nice would be some sort of interoperability. E.g., plugins or wrappers in ZABBIX to talk to the most popular ticket tracking systems already available.

That said, I'm really psyched by the rest of the roadmap. I look forward to having more a more advanced IT Services module. A quick request: would it be possible to have a comments field that could display on the Maps underneath hostnames (Eg : "Mail server" or "firewall").

Cheers,

Jonathan

[peter_field]

I agree - drop the helpdesk

Sorry, I know a bunch of people have said this already, and all the points seem well covered, so I'll keep it short. I also think that efforts would be better spent on the core product than an intergrated helpdesk solution.
Thanks for a great product, lets keep focused.

[Alexei]

Thank for all comments. We are releasing new Roadmap 1.4 this week. It will have some corrections and new features! Stay tuned!