The Nagios: Reloaded (Rewriting Nagios)

[Greg Fenton]

--- Jeff Rodriguez <nagios-users at gurugeek.com> wrote:
> I'm working on rewriting Nagios in C# and I'm looking for input as to
> what people would like to see in Nagios if it was rewritten from the 
> ground up.

First, why would you target C# instead of, say, Java?  At least Java
has a current production release on all platforms that Nagios
targets...and on a number of platforms where C# isn't and likely won't
be for quite some time.


> Features I intend to add:
> 
>     * Rewrite in C# for all the reasons one would use a managed
>       language, Linux boxen will use Mono of course!

I don't completely know what "all the reasons" are.  Nagios is a
systems-level application.  Systems code should be written in a
close-to-the-hardware language.  I would not want an OS written in .NET
nor Java (sorry to all the BlueBerry users out there...)

And the fact that it is written in C should only be a concern to you if
you are actually making modifications to the product.  What changes
have you been working on where C has been the "wrong" language to be
using?


>     * Design Nagios to be distributed from the get-go.

I'd need to get a better description as to what you mean by this.


>     * Use XML files for main configuration to ease the creation of
>       configuration tools.

This, to me, is a red-herring.  However, why not simply enhance Nagios
to recognize both the "legacy" and your "new" formats?


>     * Use a SQLite database back end for object configuration
>     * Use a SQLite database for user access configuration

I don't get this.  You mention using C# for "all the reasons ...", but
then you target a particular backend data repository???  Why would you
not make it datastore agnostic?


>     * Portability through C# and our friends at Mono

I'd want to see a fairly lengthy list of the classes you are planning
on using to ensure that they are available to "all" of the .NET
platforms...all 2 of them.


>     * Create web services for getting the status of services and
>       allowing services to report in.

There is nothing stopping this from being done with the current
architecture.  In fact, you could even write this enhancement in
.NET...or use something that wouldn't involve having to install an
entire platform just to support an HTTP/XML request (smells like a Job
For Perl to me!)


>     * Multi-threaded to simplify program code and speed the program
> up
>       on multi-processor systems.

Multi-threaded does ABSOLUTELY NOT simplify anything.  Regardless of
the programming environment.  And multi-threaded does not in and of
itself make a program more suitable/scalable in an SMP enviroment.

>     * Integrate RRDtool for performance reporting without need for a
>       plug in.

I'd want more details on this.

>     * More well-defined reporting tools.

Again, I don't see how this can't be accomplished with the current
architecture.

> I will also be releasing it under a new 
> name which I am working on getting domains and possibly a trademark
> for.

You are already thinking non-Free, so good luck to you.

greg_fenton.

=====
Greg Fenton
greg_fenton at yahoo.com


		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
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