Hi All,
Is there a way to stop certain alarms being written to the time trace table?
We have an alarm on multiple devices that when triggered can lead to over 4000 alarms and happens multiple times a day, making the timetrace table horrifically large.
In an ideal world, we wouldnt write these to the timetrace table to keep the table at a good size.
If this isnt possible, what would be the best way of coming up with a solution for this?
Does Alarm Grouping still write each individual alarm to the timetrace table?
Hi Ryan,
I'm afraid there's no such way. By design, all generated alarms have entries stored in the timetrace table, and the same applies to Information Events in the infotrace table.
The data stored in these tables allows us to search for alarms based on time — for example, when looking up alarm history in the Alarm Console. The alarm and activealarm tables, on the other hand, do not include time in their partitioning keys (only the alarm ID or DMA/Element IDs), which makes time-based searching in those tables practically impossible. That's precisely why the timetrace and infotrace tables are needed as auxiliary structures.
So, the core issue here seems to be the high number of toggling alarms. Having 4,000 alarms toggling multiple times per day is far from ideal and, in my view, is the main problem to address. It might be worth reviewing and adjusting the alarm templates — perhaps by adding hysteresis on/off thresholds to avoid repeatedly triggering new alarms for minor fluctuations.
"Does Alarm Grouping still write each individual alarm to the timetrace table?"
Yes, I believe it does.
You might also consider migrating the local Cassandra database to a Storage as a Service (STaaS) | DataMiner Docs solution. The STaaS setup uses a different data design that handles these types of scenarios much more efficiently, along with several other improvements