as stated before.. Am 01.08.2014 08:39 schrieb "Andreas Döhler" <[email protected]>:
> 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 > >
_______________________________________________ omd-users mailing list [email protected] http://lists.mathias-kettner.de/mailman/listinfo/omd-users
