Well, after using monarch for a few hours, I have some good feedback to give...
First of all, sorting IP addresses is a numeric thing. You are doing alpha sorts on numeric data. That is wrong! For example these hosts:
192.168.1.1
192.168.1.12
192.168.1.19
192.168.1.65
192.168.1.101
192.168.1.121
192.168.1.129
192.168.1.130
192.168.1.140
192.168.1.1, 192.168.1.65 and 192.168.1.129 are all default routes on the top of 3 subnet's.
Organizing these is difficult when a "sort" gives alpha results:
192.168.1.1
192.168.1.101
192.168.1.12
192.168.1.121
192.168.1.129
192.168.1.130
192.168.1.140
192.168.1.19
192.168.1.65
This is not very well sorted.
Second, when defining dependencies, it would be nice to be able to define them using grouped hierarchies. For example, if I have a subnet with 120 hosts, and one router, I should be able to select the one router, and all 120 hosts, and define the 120 hosts as dependant on the one router using a single page submit. Instead monarch requires me to select each host one at a time, to define what it is dependant on. So instead of doing this with one quick screen, I must use 120 screens to do it. It is much faster to edit the nagios config files with vi, or to write a script to construct the file by hand, than it is to use monarch.
Monarch is a great start at a tool for inserting objects into nagios! It shows great promise... However it needs to learn to sort, and to group dependants before it is ready for a busy admin with hundreds of hosts to monitor.
I am a real-world user. My application is an ISP network, and I have thousands of users to monitor. Your tools help in some ways, and hurt in others.
How I must use monarch is that I can use the web page to create the base config files, where bulk operations are supported. When a bulk operation is not properly supported, I must use monarch to create the first example of a set, and then edit the file by hand to create the rest of the set.
So I /will/ use monarch... But only as a example file generator, I still get more mileage out of using vi.
Also, I ran an apt-get upgrade, 48 or so packages upgraded, but 176 were held back. After the upgrade, nagios won't run. I'm doing a dselect-upgrade next to see if it will fix it... But unless nagios works when I'm done, your appliance cannot be properly maintained without a lot of additional support.
I would suggest that you switch to ubuntu LTS, which has a 5 year self-life, and that you create a plan for managing support issues that occur when updates are applied. A apt package that fixes nagios should ride along with the system, and every time nagios breaks, you should script up a fix, and release it as an apt update to the "fix package" so that running apt-get works as it should. Of course this means you will need to add your update server to the apt sources.list file. And for that matter, the sources.list file should be shipped in a correctly working config, rather than asking for a cd we don't have.
I think you have done some great preliminary work on monarch, and it is a useful tool in taming nagios... But there is plenty of room for improvement.
This is not a package that can, by itself, be dropped into a large real-world network. It does not scale well, it can't handle dependencies in a scalar manner. I will use it to make a quick-start config, then I will spend hours editing the files by hand to fix them.
I will continue to evaluate it and hope that I am wrong about the things I have found to be negative... and I will update this post accordingly.
But between not running on a unix VMware server, and not being scalable, it is an alpha-level product... not ready to be called beta. I understand you have "enterprise" tools... but I am not even interested in looking at them after seeing what monarch won't do for me. You must impress me with a commercial grade version of monarch, to entice me to want to dig into your enterprise offerings.
So I /will/ use monarch... sorta...
