dustmite
-
104 votesunder review ·
Admindnsmichi
(Admin, Icinga)
responded
would need a special module on the api, generating configoutput from the core. under review, but more developers for design/implementation needed.
dustmite
gave this 3 votes
·
-
5 votesunder review ·
Admindnsmichi
(Admin, Icinga)
responded
for the modular examples, see this https://dev.icinga.org/issues/1697 for contacts self assigning, i would suggest an external application managing the authority on that.
dustmite
shared this idea and gave it 2 votes
·
This would be a killer functionality against other competitors on the market. In a recent project at my place of work to assess other monitoring systems, there's a big thing made in some commercial systems that systems can 'self register' if an agent/etc is installed on them. In my company we use a massively installed (across almost 1000 servers) application, the ability for the software to be able to register to the monitoring server automagically would be an absolute killer feature. Products like Microsoft System Center Operations Manager do allow such a thing, and I would love *love* LOVE! for something like Icinga to offer this.
I think a key area here is to move towards a method for the core API to modify/update the configuration files. The question there, of course is what element of the system should be updating the files directly. I mean, it's a trivial matter to knock up a cgi that, given certain posts (with valid key) can modify the file system and add a new host/service definition, but that relies on things like service/host templates, etc. But then again... If the CGI searched for a specified host/service template (that the post to the registering CGI pointed at), and located it, it would know what to do. I hope this makes some rambling sense! Thanks!