Some hosts today have more then one interface, and the common way to monitor these would be to create a host object for EACH interface based on the fact that each interface has it's own address.

What about making it possible to give several adresses to each host, so it all appears in the same host object?
It would require some logic regarding what check to run on what interface, but it can be solved!

At the moment the Status Map seems to be using only 600 x 600 pixels on the screen. If you have a high resolution you could display more data.

I was really impressed by the speed and opportuninties of the mk_livestatus eventbroker module.

What do you think about using it for communication bewteen the new icinga-web an icinga-core?

Downtimes on a regular basis; compare: maintenance_downtime in shinken; compare: Plugin used in Nagios: downtime_sched by Steve Shipway

http://ideas.nagios.org/a/dtd/Cluster-objects/18903-3955

The current set of objects is too limited to keep the number of host and service groups manageable. While we can't override the host/service information links in any practical manner to fake deeper tree structures, the benefits of using check_cluster plugin are debatable. (Check on clustered service - you can see that there is a problem, but what does the cluster consist of?)

I would really like to see a possibility to create these objects: host_cluster, service_cluster. Otherwise as host/service objects, but consisting of host or service members and rules on when to switch states.

I love the Statusmap of new Icinga Web. But there is a extension that would be really great.
In our IT Department we print the Statusmap and put it on the wall for meetings.
So untill now i used Nagvis and made a screenshot put it into an image, changing the descriptions and so on.
This is a lot of work i have to do every month.
It would be a lot easier if i could click on an Button and i could download a whole Statusmap of the new Icinga Web (png,jpg,pdf or whatever).

Icinga is just awesome ... My company want to start a project with your software but, we need a real distributed architecture with multiple Icinga servers and MySQL DB which replicate them self to a head servers but no Icinga architecture enable this. Unfortunately, we move to Zabbix because its Zabbix Server/Zabbix Proxy meets our needs.
I suggest to the dev team to developp a distributed architecture like Zabbix. In my opinion if you create this, Icinga will be the first one entreprise monitoring software.
Best regards.

To open a wide area of future possible applications to monitor, a flexible definitions of status codes and colors would be great.
Why don't use 0 to 9 as possible code ? If nothing is defined, predefined settings could avoid problems during upgrades.
Sample config could be:
host_status0=OK
host_status0_color=#FF5577
...
host_status9=Started
host_status9_color=#565777

and the same for service status codes ...

With this, it would be possible to adjust the Icinga to the required purpose.

I believe that wider spread adoption will benefit from having Icinga included in these packages. There are others out there as well.

In a master/slave redundancy setup, I'd like to pass acknowledgements and downtimes to the other host automatically.

It would be nice if a host can depend on a service. This Feature would fix several Problems like VPN and VLAN. At this moment its only possible by using a hostdefinition for one of this Service. In a big statusmap with many VPN Tunnels and some VLAN's its very unorganised and confusing.

Different monitoring system users like to receive, and view, different information. In an ideal world, a user would be able to choose which hosts/services, or even host/service groups to receive notifications from. Imagine a case where a user of a massive implementation (something my company is looking at...) is a systems specialist and is interested in getting notifications from the systems/areas that they're actively interested in. Essentially, my suggestion is that users should be able to 'sign up' for notifications against given hosts/etc.

icinga-web should handle more than one datasources, so you can have autonomic icinga installations and one webinterface for an overlook over them all.

I'd like to hear that oneday you support Nginx.....

I like a plugin to simple integration of the API of Amazon Web Services. We just add one or more AWS accounts and so we can monitor through AWS API the status and the performance

From my work with Icinga the release interval of 90 days is to fast. In a enterprise environment it is very difficult to update the installation all 90 days. Further I can also imagine that for the development team a higher interval rate could maybe make life a little bit easier.

If I remeber correctly I saw once a presentation from the Icinga Team with a roadmap where each second release should be a beta release. From documentation and each release I don't see that concept.

My suggestion would be a release interval of 180 days instead of 90 days.

http://ideas.nagios.org/a/dtd/Grouping-notifications/20743-3955

Would be nice if a host has multiple service problems, that the notifications will be grouped. Guess the first occurrence of a problem must be alarmed as a single notification and afterward only collected and grouped notification should be send out.

Icinga Web is missing the System->Process Information page which is available in the classic GUI. This is especially important if you would like to disable notifications and/or restart the Icinga process.