The UUIDs generated for the Alerts raised by the Edge Agent currently change every time the Edge Agent is restarted. This is not ideal, as the Directory has no way of knowing the new alert is a replacement for the old and will keep indexing both.
Since we have no information available to us except our own UPN, UUID and Sparkplug address, I propose using v5 UUIDs under the following scheme:
Use the existing Factory+ UUID 11ad7b32-1d32-4c4a-b0c9-fa049208939a as the v5 UUID namespace.
The name within this namespace is a string composed of colon separated parts.
The first part is a subtype, also a UUID in canonical string format.
The subtype 8a4dc2f4-2f9f-45fc-b2e9-ed7b9cda6145 is hereby reserved for generating Instance_UUIDs from fixed metric names.
Names of this subtype have two more parts: a Device UUID and a string metric name.
The metric name must be the folder prefix of the Instance_UUID metric we are generating.
So an alert based at Alerts/Config_Invalid for a device with uuid 11111111-2222-3333-4444-555555555555 would have a metric Alerts/Config_Invalid/Instance_UUID generated with
The UUIDs generated for the Alerts raised by the Edge Agent currently change every time the Edge Agent is restarted. This is not ideal, as the Directory has no way of knowing the new alert is a replacement for the old and will keep indexing both.
Since we have no information available to us except our own UPN, UUID and Sparkplug address, I propose using v5 UUIDs under the following scheme:
11ad7b32-1d32-4c4a-b0c9-fa049208939a
as the v5 UUID namespace.8a4dc2f4-2f9f-45fc-b2e9-ed7b9cda6145
is hereby reserved for generating Instance_UUIDs from fixed metric names.So an alert based at
Alerts/Config_Invalid
for a device with uuid11111111-2222-3333-4444-555555555555
would have a metricAlerts/Config_Invalid/Instance_UUID
generated with