-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alarm streaming: CLEARED versus TOMBSTONE #548
Comments
In TR-548 the alarm is considered as an entity. When the alarm state goes to cleared, the entity is considered as having been deleted (so the active alarm list essentially is being considered as the presence of alarm entities). There should be no entity representing the existence of a CLEARED alarm (otherwise the log would continue to grow with cleared alarms. The delete can carry extra details if necessary related to the clearing reason etc. (in the same way it could carry deletion reason for any other case). This has not been assumed to be necessary at this stage and hence not detailed. Are there details in the cleared alarm that you think need to be conveyed? The text in TR-548 is sloppy. It should state that "The Tombstone (representing the clear) shall cause..." and "The Tombstone shall also cause the compaction process to remove the Delete (representing the clear alarm)..". I will read through the related sections and try to catch any related ambiguities. I hope this clarifies. |
I have checked the text and have changed the section you commented on to... As noted earlier, the alarm DELETE record (representing the alarm clear) shall be followed immediately by a Tombstone record. As also noted, the deletion of an alarm detector, where the alarm was active prior to the deletion, shall cause at least the logging of a Tombstone record. Allowing for compaction delay:
|
I also made a minor adjustment to the earlier section... CLEARED should not be used. A cleared alarm is represented by a DELETE/TOMBSTONE. |
No, I did not have any extra clear information in mind. I was merely trying to understand how a clear would be modeled in the stream. |
When an alarm is modeled as an entity, what is its unique id? Is it the If the controller is using a compacted log in Kafka to maintain the alarm stream, what would be the "key" for a message corresponding to the log-record for an alarm? |
Regarding alarm entity, we need to check if the item is clarified in TR-547 - and if not, maybe reuse TR-548 statements. |
Hi @amazzini , @nigel-r-davis Regarding the unique identifier of an alarm, following are the contenders (in my understanding):
|
Regarding option 2, also the target-object-name (local class, child of global class identified by target-object-identifier). |
Hi, From a streaming perspective, the entity-key needs to be the same value for the raise, any changes and the clear for any particular detection. The entity-key needs to be unique across all alarms active at a time. It is OK for an entity-key to be used again, so long as it does not violate the uniqueness need. So, for example, the entity-key could be a unique identifier of the detector (for a single condition). In this case, whenever the alarm is active, it will use the same identifier. But clearly, the active-clear-active cycle will ensure temporal isolation and compaction will clean up as usual. The entity-key is usually a uuid format. There is no reason in the standard to specify how the entity-key is generated as it is treated as opaque. From a standard perspective, you could use any of the methods you propose so considering each in turn:
I hope this is clear enough. |
In TR547 v2.0 page 60, it says:
However in section 4.7 (page 63), it says:
This raises the question whether a stream-record needs to be created with perceived-severity as CLEARED when an alarm is cleared and then delete/tombstone the original alarm.
This also raises the confusion about what should be used as the "key" for alarms in a compacted log?
Should it be the detector-uuid?
The text was updated successfully, but these errors were encountered: