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
