Add documentation for event externalisation

[alexane-bougeardbebin-sekoia]

see https://github.com/SekoiaLab/platform/issues/86210

[mathieuguarino-ctrl]

@alexane-bougeardbebin-sekoia I think you put externalisation instead of eternalisation almost everwhere ?

[alexane-bougeardbebin-sekoia]

@mathieuguarino-ctrl does it answer your need?

@rdettai-sk is this accurate? I gathered info from dust, but I can't make sure if everything is (still) up to date and accurate.

[mathieuguarino-ctrl]

several minutes I think

[github-actions]

Newest code from alexane-bougeardbebin-sekoia has been published to preview environment

🚀 Latest deployment was built on 2026-05-29 11:22:31 (b3749b99690cd1e1febe8b0ff8d7a573949426cf).

[rdettai-sk]

This is common to all events, I don't think it should be in this page.

[mathieuguarino-ctrl]

Another warning :

events linked to anomaly rules are not eternalized (there is no event tab in an Anomaly Alert)

[alexane-bougeardbebin-sekoia]

@rdettai-sk @mathieuguarino-ctrl I'm starting the article again to make sure I cover only eternalisation. I am a bit embarrassed because if it sure helps users understand what this is and the cause of some issues, it doesn't really help them understand :

• the benefits
• how they can act

• It gives a rather poor image of this process, don't you think? But I am missing infos to make it more actionnable/positive

[mathieuguarino-ctrl]

Hello @alexane-bougeardbebin-sekoia

• Eternalisation can be compared with Hot and Cold storage, which have specific retention values
• How they can act : nothing to do on this part once an alert is created, it is eternalised, but some clients don't have the info that these events are here forever
• Maybe we can link it to retention doc

Regarding this :

Events may be missing from an Alert

If eternalisation partially fails, an alert may be published with fewer events than expected, or none at all. This can make investigation difficult, as the supporting evidence is incomplete.

Eternalisation should (and must) not fail (except with incidents/bug?) I don't think this is something we want written.

[rdettai-sk]

it doesn't really help them understand :
the benefits
how they can act
It gives a rather poor image of this process, don't you think? But I am missing infos to make it more actionnable/positive

I can give you my understanding that too biased by the technical side of things, but I think it's interesting for you nevertheless. AFAIK, what we want functionally is just to have some events attached to alerts. Eternalization is a technical implementation detail that serves several purposes:

• avoid loosing the events attached to alerts when their retention expires: retention policies just delete big chunks of data, it is not simple to tell them to delete everything but event x, y and z.
• fast retrieval of events for an alert: technically, with the data volumes we have it is not straightforward to cherry pick an arbitrary number of events and attach them to an id (here the alert id)
• (I might be forgetting reasons...)

But I insist, these are implementation details, I don't think we need or want to expose it to users. For instance when working on Exalog, we considered removing eternalization entirely. Users wouldn't have cared, as long as they have their events, their alerts and some events attached to alerts. We didn't because it is still technically the best approach.

I don't know how exactly the decision was made to expose eternals explicitly as a SOL datasource. I think again that it was the simplest technical solution to give users access to both to their main event stream and the events attached to alerts. But purely functionally, I guess the ideal approach would have been to have just one events datasource from which you can magically get events that are attached to alerts or not. This is what happens on the "Events" page.

I think you should involve someone from product (maybe @Sengthay ?), because I might not have the full picture on the functional side.