We need to create a Concise way of reporting about events based on the use cases of our users.

[underdarknl]

We need to create a Concise way of reporting about events based on the use cases of our users. This mostly covers the data we send out as structured logging, as not all of this is relevant for OpenKAT itself.

Originally posted by @underdarknl in #3038 (comment)

Possibly look at the NEN7513 for inspiration.

• UserID
• Login technique used (api / browser session)
• Remote IP address?
• TIMESTAMP
• EventCode
• EventData as json
• OpenKAT version
• Post/GET/DELETE/PUT values

[r3boot]

The fields that contain PII (UserID, Remote IP, Timestamp, EventCode, EventData) should be hashed. The hashing parameters should be configurable by the operators of OpenKAT, and these operators should also be able to view the mapping between PII and the hashed version. Logging that is submitted to storage should only have hashed/anomized logging. This will prevent people that run the OpenKAT infra from learning PII (to an extent).

From a operational / development perspective, the following information is also nice to have:

• Timing and result of operation performed
• Host on which an operation is performed
• Amount of resources consumed (cpu, memory, storage)
• HTTP headers used during operations (anomized if it contains PII)
• Which hosts are involved in a request
• Identifier(s) that can be used to correlate a operation (as done by a single component) to a job.

[underdarknl]

Agreed on the hashing. A configurable hashing algo, and seed would be preferable.
I'm not sure we can gain access to all other requests in all location where we want to create the events, but we could try.

Which hosts are involved, and which JOB-ID is associated with an event is a more complex question than just sending out singular events. Although I do see the value of this.