💪 On Saturday, April 25, 2026 at 11:43:48 PM UTC+1 Jim Auldridge wrote:
> 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 > > On Saturday, April 25, 2026 at 6:30:30 PM UTC-4 Long Dmtvape wrote: > >> >> Hi, thanks for the detailed explanation, that helps a lot. >> >> On Monday, April 20, 2026 at 8:27:31 PM UTC+1 Aleksei Khudiakov wrote: >> >>> 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. >>> >>> On Tuesday, April 21, 2026 at 1:10:25 AM UTC+10 Larry Garfield wrote: >>> >>>> 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 >>>> >>> -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/php-fig/40d2ee15-0573-4eb9-8f11-9e72a9c1eb5dn%40googlegroups.com.
