Hello.
I'm looking for a solution for my idea.
I have hosts with perl monitoring scripts running and forwarding to Nagios server. I don't use NRPE - it is socket server using command pipe /usr/local/nagios/var/rw/nagios.cmd, it's generally passive check.
If I well understood I must have every service defined as unique with host. Ie. host+service makes unique message ID which is used to match with defined service.
It is not convenient, because there're many services and I'd like avoid editing every script to modify service name (they are also used on not Nagios monitored systems and I'd like to have them in the same versions).
I'd like to aggregate service name in Nagios with regexp, like in http://mathias-kettner.de/checkmk_aggregation.html"Dynamic aggregated services via pattern extraction"
For example, when I can get output from scripts with such names:
GL.OS.FS,
GL.OS.CPU,
GL.OS.MEM
I'd like to create one aggregated service for them with name GL.OS and catch into it every event sent with command pipe with service name like ^GL.OS.*
Is it possible to implement such Nagios system behaviour?
Thanks.
Aggregated service
-
- Posts: 7698
- Joined: Mon Apr 23, 2012 4:28 pm
- Location: Travelling through time and space...
Re: Aggregated service
This could be possible however it is definitely not a feature. The reason this is not a feature stems from a few things. For one, you would not be able to fit all of your returned service data in one service because of the output size limiters Nagios uses, this is due the the ability for a check to glitch out and stay open indefinitely, filling your server with gobbldyguke, and keeping a pipe open for exploitation.
The second reason is that this is simply not feasible or usable by a large portion of those who do use Nagios for their production environments. Nagios caters to those who would rather have a complex network infrastructure setup which they can edit and control down to the last singular service configuration, in this way they can accurately map out their network as they see it every day.
The second reason is that this is simply not feasible or usable by a large portion of those who do use Nagios for their production environments. Nagios caters to those who would rather have a complex network infrastructure setup which they can edit and control down to the last singular service configuration, in this way they can accurately map out their network as they see it every day.