Check_mk – monitoring solution created by Mathias Kettner. I learnt aabout it 2 year ago as an alternative for nagios:
Under the hood it’s nagios engine with innovative mklivestatus as monitoring engine and very functional GUI – so in theory integration should be easy as eating a cake. However if you have access only via http – then it could be a challenge;)
Here’a short list of configuring it:
- Approach to distributed monitoring by check_mk (easy if you have access via ssh):
2. check_mk HTTP-API (some kind of RESTAPI if you have access as admin in order to create proper user):
3. if you have acces only via http then:
a. create proper views as described here:
b. use saved view and export data as json:
c. having this output write a JSON parser using one of methods below:
in order to get output in nagios format and send it as passive check via scheduled cronjob:
Submitting Passive Service Check Results
External applications can submit passive service check results to Nagios by writing a PROCESS_SERVICE_CHECK_RESULT external command to the external command file.
The format of the command is as follows:
- timestamp is the time in time_t format (seconds since the UNIX epoch) that the service check was perfomed (or submitted). Please note the single space after the right bracket.
- host_name is the short name of the host associated with the service in the service definition
- svc_description is the description of the service as specified in the service definition
- return_code is the return code of the check (0=OK, 1=WARNING, 2=CRITICAL, 3=UNKNOWN)
- plugin_output is the text output of the service check (i.e. the plugin output)
Note: A service must be defined in Nagios before you can submit passive check results for it! Nagios will ignore all check results for services that had not been configured before it was last (re)started.
An example shell script of how to submit passive service check results to Nagios can be found in the documentation on volatile services.