Hi Andrea, the macros should also be available inside Icinga. From the logfile i see that these error message only pop-up if you have a host event. And on a host event there are no macros available what belong to services. That's right. The problem could be that Icinga give back something for the macros not found. This will lead to a problem with the command "cmk --notify" what is called from the core as notification command. In the end every notification from your system results in a service notification.
br Andreas 2014-07-31 12:47 GMT+02:00 Andrea Corazzari <[email protected]>: > Hi All, > finally I solved this issue. > First on a little slave site I change core from Icinga to Nagios, then > after few hours I saw that's working fine and nagios.log was clean > of above errors. > So I made an OVA of master site and repeat the operations, logfile is > clean and mail are always with right body. > > I find strange to be the only one encountering this issue, moreover: if I > didn't any mistake during installation (omd create...) i an > icinga/check_mk problem? > I didn't find documentation regarding best combinations and I'm wondering > why is possible use icinga but are necessary nagios macro. > > Regards > Andrea > > > Il Martedì 29 Luglio 2014 17:34, Andrea Corazzari <[email protected]> > ha scritto: > > > Hi Andreas, hi list, > notifications are generated from the standard Check_MK template, all is at > default value except subject where was asked me to cut the Check_MK prefix. > > A very important (IMHO) thing is in dir /opt/omd/sites/master/var/nagios/ > file icinga.log (I use icinga as core) where, tanks to your hint I found a > lot of entry like following ones. > > I "grepped" config direcories without find any of these macro. > I didn't anything by hand (except a couple of timeout in tuning.cfg) so I > can't figure out why something are trying to use them. > Are only for installation with Nagios as core? > If so running a omd config changing core will destroy all configurations? > This is an option tha I can't stand. > My IT manager will make me work on sunday an on holyday w/out paying me.... > > Thanks again and also in advance. > Andrea > > > [1406646946] SERVICE FLAPPING ALERT: firewall.arx.cedis;Check_MK;STOPPED; > Service appears to have stopped flapping (3.8% change < 5.0% threshold) > [1406647035] HOST ALERT: firewall.capri.cedis;UP;HARD;1;OK - > 192.168.185.251: rta 325.641ms, lost 0% > [1406647035] Warning: Error grabbing macro 'SERVICENOTIFICATIONNUMBER' > value ''! Maybe used in the wrong scope? Check the docs. > [1406647035] Warning: Skipping unknown macro > '$SERVICENOTIFICATIONNUMBER$', removing it from output! Fix your config, or > set keep_unknown_macros accordingly... > [1406647035] Warning: Error grabbing macro 'SERVICEPROBLEMID' value ''! > Maybe used in the wrong scope? Check the docs. > [1406647035] Warning: Skipping unknown macro '$SERVICEPROBLEMID$', > removing it from output! Fix your config, or set keep_unknown_macros > accordingly... > [1406647035] Warning: Error grabbing macro 'SERVICEDESC' value ''! Maybe > used in the wrong scope? Check the docs. > [1406647035] Warning: Skipping unknown macro '$SERVICEDESC$', removing it > from output! Fix your config, or set keep_unknown_macros accordingly... > [1406647035] Warning: Error grabbing macro 'LASTSERVICESTATE' value ''! > Maybe used in the wrong scope? Check the docs. > [1406647035] Warning: Skipping unknown macro '$LASTSERVICESTATE$', > removing it from output! Fix your config, or set keep_unknown_macros > accordingly... > [1406647035] Warning: Error grabbing macro 'LASTSERVICESTATECHANGE' value > ''! Maybe used in the wrong scope? Check the docs. > [1406647035] Warning: Skipping unknown macro '$LASTSERVICESTATECHANGE$', > removing it from output! Fix your config, or set keep_unknown_macros > accordingly... > [1406647035] Warning: Error grabbing macro 'SERVICESTATE' value ''! Maybe > used in the wrong scope? Check the docs. > [1406647035] Warning: Skipping unknown macro '$SERVICESTATE$', removing it > from output! Fix your config, or set keep_unknown_macros accordingly... > [1406647035] Warning: Error grabbing macro 'SERVICESTATEID' value ''! > Maybe used in the wrong scope? Check the docs. > [1406647035] Warning: Skipping unknown macro '$SERVICESTATEID$', removing > it from output! Fix your config, or set keep_unknown_macros accordingly... > [1406647035] Warning: Error grabbing macro 'SERVICEOUTPUT' value ''! Maybe > used in the wrong scope? Check the docs. > [1406647035] Warning: Skipping unknown macro '$SERVICEOUTPUT$', removing > it from output! Fix your config, or set keep_unknown_macros accordingly... > [1406647035] Warning: Error grabbing macro 'LONGSERVICEOUTPUT' value ''! > Maybe used in the wrong scope? Check the docs. > [1406647035] Warning: Skipping unknown macro '$LONGSERVICEOUTPUT$', > removing it from output! Fix your config, or set keep_unknown_macros > accordingly... > [1406647035] Warning: Error grabbing macro 'SERVICEPERFDATA' value ''! > Maybe used in the wrong scope? Check the docs. > [1406647035] Warning: Skipping unknown macro '$SERVICEPERFDATA$', removing > it from output! Fix your config, or set keep_unknown_macros accordingly... > [1406647035] Warning: Error grabbing macro 'SERVICECHECKCOMMAND' value ''! > Maybe used in the wrong scope? Check the docs. > [1406647035] Warning: Skipping unknown macro '$SERVICECHECKCOMMAND$', > removing it from output! Fix your config, or set keep_unknown_macros > accordingly... > [ > > > Il Sabato 26 Luglio 2014 14:17, Andreas Döhler < > [email protected]> ha scritto: > > > Hi, what is more important at this situation is the logfile from your > monitoring core. (nagios.log) > Can you post the line when such an notification is generated. > Other point is how do you generate the notifications? With a script build > from yourself or do you use the CMK included standard mail template? > > br > Andreas > > One important point would > > Am Freitag, 25. Juli 2014 schrieb Andrea Corazzari : > > Hi, > curious... I've been only network admin for ten years, now I'm (?) > sysadmin also. > Anyway last test revealed the same behaviour on a server (so widows agent) > just addedd like other ones. > Next week the hunt will continue... unless someone very skilled > (Marcel??? I believe you're under pressure for omd 1.20) turn the light on. > In a few word: please, somebodi help me! > > Regards > AC > > > Il Venerdì 25 Luglio 2014 17:00, Jaroslaw Nowak <[email protected]> ha > scritto: > > > That example was just for the sake of explanation, not actually for you > to try out. Me, being a networking Guy, would use an ACL on our Cisco ASA > to try that out. > Anyway, you're right about ping check not showing up in service list, but > they are done and show up if they fail. Bad me, not verifying that, but a > device should be only tagged as down when all services on it failed, yes > that's the core of my assay. > I might be wrong regarding ping as service which might be essential for > host up/down events. But you got the point about the difference of both > notifications which is what i wanted to achive :). Just swap blocking ping > with blocking snmp for your testing (yes iptables is a good idea, but be > careful ; ), it should work as intended. I'll verify that ping "test" > later :). > n1 weekend either. > Fate > Am 25.07.2014 16:07 schrieb "Andrea Corazzari" <[email protected]>: > > Hi Jaroslav, > I agree and I say thank to you for this starting point. > But what do you mean with blocking ICMP packets to an SNMP monired device? > Check_MK pings every type of hosts (with monitoring configured vi agent, > snmp, ecc. ecc.) and Ping never appear as a service except for ping only > host. So I can't figure out how to to what you say in Check_MK, I could use > an iptables rule... > Moreover if an SNMP device dosn't respond to ICMP is declared down, > regardless if is responding to SNMP, but this should be the core of the > test, right? > > Thanks and have a nice weekend > AC > > > Il Venerdì 25 Luglio 2014 10:43, Jaroslaw Nowak <[email protected]> ha > scritto: > > > Well, this looks pretty valid (if I'm not getting it wrong) . The first > mails are service notifications the second one's are host notifications. > You should get em both, because nagios makes a difference between host and > service event's. Taking a ping only device, it maybe does not make much > sense b/c its clear that, when a device is not pingable, it must be down. > But when you change your perspective to a service oriented view : take your > firewall, configure snmp monitoring and finally block all icmp(ping) > packets. You will see then an service notification for ping, but you wont > get an host notification b/c its yet reachable via snmp. When you then turn > it off, you'll get both a service event stating that the service went down > and a host down notification (like the second one's). > W/ regards > Fate > Am 25.07.2014 10:02 schrieb "Andrea Corazzari" <[email protected]>: > > Hi Jaroslav, Hi List, > > You're right talking about pinpont for troubleshooting, but I didn't have > any and I hoped someone else had same problem and solved it > even if a deep google searching didn't helped. > > Now I can't repeat a scrathc installation (today i'll finishs this one > scratch installation). > > This morning I noticed a behaviour that maybe could help, but before I can > say that all hosts are DNS entry, all where configured via WATO and > notification email settings are at default value exept for subject where I > "cut" Check_MK: prefix. > > > > > > Il Giovedì 24 Luglio 2014 22:15, Jaroslaw Nowak <[email protected]> ha > scritto: > > > Looking to the posted mail, ignoring the abc.def it looks like a pretty > valid host down/unreachable event you have been notified about coming from > a ping only host. Does that host show up as down in the dashboard? > > Yes, also in Events of last 4 hours > > Did you maybe opt/in "generate random data". those are just blind > guesses, not very helpful, but if the least is not the case, barely anyone > will find the error w/o looking in your config i fear. > > I don't think so, because I don't know that option and moreover it's > meaning. > Could you tell me where could I find it and check in WATO? > > Below an example about the same host with two different behaviour, is a > ping only host and I configured wia wato filling hostname field and nothing > else (ping only type is a rule regarding the whole foleder containing it) > exept clicking "saving and go to services". > Should I click "save and finish" instead? > > Here the four emails > > Correct ones > > Host: vpn3 > Alias: vpn3 > Address: 192.168.160.251 > Service: PING > State: CRITICAL -> CRITICAL (PROBLEM) > Command: check-mk-ping! > Output: CRITICAL - 192.168.160.251: rta 1021.263ms, lost 0% > Perfdata: rta=1021.263ms;200.000;500.000;0; pl=0%;40;80;; > rtmax=1062.833ms;;;; rtmin=977.549ms;;;; > > > > Host: vpn3 > Alias: vpn3 > Address: 192.168.160.251 > Service: PING > State: CRITICAL -> OK (RECOVERY) > Command: check-mk-ping! > Output: OK - 192.168.160.251: rta 110.335ms, lost 0% > Perfdata: rta=110.335ms;200.000;500.000;0; pl=0%;40;80;; > rtmax=113.304ms;;;; rtmin=107.934ms;;;; > > > Wrong ones > > Host: vpn3 > Alias: vpn3 > Address: 192.168.160.251 > Service: > State: -> (PROBLEM) > Command: > Output: > Perfdata: > > Host: vpn3 > Alias: vpn3 > Address: 192.168.160.251 > Service: > State: -> (RECOVERY) > Command: > Output: > Perfdata: > > Is the same host, so the configurations could not be different. > This leave me speechless. > > Thanks for the answer and thanks in advance for any hint. > > Andrea > > > > > > > > > >
_______________________________________________ omd-users mailing list [email protected] http://lists.mathias-kettner.de/mailman/listinfo/omd-users
