NRPE/NSCA replacement thoughts?

[Max]

On Fri, Feb 19, 2010 at 11:19 AM, Flyinvap <flyinvap at orange.fr> wrote:
> Le Fri, 19 Feb 2010 07:47:32 -0800,
> Kevin Keane <subscription at kkeane.com> a écrit :
>
>> With SNMP, there is no way to do that - you basically can't wrap UDP
>> in any way. With NRPE, you can easily implement all kinds of
>> homegrown solutions already: ssh tunnels, HTTPS.
>
> You can use SNMP on TCP. You can even use SNMP on SSH or DTLS [1].
> net-snmp [2] can do that without implementing SSL tunnel or other kind
> of solution. With SNMP v3, you can use authentication and encryption.
>
> I'm not saying SNMP is a good solution but provides all security
> needed.

We have had very good success with SNMP for polling; we are getting
about 2200  hosts and 15000+ active checks per poller, about 80% of
our checks are SNMP-based, 95% of our checks (that is a number from
our performance graphing) return in < 1 sec.

Our SNMP zone is heavily ACL'd and not reachable from outside of our
networks, and yes, security is a very big design question that has to
be answered early and revisited often when using SNMP.  We do not use
SNMP v3 for performance reasons.

I use SNMP v3 for WAN SNMP polling and for small scale projects it
works well and I have never had cracks or breakins through the SNMP
agent (as compared to the many many cracks that have happened on web
hosts with customer sites through PHP miscoding or other web-based
vulns).

The tradeoffs of SNMP vs other protocols

Pros
=====================
* It is a standard, so it does not lock anyone into using
Nagios-specific protocols, in some orgs this is seen as a big
advantage
* It is well supported from a library and code perspective; many ways
to integrate SNMP code into applications
* MIBs give a common language for teams to use to communicate what
checks do.  In larger organizations, this langua franca can make
conversations about monitoring more productive and more productive;
MIBs also provide developer documentation for consumers of SNMP-based
metrics / information.
* It performs well for us in our environment.  Yes, this is
subjective, our performance graphs support my claim in this
environment but I make no claims that this would hold true for every
environment :).

Wes Hardaker, of Sparta, did a study of SNMP performance over UDP vs TCP.

In a well-behaved network SNMP over TCP did better; as the network
quality degraded to more than 40% loss for short messages or ~ 30% for
longer SNMP sessions, UDP actually worked better as a transport as TCP
would give up altogether.  There are many studies that have
conflicting results in this area.

Wes Hardaker - SNMP performance - TCP vs UDP
http://www.ietf.org/proceedings/72/slides/opsarea-2.pdf

SNMP over SSH
http://www.ietf.org/proceedings/67/slides/isms-3.pdf

Cons
=======================================
* Security - have to carefully define network and host-based ACLs
* Security - have to carefully define agent ACLs
* Security - have to keep up with advisories
* Performance - longer SNMP sessions (like pulling process tables or
partition tables ) can time out even on pretty well-behaved networks.
Most agents provde SNMP extensions that move the utilization checking
to the agent side so that a check just retuns cooked utilization
values
* Development time - SNMP-based checks do take longer to create as
there is an explicit contract with MIBs and OIDs that should be
defined to communicate what a check does.  We have an extention
framework for Net-SNMP that make implementing a new SNMP check as easy
as writing a perl module that returns a list or list of lists.
Net-SNMP does have a number of methods that make writing SNMP
extensions easier, but certainly none are as simple as NRPE.

We use SNMP for our 'send a check from anywhere to Nagios' wrapper
script.  We have implemented the nSvcEvent and nHostEvent trap
definitions in this script and we have filter code for the two traps
in SNMPTT; this is a much lighter weight way to send an asynchronous
event to Nagios than it would be to initiate a TCP session for every
fault message with NSCA.  I like NSCA and we use it too, so I am not
knocking it.

Our user audience is a mix of developers and SAs; we find that most
SAs prefer NRPE for simplicity and that our developers are comfortable
with either.  Both communities like our SNMP trap sender wrapper,
which functions as both a CLI script and as a perl module.

I make no claim SNMP is better than NRPE nor NSCA, all 3 are excellent
choices depending on the politics at an organization, security
requirements, and network conditions.

I do get annoyed at people who just throw out that SNMP is not a good
choice without supporting evidence.  it can be a fine choice, it is
the only choice with many HW appliances.

It can be used effectively and securely and it works fine in
conjunction with other protocols.

- Max

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null