What would be the recommended approach to have the ability to report on elements that have already been deleted from DM or table records that have been removed from a table?
After some discussions we have come up with 2 possibilities, but we are looking for a greater exposure to the use case.
Report on Deleted Table Records
- Protocol level: We could implement a mechanism to not delete the table records for x amount of time (similar to DVE handling)
- This option, while easy to implement, imposes countless possibilities of things that could go wrong and we end up losing the data stored in the table. It also adds complexity to the handling of data within a protocol, which should be focused on polling performance instead
- Software feature to be able to report on deleted entries from within the specified data retention range (RT, AVG 5 mins, etc)
- This could be an option in the new reports and dashboards module, via which we could be able to report on table records (trended) that are no longer there but that are still within the data retention period
Report on Deleted Element (decommissioned device or platform)
- The easy approach is to advise that the element is not removed and in combination with the Report on Deleted Table Records features we could provide the functionality
- The one drawback we see here is that customers would have to keep the elements within the system for reporting purposes only
- Software feature to run reports on deleted elements and element records that fall within the configured data retention configuration
Your ideas and insights are appreciated.
Thank you,
Rene,
First, let me explain the difference in database:
- MySQL:
- Performance data (trend)
- when an element is deleted, the performance data is deleted as well. (data_x and dataavg_x) tables.
- when a row is deleted, the performance data fades out
- Fault data (alarms)
- faded out
- Performance data (trend)
- Cassandra (single node and cluster)
- Both performance and fault data is always faded out
This means that when it concerns data that fades out, that all the information is still available in the database.
What information is reachable:
- Performance data is accessible in DataMiner Cube for metrics where the trending has been disabled after a while. You can drill down on the parameter, and in the trending tab hit 'Load' to see the data which is still available in the database.
- Fault data is also still visible in DataMiner Cube even if your element or row was removed from the system. (Alarm history query)
- There is an alarm-list component in soft launch in dashboards. This component also has the possibility to do a history query, and shows alarms from deleted rows and elements.
Now, for your use-case, how do you want to access this information? As the biggest problem will probably be which queries to execute.
Hope this helps you further.
Jan – Thanks for your response. The use case is simple: Ability to use the dashboards to report on KPIs (trended parameters), even after an element has been removed or an entry from a table has been deleted.
The most simple approach seems to be the integration of a setting on a specific set of dashboard components that allow for the inclusion of deleted elements or table entries.
The time for which deleted elements/ table entries would remain in the Database could be incorporated alongside the existing settings towards data retention.
The same applies for Alarms but as you mentioned, the alarm component in dashboards seems to already cover the capability.
Thank you,
Could it be possible to expand the use case(s) under which such reporting is required?