Badges [ 5 ] [-]
Memberships [ 1 ] [+]
Activity Stream [+]
Ideas Contributed [ 13 ] [+]
HMAC message digests for signing pyro messages. (Pyro is the messageing framework that Shinken runs on). This feature is available starting at Pyro 4.04.
This would be a good first step in securing default Shinken installations.
Create a poller module using the Python OpenOPC library to read VTQ (Value, time quality) tuples from an OPC server. The poller module uses threshold values from the Shinken service definition associated with the data point or tag name.
Store the Shinken configuration in a more strongly typed, hierarchical and standard format. Ex. JSON, YAML. Continu to provide configuration validity checking and human readability.
This obviously breaks the configuration format. So this should only be done when Shinken reaches critical mass, or when conversion utility is available.
I suggest you store the Shinken configuration in a SQL/noSQL back-end database, instead of current flat-files. Any configuration stored in the database should be exportable/importable to and from a strongly typed format files that are still readable. (JSON, YAML, etc.)
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.
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.
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 implement three roles that users can have:
Administrator, user and read-only
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.
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 »
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 »
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.