I suggest you to translate your software. If you need a French translator, I'm here.
When we acknowledge an alarm, we acknowledge the alarm status.
Warning on a disk => acknowledge
Warning on a second disk => the message change but not the status => the acknowledge isn't removed.
It would be great if there is a "soft" acknowledge which is removed in case of status change OR message change.
Creating KPIs requires a calculation module, that accesses incoming performance data and applies mathematical formulas to create composite data points. Livestatus provides methods for doing sums, averages, but is not really meant to create new data points. Typically performance or state data is received from plugins. This data is captured through Livestatus, the calculation module applies a real time formula and sends ...more »
This is a complete replacement for Nagios GUI
It is much more event-oriented, which Nagios lacks.
It includes perfdata graphing
this should be no big deal
Provide a simple input box for filtering displayed data based on a google search type. As each character is input, the visual output is modified, or at a minimum a dropdown/floating list of matches is displayed. This list would be purely informational and limited in size. Limit the floating list to 15 matches and add a wildcard at the end to indicate there are more matches than can be displayed. Once the user hits enter, ...more »
In the UI it can be good to have different "group of things" that can be good to display and aggregate. Some will want to show some geographic dispatch, other want a technical view, other business elements. So with the entities, we can have : * realm and poller_tag : geographic separation * hostgroups/servicegroups : technical ones * template : technical one too So in a dashboard, the user can choose between "entities" ...more »
Can be good to have a in the dashboard a view that show alerts by users:
* what they can manage (contacts)
* the one they already acks
It can be cool for a dashboard view to show a past volume problems/impacts for each "entity", so a manager can see where there was big problems.
Show maintenance periods can hemp admins to see what the others have planned.
The problems page should be able to aggregate some similar alerts in one element instead of N similar ones.
I suggest you implement three roles that users can have:
Administrator, user and read-only
I suggest you implement an audit log for all webUI events of interest:
- configuration changes
- comments created
This would be in addition to the Shinken general logs.