My impression about Merlin and Ninja
Johannes Dagemark
jd at op5.com
Mon Jul 20 10:19:40 CEST 2009
Hi Mathieu and everyone else interested
Mathieu Gagné wrote:
> Hi all,
>
> Some of us are under the impression that Merlin and Ninja will be the
> new default GUI and NEB module used in Nagios.
>
> I therefore gave a try to both of them this week and I would like to
> share my impression and opinion about those.
>
Very nice :)
After working with Ninja and Merlin for most of this year I have to say
I'm really happy to see that people are interested and actually succeed
to get as far as "working" installations at this early stage.
If anyone want to take a look at Ninja without the hazzle of doing a pre
beta installation we have a system that does a 'yum update' once every
hour, installing rpm's built from the latest commits.
https://beta.op5.com/ninja/
login: monitor
password: monitor
> Lets start with Merlin.
>
> 1) Lack of documentation
>
> There's a serious lack of documentation about the project making it
> difficult for anyone to join and test Merlin.
>
ok,
Current existing project documentation can be found at
http://www.op5.org/community/projects/merlin, there is information,
brief but still information about the project and how you can join and
test Merlin. I'm not saying it's going to be easy, but you're not
completely left alone at least.
> 1.1. We should be explained the terminology used by Merlin
>
> What is a NOC, Poller and Peer? What are they in the big picture and how
> do they interact with each others?
>
>
Have you checked out the README file in the git repo? It should cover
what you're asking for.
> 1.2) We should be provided examples of setup
>
> How can Merlin be configured and used? Clear working examples should be
> provided, including schema and network information (hostname/ip).
>
> Over the years, I tend to be more and more a visual person. The backend
> illustration is nice (http://www.op5.org/community/projects/merlin) but
> not enough for me to understand how can multiple Merlin enabled Nagios
> can interact with each others and what I should be expecting from them.
>
>
I agree with you, we have not come this far yet. Right now the only
thing available is the above mentioned illustration. Now when I think of
it I actually have an old pdf describing a couple of possible setups as
well, I'l try to shape it up and get it published. We also have an
example.conf but I think we should provide a couple of more example
config files just like Nagios Core does.
> 1.3) Configuration propagation
>
> - How is it propagated? Do I have to rsync them? Is it propagated or
> just imported to the database for status aggregation purpose?
>
It's not propagated at all so yes you have to rsync them. It would
though be very nice if this were handled by Merlin in some nice way, I
know I for one would like that.
> - How does Merlin deal with name collisions? Does it assume "localhost"
> from "nagios1" is the same as the one on "nagios2"?
>
>
Since it's not responsible for the "configuration propagation layer" at
this moment it does not handle name collisions either and just assumes
it's the same host.
> All those questions would probably be answered if real life examples
> were provided.
>
yep :)
> 1.4) Nagios instance
>
> Was the NDOutils concept of "nagios instance" dropped? I can see this in
> object_importer.inc.php:
>
> $obj['instance_id'] = 0;
> $obj['instance_name'] = 'Local Nagios/Merlin instance';
>
>
yes, for now at least. If it makes sense in the future we might
reintroduce it.
> 2) Installation process to be improved
>
> The installation process isn't trouble free.
>
> I installed a MySQL server on a remote host. There's unfortunately no
> way to tell the install script to use a remote MySQL server. It assumes
> MySQL is installed on the local host and can authenticate using the
> password-less root account. We should be given a choice and asked
> authentication informations. (host,port,user,pass)
>
I agree
> 3) Using PHP for shell scripts
>
> I used to program PHP for several years in the past. PHP is nice and
> easy to learn. However having to install PHP on a monitoring server just
> so a single shell script can import a Nagios configuration isn't really
> cool. I would prefer Perl or Python which are usually already installed
> on the server.
>
The story behind this was that we had this code in php already and
wanted to get the import program to work fast so that we could start
testing with some real data. I agree that it's not sane to use php for
the reasons you describe. We might change this in the future but it's
not top priority. A patch for this would be very welcome.
> And now with Ninja.
>
> 1) Installation process
>
> The installation process isn't trouble free with Ninja neither.
>
that's because there is no installation process available yet ;) But
kudos to you who succeeded anyway
> 1.1. I installed a MySQL server on a remote host. I can't specify a host
> on which I want to configure the database. I had to execute each part of
> the installation process separately.
>
> 1.2. Error reporting isn't user friendly. I was prompted with this error
> during the installation process:
>
> sh: -c: line 0: syntax error near unexpected token `newline'
> sh: -c: line 0: `/usr/bin/php /usr/local/ninja/index.php
> cli/insert_user_data <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
> Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> '
>
> An error occurred and this script will terminate. Too bad...
>
> It is in fact the first line of a huge backtrace from Kohana telling it
> can't connect to MySQL.
>
> 2) Interface
>
> 2.1) At first glance, the interface is nice. The dashboard and the use
> of widgets is a good idea.
>
thanks
> However the interface is very pale and seriously lacking colors/contrast.
>
> Your answer would be: "Ninja supports themes so improve it yourself".
> While it's a valid answer, it certainly won't satisfy anybody as it
> requires time and expertise which most of us don't have. And I would
> personally consider this answer as a loophole so you don't have to
> review/change the theme to answer most people concerns and needs.
>
> To justify my opinion, let me give you an example. With the current CGI
> interface, when a server is marked as DOWN, we get a WHOLE red line to
> draw our attention. This is great because I know in seconds where to
> look and what is asking my attention.
>
> However, with Ninja, we only get a 16x16 icon which doesn't draw any
> attention. It's even worst when you are showing the interface on a big
> screen in a NOC. Small icons simply don't do the job compared to an
> awesome huge red line.
>
> IMO, state should use background colors instead of icons and commands
> should use icons. (pretty much like Nagios does today)
>
>
Well, I myself is a bit conflicted here. My first reaction was the same
as yours but after a time I have gotten used to the new look and feel.
Some parts I like better with the old gui but most parts I like better
with the new gui. I was hoping for people to give feedback like you are
doing now and it will be very interesting to hear what other people
think also.
The best would be to have a couple of skins available, like "The good
old days", "Ninja style", "High contrast", etc...
> 2.2) State Information and Commands
>
> Both sections are overlapping and some state information are hidden
> because of that.
>
sounds like a bug which will be fixed
>
> 2.3) Typos
>
> I saw some typos here and there.
>
> - "Notification enabled" instead of "Notification disabled"
> - Icon filenames: nofity-disabled.png => notify-disabled.png
> - Etc.
>
Thanks, please if you or anyone find stuff like this, just send a short
description to op5-users at lists.op5.com (have to register first,
http://lists.op5.com/mailman/listinfo/op5-users). Easy to miss and all
help is welcome.
> 2.4) Errors
>
> Anyone got them so far?
>
> session_start() [function.session-start]: ps_files_cleanup_dir:
> opendir(/var/lib/php5) failed: Permission denied (13)
>
> Invalid argument supplied for foreach()
> application/controllers/status.php [675]:
> Status_Controller->group_summary( service, all )
> Status_Controller->servicegroup_summary( )
>
>
yep, and they occur now and then in the pre beta release code. Hope to
release the first beta without any errors like that though.
> 3) Documentation
>
> It should be clearly stated that Nagios needs to be running on the same
> host as Ninja to be able to use commands. Otherwise you will be getting
> those errors:
>
> fopen(/usr/local/nagios/var/rw/nagios.cmd) [function.fopen]: failed to
> open stream: No such file or directory
>
>
agree, will do
> -------------
>
> I hope my message won't discourage you. I guess most of us are curious
> about Merlin and Ninja and have big hopes for them.
>
> I just wanted to give my first impression. :)
>
Thanks Mathieu, as I said earlier, I'm happy that you are showing
interest :) I was a bit put down at some parts of the mail considering
this is very much work in progress ;) but I value your feedback and we
are working hard on Ninja and Merlin to help growing the community of
Nagios users.
Cheers
--
Johannes Dagemark
CTO / VP Engineering
________________________________________
op5 AB
Första Långgatan 19
SE-413 27 Gothenburg
cell: +46 733-70 90 24
fax: +46 31-774 04 32
Email: jd at op5.com
http://www.op5.com/
> --
> Mathieu
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
More information about the Developers
mailing list