A UI is a real time sink and constant source of bug fixing. There are great UIs that plug into the NEBs, concentrate on the core functionality which was the reason for the fork. There is still a lot of interesting work that can be done in the core.
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
Once the user hits enter,... more »
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 »
Show recent alerts on a dashboard, timebase sorting.
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.
Got an object that will be able to "match" things like :
* string in output
* values in parfdata
and so raise status or actions.
A bit like Zabbix triggers.
I would suggest having user profiles that are stored across sessions. This user profile can have a default setting and also remember things like: Dashboard entity groups selections, list of links in main dashboard.
Roles should be assigned to users.
I suggest you implement three roles that users can have:
Administrator, user and read-only
I suggest exposing some configuration items to be modified via the WebUI.
- Correlation rules
- WebUI session options
- Hosts and their properties
- Services and their properties
Any changes need to be checked for validity prior to commiting to the configuration.
Any changes done to the configuration need to be consigned to an audit log.
I suggest you call upon all Shinken developers and users to find+submit and fix+validate all possible bugs prior to a release date.
The one who fixes the most bugs gets a recognition prize.
The one who submits the most accurate and numerous bug reports also gets a prize.