Module: check_mk Branch: master Commit: e78ba92aea78b510c1c6193b501c3d8f79f256e0 URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=e78ba92aea78b5… Author: Lars Michelsen <lm(a)mathias-kettner.de> Date: Tue Apr 2 12:23:34 2013 +0200 Updated bug entries #0905 --- .bugs/905 | 58 ++++++++++++++++++++++++++++++++-------------------------- 1 files changed, 32 insertions(+), 26 deletions(-) diff --git a/.bugs/905 b/.bugs/905 index bdb8103..c7c893e 100644 --- a/.bugs/905 +++ b/.bugs/905 @@ -1,36 +1,42 @@ -Title: We need an option to make "expect messages" based on subregexes possible -Component: ec +Title: Improve shinken support +Component: core +State: open +Date: 2013-04-02 12:22:30 +Targetversion: future Class: feature -State: done -Date: 2013-01-31 11:18:44 -Targetversion: 1.2.2 -For example, when having several logentries which are sent regularly, like +Added from old ticket system #755912: -SRV-12345 is alive -SRV-52345 is alive -SRV-62345 is alive -SRV-72345 is alive -SRV-82345 is alive +Hi everyone, -The following pattern matches them all: + +just wanted to share my experience i made today while setting up check_mk with Shinken as monitoring core (using OMD 0.56). -SRV-([0-9]{5}) is alive +Credits also go to several bug-reports and forum posts :) -Imagine, we have about 2000 different SRV-* entries in the log and we must -create a regular message expectation rule for each of those single SRV-* -items. + +1. When exporting check_mk's configuration to Nagios, cmk validates the "Nagios"-configuration by using the actual Nagios binary and also expects the config to sit at /omd/sites/sitename/tmp/nagios/nagios.cfg, which does not exist when using Shinken as monitoring core. -Once a number (subpatter) is received for the first time, the expection counter -must start and raise an event for this single number if it has not been received -for about a minute. + +I worked around that by symlinking /omd/sites/sitename/tmp/shinken/shinken-apache.cfg (which is a legacy-Nagios-compatible version of shinken.cfg) to /omd/sites/sitename/tmp/nagios/nagios.cfg. -Loesung: Dies wird ausserhalb der EC geloest durch eine EC-Aktion, die -von einer Regel aufgerufen wird, die auf obigen Text matcht. Diese fuegt -autoamtisch eine neue EC-Regel direkt vor der Generator-Regel ein, die -dann auf den speziellen Host wartet. Danach muss die EC neu geladen werden. -Frage ist, ob das aus einer Aktion heraus sauber geht. Wahrscheinlich ja. + +2. Shinken does not seem to care about check results being submitted as file, since I could see my passive services being created correctly, but never received any result. + +After setting check_submission = 'pipe' in main.mk the check results were processed correctly. -2013-02-12 13:40:26: changed state open -> done -solved. + +My thoughts on these findings are: + +Regarding 1.) Wouldn't it be possible to let OMD decide which core binary to use when doing a config check with check_mk, so that the correct one is being used (and therefore the correct config file is being parsed)? + + +Regarding 2.) check_mk recommends submitting the check results by file for performance and scalability reasons. Do these reasons also apply to the Shinken core? Shinken ignores any settings regarding this, such as check_result_path. + +Would it be possible to set check_submission to pipe automatically when using Shinken instead of Nagios / Icinga? + + +Regards, + +Markus