<div dir="ltr">As a small operator, we mainly use Icinga for the reasons Chuck mentioned.<div><br></div><div>The API allows us to do updates based on configuration parameters we've created in a custom MySQL database. <br><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br><div>Peter</div><div><br></div><div>Peter Harrison </div><div>CTO, Colovore LLC</div></div></div></div>
<br><div class="gmail_quote">On Wed, Aug 15, 2018 at 9:19 AM, Chuck Anderson <span dir="ltr"><<a href="mailto:cra@wpi.edu" target="_blank">cra@wpi.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Aug 15, 2018 at 08:49:12AM -0500, Colton Conor wrote:<br>
> We are looking for a new network monitoring system. Since there are so many<br>
> operators on this list, I would like to know which NMS do you use and why?<br>
> Is there one that you really like, and others that you hate?<br>
> <br>
> For free options (opensouce), LibreNMS and NetXMS come highly recommended<br>
> by many wireless ISPs on low budgets. However, I am not sure the commercial<br>
> options available nor their price points.<br>
<br>
For monitoring network device/interface data plane reachability with<br>
ping, we are still using an ancient piece of open source software<br>
called Autostatus.  I find it invaluable for notifying us about<br>
reachability issues with it's simple to understand parent/child<br>
relationships and graph-based fping methodology.  It isn't perfect--it<br>
doesn't scale very well, it doesn't have HA/clustering, it has no<br>
fancy dependencies (just basic parent-child) and no event correlation,<br>
no contact scheduling, no API, etc. but it is very easy to understand<br>
why you are getting an alert or not and boiling that down to a single<br>
point of failure and as such it provides reliable, trustable<br>
information about data plane reachability from one vantage point on<br>
the network.<br>
<br>
For monitoring server & network service availability,<br>
device/environmental health, etc. we are currently using Nagios.  My<br>
problems with it are that it has complex rules for how/when to perform<br>
a specific health check and send or suppress a notification (and<br>
perhaps bugs in our old version that never ever seems to send any Host<br>
notifications except when it does) and the whole idea of "suppress the<br>
Host check unless all Service checks for all services on the host are<br>
down" doesn't really fit well with the idea of monitoring<br>
device/interface reachability on routers & switches that make up a<br>
complex graph of dependencies.  Trying to shoehorn Nagios into<br>
alerting on just the one IP address/device/interface that is causing<br>
all the others behind it to be unreachable doesn't work very well.<br>
You can't use Host Depenencies because Host checks are suppressed by<br>
default, and Host Dependencies don't affect Service<br>
Checks/notifications.  Forcing Host checks to always run causes<br>
performance problems.  Creating a "Ping" service for every host<br>
requires creating manual Service Dependencies between all the "Ping"<br>
services on every Host.  Then you end up with a complex configuration<br>
that is very hard to understand.  But for things like telling you when<br>
a power supply or fan has died, or if the web service crashed, it<br>
works well.<br>
<br>
We did a survey of a bunch of open source tools to replace Nagios and<br>
have settled on Icinga for it's APIs, dynamic rules with pattern<br>
matching and boolean logic, and compatibility with Nagios plugins.<br>
But it still doesn't change the basic architectural choices of the<br>
Nagios core engine and hence isn't a good fit for network<br>
device/interface reachability monitoring IMO.<br>
</blockquote></div><br></div></div></div>