RE: [Nagios-users] NSClient++ (Early ßeta release)

[Michael Medin]

> -----Original Message-----
> From: nagios-users-admin at lists.sourceforge.net
> [mailto:nagios-users-admin at lists.sourceforge.net] On
> Behalf Of Andreas Ericsson
> Sent: den 16 februari 2005 10:41
> To: nagios-users at lists.sourceforge.net
> Subject: Re: [Nagios-users] NSClient++ (Early ßeta
> release)
> 
> Michael Medin wrote:
> > Hi,
> > 

[snipped, out...]

> >
> > Future plans are (if there is an interest):
> >
> > Modules for:
> >
> > * SSL (need to read up on the subject first).
> >
> 
> It's fairly straightforward. I believe there are win32
> ports of openssl
> (or the likes). Look at SSL-enabled plugins if you're
> curious about
> simple SSL functionality, and openssh if you're
> interested in advanced
> features (PKE and such).
> 

I was considering using W32 APIs to reduce lib dependencies (but I have never used that so I need to look into what's there, also I would like something that doesn't require certificates to use as I found it a bit tedious to manage certificates for all my servers).

> > * Event log (already there but not finished).
> >
> > * Scripting support (would be I think simple to allow
> scripts to be
> > written in some language and executed (much like
> Nagios).
> >
> 
> This would be nice. If it could be made compatible with
> check_nrpe and
> bind both ports if told to support the feature I think
> it would be made
> really useful.

Sounds interesting, someone else pointed this out and I shall have a look at this, if NRPE is similar in structure I think it would be doable.

The internal structure as of now is on the following form:
<command> [<argument1>, <argument2>, ..., <argumentn>]
The command as a string and the arguments as a list of strings.

> 
> > * Passive checking (is this really useful, haven't
> ever used it
> > myself)
> >
> >
> >
> > But the big question is: is there any need for this?
> >
> 
> Perhaps, and perhaps not. I'm a firm believer in
> touching the monitored
> objects as little as possible. It seems an additional
> scheduler running
> on the host can never be a good thing.
> 

Hehe, this was my main issue with the plugin support. A lot of our computers already have SNMP monitoring but need event log. So I didn't want to duplicate the "performace counters" and what not in NSClient++ unless I have to. 
What Im getting at is that the passive checker would be implemented as a module and thus be togglable. 
If I do SSL I will also refactor out the "NSClient socket responder" as a module (or as two modules, one that uses SSL and one that doesn't) and then you can technically have a NSClient++ that does nothing, and uses pretty much no resources at all, well it is windows so 4-5 megs of ram and a few CPU cycles :)
As of now there are five plugins:
1, NSClientCompat (plugin to emulate NSClient)
2, SysTray Module (plugin to display a system tray icon)
3, EventLog module (eventlog polling plugin)
4, Console Logger (used to log to stdout for debug pourpouses)
5, File Logger (used to log to file)
Any and all of them can be disabled making the footprint of NSCLient++ up to the deployer.



[snipped out a bit more ]
> 
> > So is there an interest?
> 
> Definitely. If I knew anything about windows
> programming I would help.

As of now I probably need more "monitoring experience" then Windows programming help :)
So if you or anyone else have ideas on *how* you would *like* things to function let me know :)


[ more snipped out part ]
> >
> 
> I'll get back to you with those as soon as we've got
> anything to report.
> The module API sounds very interesting.
> 

The API is quite simple:
The following functions are available for a module to "export": (think DLL)

NSLoadModule 
- Loading of modules (done when the service starts)
NSGetModuleName
- Used to get a nice name for the module.
NSGetModuleVersion
- Not really used but...
NSHasCommandHandler
- Let the "core" know it can handle commands (from nagios)
NSHasMessageHandler
- Used to let the "core" know it wants to see all log/debug/error messages that are generated.
NSHandleMessage
- Used to digest a log/debug/error message.
NSHandleCommand
- Used to (possibly) digest a command.
When a command is "injected" then command is parsed and then sent along to all plugins (which accept commands) in order (they are listed in NSC.ini) and they are allowed to act on the command. If they do act on the command the "injection" is aborted and the resulting "return string" is returned to the "injecter" (normaly check_nt through a TCP stream. The ordering can thus be used to 1, optimize if things are slow (though I fail to see that unless someone makes some pretty f*cked up modules) and priority if one module overlaps the command of another (though then I would recommend someone to change the plugin command strings :)
NSUnloadModule
- Used to unload and terminate "stuff" nicely. (Generally this is when the service terminates)
NSModuleHelperInit
- Used to send along callbacks to the module (for making calls to the "core". (Ie. To allow the module to inject commands, get versions, names, and settings)

So the API is quite simple and straight forward (I hope :)


To make a simple call graph:

* Service starts:
* For each plugin 
	- call NSLoadModule
	- call NSModuleHelperInit
	- if NSHasCommandHandler
		. Send to "command plugin" stack
	- if NSHasMessageHandler
		. Send to "message plugin" stack
* Wait for socket data
	- Parse socket data
	- For each "command plugin"
		. call NSHandleCommand
		. if Command handled abort

<termination signal sent to service>
* For each plugin
	- NSUnloadModule
* Terminate service

<Log/debug/error message generated in a module>
* On incoming message:
	- For each "message plugin"
		. call NSHandleMessage

There are a few more things to this but overall I have tried to keep things simple.

The extensions (to the API) I'm considering as of now (depending on the fallout) is:
* "SettingsHandler" to allow registry/INI/* settings modules. As the overhead of reg/ini settings system is quite low, perhaps this is overkill. But I don't know: thinking wildly there might be a reason for someone to want to load settings from a central server or whatever :)

* "SocketHandlers" though this will not be a specific handler I have considered to refactor out the code and allow the socket handler (that reads the TCP socket and parses the command) to be a plugin when I do SSL as I assume SSL will come with quite a high overhead and thus I might not need it all the time. 
Also as mentioned this might be a good place to do a NRPE socket parser module to allow compatibility with NRPE. But this I assume is a bit in the future as I need to get "NSClient++" before I can get "NRPEClient++"...

As for PassiveChecks that could be implemented as a plugin today as any plugin can inject commands into the "core". Thus a plugin can be loaded, have a background thread that every X minutes calls "core".injectCommand(); and sends the result over to nagios. (This is how I assume that passive checks work)


Whoooha... long email that I think I will turn into documentation when I get home tonight, hope I haven't bored anyone to death :)

// Michael Medin

> >
> >
> > BTW; I just noticed that the zip file on SF was
> broken (don't really
> > know why) so you have to wait a few hours (we are
> talking something
> > along the lines of 18:00-19:00 GMT when I get home)
> before you can
> > try it. I also noticed that the CVS only had
> directories in it so Ill
> > have to check about that too, my 1337 SourceForge
> skillz are not what
> > they should be I suppose but this is pretty much the
> first time in
> > years I post to SF :)
> >
> >
> >
> > Regards,
> >
> >
> >
> > Michael Medin
> >
> >
> >
> > Direkt: 08-410 052 42
> >
> > Mobil:  0733-35 55 42
> >
> > E-mail: michael.medin at altcom.se
> >
> > Internet: WWW.ALTCOM.SE
> <BLOCKED::http://www.altcom.se/>
> >
> >
> >
> > ALTCOM AB  SEGELBÅTSVÄGEN 2, 11264 STOCKHOLM TELEFON:
> 08-7 300 300
> > FAX: 08-7 300 305 EMAIL: INFO at ALTCOM.SE
> > <BLOCKED::mailto:INFO at ALTCOM.SE>   INTERNET:
> WWW.ALTCOM.SE
> > <BLOCKED::http://www.altcom.se/>
> >
> >
> >
> > This message contains information that may be
> privileged or
> > confidential and is the property of the Altcom AB. It
> is intended
> > only for the person to whom it is addressed. If you
> are not the
> > intended recipient, you are not authorized to read,
> print, retain,
> > copy, disseminate, distribute, or use this message or
> any part
> > thereof. If you receive this message in error, please
> notify me
> > immediately and delete all copies of this message.
> >
> >
> >
> >
> >
> >
> 
> --
> Andreas Ericsson
> andreas.ericsson at op5.se
> OP5 AB                             www.op5.se
> Lead Developer
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products
> from real users.
> Discover which products truly live up to the hype.
> Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> 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



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
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