Project Overview
- Project Name: Argus / Dashboard
- Purpose: We are currently in the process of redeveloping our alert aggregator and are seeking information as you have a similar product that is open source.
- Required Delivery Schedule: Prototype Release Candidate in place for side-by-side acceptance testing in OC in Q3 2024. Final release, decommissioning of legacy dashboard in Q4 2024.
Existing Product Overview
Product name: Dashboard
Years in service : 10+
Purpose: Aggregation of Alarms
Detailed description : We currently have a Java based application that aggregates alarms from different services. It has some custom features as required by the NOC/SOC and first line support team.
Key features and specifications : Alarm States, Correlation and coalescing of alarms, Blacklisting, Filtering, Connections to other API's
Features required in the system
We have looked at our system vs the Argus system and completed an internal Gap Analysis. From this we have some questions for the Argus development team on whether specific feature requests are feasible. These are the minimum requirements and non negotiables as required by the consumers of the system. These features will probably require more discussion to be properly understood.
Feature/Functionality | Gap Identified | Feedback/Comments |
Alarm Lifecycle | Our alert states are more complex. We have at least 5 states of which 4 are represented by the GUI. By means of flashing or different colours/tints. |
|
Multiple stages of Ack | We have first and second line support and their acknowledgements are represented in the GUI. |
|
Correlation | The initial info for a particular alarm will change over time (during the Alarm Lifecycle). For example, multiple alarms that are immediately reported could be “squashed” into a single alarm after a few seconds. |
|
Coalescing | Multiple instances of an identical alarm need to be “merged” in the gui. But with an indication that this has happened, and how often. |
|
Status of integrations | Possibility of integrating a callback system for monitoring the status of related services? Either this or plugin support? |
|
Priority | Severity and priority are different things. We have a priority numbering and it is utilised by 1st and 2nd line support. |
|
History + Search | We need to keep all alarms that have ever happened to provide reporting for other services on availability and utilisation of service. This is at the level of alarm “component”. |
|
Alarm logical post-processing rules | The OC can specify logical rules and change the characteristics of alarms. For example, if an alarm description contains particular keywords, or is related to a particular location, then the gui severity can be changed, comments added, or perhaps hidden. |
|
Filtering | Complex filtering. Filter groups AND / NOT |
|
Alarm internal details | Our OC requires that the internal components of an alarm are easily-browsable from the gui. For example: if an optical cut causes multiple IP circuit and BGP peering failures, OC must be able to “open” these details (e.g. hostnames, ports, start/end times, etc.) by clicking on the alarm in the top-level alarm row. |
|
Please provide feedback on the above technical requirements and if it would be reasonable to add these features to your development plan for the coming year.
Technical requirements
- Compatibility with existing systems (TODO - list current API calls (i.e. for ticket generation))
- Follow ITIL standards where possible in naming conventions etc
- Developed within the technical stack we have discussed
Support and Maintenance
If security issues become apparent within the system what is the response time that can be expected to patch such issues?
What is the predicted upgrade path for future versions?
If new features are requested after the key features are complete will this be possible?
Delivery and Implementation
We would require this to be developed through 2024 with continuous delivery so we can A/B test against the existing product as well as build integrations and setup of server infrastructure.
The key features would need to be delivered within the current year.
Use Cases