Audit Logging

[Jim Auldridge]

Greetings,

I am involved in a few projects which will need me to implement some solid audit logging. I use loggers that implement the PSR-3 Logger Interface and am surprised to find no mention of audit logging. I see further that it references RFC 2119, which also makes no mention of audit logging.

It seems to me that logging for the purpose of leaving an audit trail is somewhat different than the other log level purposes. Audit entries should probably always be logged, regardless of the log level configuration in a project. Perhaps a log level of AUDIT that always logs if a new companion boolean config flag is set to true?

It also seems there should be some expected format that includes what user took an action, whether it was done by proxy of another user, and what it was that took place (the message).

Do you have any thoughts these needs and whether the current PSR covers them? Any other ideas for audit logging criteria? How would you implement audit trails with the current logger interface, or is it appropriate to suggest a new PSR for logging that includes this need?

Thanks for any discussion you bring to the matter!

Jim

[Ralf Lang]

Hi Jim,

for a meaningful audit trail I think the general system logs are only the second best option and you would rather want to ensure meaningful observability through something like a PSR-14 Event system - the different system components just emit events and have no notion of priority or relevance - that's for the event listeners to decide, i.e. your audit sink.

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/php-fig/c100ae27-6056-4913-b3f1-9495e1446ed0n%40googlegroups.com.

[Larry Garfield]

On Sat, Apr 18, 2026, at 6:21 PM, Jim Auldridge wrote:
> Greetings,
>
> I am involved in a few projects which will need me to implement some
> solid audit logging. I use loggers that implement the PSR-3 Logger
> Interface and am surprised to find no mention of audit logging. I see
> further that it references RFC 2119, which also makes no mention of
> audit logging.
>
> It seems to me that logging for the purpose of leaving an audit trail
> is somewhat different than the other log level purposes. Audit entries
> should probably always be logged, regardless of the log level

> configuration in a project. Perhaps a log level of AUDIT that *always*

> logs if a new companion boolean config flag is set to true?
>
> It also seems there should be some expected format that includes what
> user took an action, whether it was done by proxy of another user, and
> what it was that took place (the message).
>
> Do you have any thoughts these needs and whether the current PSR covers
> them? Any other ideas for audit logging criteria? How would you
> implement audit trails with the current logger interface, or is it
> appropriate to suggest a new PSR for logging that includes this need?
>
> Thanks for any discussion you bring to the matter!
> Jim

(Repeating what I said in Discord for posterity.)

The log levels in PSR-3 are inherited from RFC 5424[1], so are a long-time standard. We shouldn't be messing with how that works, so adding an "audit" level doesn't seem like the right approach.

Rather, the PSR-3 way to handle that is to have an "audit" log channel, aka PSR-3 instance. That instance can be configured to always record whatever gets sent to it, period, and potentially send it to a different place than the normal application log. Also routing such messages through a PSR-14 event as Ralf suggests is an option, but I don't think is necessary.

As far as an expected format for the messages, that would be a separate topic; whether it's worth its own PSR is an open question, though I'm not yet convinced. It would more likely be standardizing more context key names beyond 'exception' rather than the message structure itself.

[1] https://datatracker.ietf.org/doc/html/rfc5424

[Aleksei Khudiakov]

Hi all,

I agree with Larry here. Audit log entry is not really another log level but rather a different kind altogether. If it has to be done with PSR-3 a separate log channel/instance feels more appropriate.

Simple logger interface like PSR-3 is not really well suited for this. I believe for audit trail you should look towards more comprehensive observability approach like OpenTelemetry. For audit entries OpenTelemetry Tracing is of particular interest with event recording spans tree. Combined with the regular logging enhanced with OTel context for correlation it should give full audit picture. 
It has been years since I looked at the php sdk for opentelemetry. I am not particularly fond of the static api in the example https://opentelemetry.io/docs/languages/php/getting-started/#traces but I can easily see it abstracted from domain logic in the domain specific audit trail service/object. Or in the PSR-14 event listeners. 

Introducing proper support for OpenTelemetry in the application is not a trivial amount of work but going with the industry and the ecosystem around it is well worth it.

[Long Dmtvape]

Hi, thanks for the detailed explanation, that helps a lot.

[Jim Auldridge]

Thanks for the thoughts, everyone. Making it a separate channel makes a lot of sense, and avoids the line blurring that I alluded to in my original message. I also appreciate the thoughts on event systems. This has been a helpful discussion.

Jim

[Franklin Pierre]

💪