Add access log refactor proposal

[steven-zou]

Add access log refactor proposal

Signed-off-by: Steven Zou szou@vmware.com

[ghost]

Hi @steven-zou – this is awesome! I suspect that logging to external syslog server(s) is out of scope for this proposal, particularly considering K8s will handle much of that log consolidation for us. I do see a strong use case for logging over the network, however.

Just wanted to throw that out there.

[ghost]

nit:

• s/It's/It
• s/auditing usage/auditing purposes

[ghost]

Additional feedback from @goharbor/all-maintainers would be great.

[nlowe]

I like this idea, I know we have a few departments who would definitely be interested in this data. This sounds more like an Audit log than an access log. When I think access log I think logs from a web server (response code, request type, URL, IP addresses, etc. etc.)

A few things I'd love to see clarified:

• Who is responsible for generating UID's?
  • The application? If so, at what point does UID's get generated? When the context is injected? When an event is published?
  • The handlers? If so, do they all generate their own ID's? If they don't, we now have a special handler (the database?) that's responsible for doing more than just "handling" events.
• Can you give some examples of what the Metadata fields would be used for? I'm not sure I see a use for them. Assuming all of the handlers live in-repo, I think this can be taken care of on the deserialization side for remote / webhook-styloe applications that listen for these events which can be configured to ignore unknown fields until developers get around to updating them.

[ludz-lim]

Any chance that logging with source IP will be released in the near future?

[OrlinVasilev]

@steven-zou @nlowe is that valid or we can close? thank you!

[Razniak]

Hello, this case is still alive? :)

[OrlinVasilev]

I think we can park this one for now.... as nobody is working on it!