Shameless plug aside (that as a small business I understand)....I don't completely agree with you. True - ICMP is lower priority. But with ICMP - you can graph interesting data like response times and per hop latency over time (historical graphing of this could be interesting and show congestion points -- even if ICMP is not prioritized). Stated another way: if I'm consistently loosing ICMP it could be a sign of congestion that I need to do something about. Think like the cool tool called MTR --> http://www.bitwizard.nl/mtr/ --- it shows per-hop latency / response times in real time. Would be great to graph that overtime. Then you could also detect route changes - which matters to me to...
There are some devices you want / care about that do not implement SNMP. A customer I work with - until recently - had a core product from a vendor (4 servers) that they would not implement SNMP on. Using another NMS provider (who allowed discover with PING only) and PING was our easiest way to at least know if we could ping the device. If Ping failed we alerted. It only failed in our case when there was a real problem.
So - from my .02 - having the ability and/or options to discover via ping, ping and snmp, or just snmp (because some devices filter icmp right..) would make Observium more robust and usable.
Finally...if I want to monitor hops from point A to B where I don't have SNMP access...like my MPLS providers hops (which I know I can't see all of them)
Thanks, Kenny
On Tue, Jan 28, 2014 at 9:01 AM, Chris Moody chris@node-nine.com wrote:
Just to chime in my $0.02 here...
ICMP is not a very robust means of "monitoring" a device. The ICMP protocol is often lowest priority in traffic queues on routing equipment and as such will frequently just be discarded during periods of high link utilization or high traffic load. In particular, trying to "monitor" a device across the Internet, your ICMP is really best-effort.
That coupled with the fact that you get absolutely zero metric-data outside of ICMP response time (see previous point) and you're really not buying yourself much data to track.
I can completely understand why observium devs would take the stance of not supporting devices that are only ICMP reachable. There'd be nothing to graph and any alerting could happen at random intervals.
If you really want some 'rough' up/down visibility such as this, I'd suggest standing up a basic Nagios install and simply have it performing the check_host_alive (which is ping based) routine. While this does only check via ICMP, the nagios backend itself has logic enough to re-test upon event should it detect something as problematic before flagging it as 'down' so that you don't trigger alerts for just single packets going missing.
This is definitely not the territory observium operates in - it's busy kicking ass at what it does best. :o)
Cheers, -Chris [shameless plug - Adrien and Johnathon, my company (Node-Nine) specializes in building all sorts of stuff like this, so we would be glad to assist you in meeting your needs]
On 1/28/14 4:40 AM, BERTRAND Adrien [BPCE Assurances] wrote:
Hi all !
I know that I ask about a lot of functionalities ... but you like me for that :-)
So I'll to be as clear as possible (and as "English" as possible ...).
Is it possible to add a new kind of device that is only polled with ping ? The primary goal is to know when distant server (hosted by partners) aren't reachable without asking to have access to their snmp daemon and community ...
I imagine that it can be a huge work because it needs to bypass a lot of code but you could have think about it ... ? To be simple for everyone, this kind of device can be a new sort of server but without any snmp information (no device panel / no ports panel, etc...) and just be polled by the ping. And when a hosts is down the alerter send a mail / trap and the index.php put an information box to warn on "device down" like any others hosts.
Sincerely,
Adrien Bertrand - Information Security Administrator
BPCE Assurances, 88 av de France 75013 Paris
observium mailing listobservium@observium.orghttp://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium