Page 1 of 2
Trying to find the best way to pull information
Posted: Wed Jan 18, 2017 3:01 pm
by teh0015
What I want is to regularly dump every Host -> Service -> Contact(s) from Nagios servers into a csv.
Seems simple enough but I need to do this on a number of Nagios servers (both XI *and Core [34]).
Access to the Nagios servers ranges from login/sudo to just readonly web access.
I've looked at directly pulling from an XI db, or using check_MK, but ideally I'd like to find a single solution that works across all of them.
Re: Trying to find the best way to pull information
Posted: Wed Jan 18, 2017 3:56 pm
by rkennedy
Assuming you're able to read /usr/local/nagios/var/objects.cache - you should be able to parse data out of here and then export it to CSV.
The other options with XI are using Help -> API, which will allow you to pull information in JSON. OR, use the 'Backend API URL' component from Admin -> Manage Components -> Click the screw driver / wrench icon.
One final thing you might find interesting for Core is the JSON handling which we have a presentation available for here -
http://www.slideshare.net/nagiosinc/eri ... -nagios/46
Hopefully that helps - let us know if you have any further questions.
Re: Trying to find the best way to pull information
Posted: Wed Jan 18, 2017 4:40 pm
by teh0015
Assuming you're able to read /usr/local/nagios/var/objects.cache
I can on some but others I only have readonly level web access.
Re: Trying to find the best way to pull information
Posted: Wed Jan 18, 2017 5:20 pm
by dwhitfield
It's possible this will need to be a feature request, but before we do that, let me ask one more question: on the Nagios servers where you have only read-only access, are you able to see every Host, Service, and Contact? If not, then I don't think there's anything we can do from a security standpoint.
Re: Trying to find the best way to pull information
Posted: Wed Jan 18, 2017 5:32 pm
by teh0015
dwhitfield wrote:It's possible this will need to be a feature request, but before we do that, let me ask one more question: on the Nagios servers where you have only read-only access, are you able to see every Host, Service, and Contact? If not, then I don't think there's anything we can do from a security standpoint.
The account I'm using on those machines can see hosts / services (status) ... they *don't seem to be able to see contacts.
I suppose I can write some sort of web scraper but I was hoping there was something a bit more elegant than that.
Re: Trying to find the best way to pull information
Posted: Wed Jan 18, 2017 5:36 pm
by dwhitfield
Are contacts optional then?
Re: Trying to find the best way to pull information
Posted: Thu Jan 19, 2017 10:35 am
by teh0015
dwhitfield wrote:Are contacts optional then?
Pulling the contact data isn't *really optional.
I still need that info and on boxes I have access to I can get it but for the others I'll need to track down the admins and try to get them add a cronjob that pulls it.
Obviously it would be best if I had a single way to pull that info via the web (with readonly access) and I could use that single method against *any of them.
Re: Trying to find the best way to pull information
Posted: Thu Jan 19, 2017 11:42 am
by rkennedy
I filed a feature request for the ability to have read-only users be able to see the object definition. The ID is #10762.
The one concern I have about this though, is that a read-only user will be able to see credentials that could be contained in the check_command - which may not be something a read-only user should have access to.
Re: Trying to find the best way to pull information
Posted: Thu Jan 19, 2017 12:32 pm
by jwelch
I installed livestatus (from the Check_MK folks) on my Nagios XI server and it's now very easy to pull host/service/status data from Nagios on my server quickly and with low overhead. (YMMV)
Re: Trying to find the best way to pull information
Posted: Thu Jan 19, 2017 1:03 pm
by rkennedy
Thanks for sharing your way of doing so - that would still require some access to the machine though for the OP I believe. It's a hard bargain with only having limited access.