Hi Larry Sounds good. There's been a bit of discussion in the Discord as to possible vendors to talk to. so I'll see if I can get in contact with a few people! I will follow up if/when the time comes to seek a sponsor.
Nb: Not entirely sure how to handle bottom-posting when it comes to google groups webUI, as I don't seem to be receiving replies in gmail. Happy to discuss more on Discord if that works for you :) Thanks A On Tuesday, 15 March 2022 at 16:21:46 UTC Larry Garfield wrote: > On Tue, Mar 15, 2022, at 10:04 AM, Adam Allport wrote: > > Hi Larry, > > Thanks for your response. > > > > 1) Differences to PSR-3 > > Whilst PSR-3 (Logging) does improve observability within an > > application, it is just that, logging. > > Tracing (sometimes referred to as application performance > > monitoring/APM) takes it a step further to answer the questions When is > > my application doing *x*, and why > > > > 2) Rough Sketch of what the spec might look like > > Yeah! I think we should consult the methodologies set out by > > > https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md > > I believe bringing the interfaces into a PSR could provide the needed > > encouragement for adoption & standardisation > > > > I will note, opentracing has been adopted as a standard by various > > large players for other languages. > > The lack of a standard for PHP may be holding it back > > > > This would allow developers to integrate various parts of their > > application to OT systems like Zipkin and Jaeger. In a standardised way. > > *An* implementation could look similar to how Sentry have implemented > > the tracing section of the library: > > https://github.com/getsentry/sentry-php/tree/master/src/Tracing > > There is an OpenTracing PHP SDK available, however, I do not feel it's > > appropriate for framework/library developers to add this as a > > requirement, since it would increase the inherent size of the > > application. > > The PSR would naturally form an interop layer for libraries to > > contribute to an applications traces, should a TraceProvider be > > available/provided > > > > The motivation behind this is due to how there are currently (for > > Laravel projects as an example) 3 distinct ways to handle insights for > > what an application is doing, each of which have their own, very > > similar, methods for adding traces to a project > > - Tools like Sentry > > <https://docs.sentry.io/platforms/php/performance/instrumentation/> > > - Tools like Clockwork <https://underground.works/clockwork/> > > - Tools like Laravel Debugbar > > <https://github.com/barryvdh/laravel-debugbar> > > > > 3) Members who could form a working group > > You've rightly identified Sentry, I have not contacted them directly, > > however, their other implementations do confirm to the OpenTracing > > spec, which would suggest they would be interested. > > There will almost certainly be PHP Developers from the CNCF who may be > > interested (although not contacted) > > > > Please let me know if this raises any further questions! > > A > > That all sounds reasonable. Your next step would probably be to speak to > various vendors and see if you can get them on board. If 3-4 vendors showed > up and said "hey, we want to standardize a PHP version of a known > cross-language spec that we all use", I expect FIG would respond with a > loud "yes please!" :-) You'll also need a CC member as a sponsor; I don't > have the bandwidth but you can probably find one who does. > > (Also, please stick to bottom-posting if someone bottom-posts a thread. It > makes it easier to track. Thanks.) > > --Larry Garfield > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/c11d40a7-2a1d-4f81-b2df-0dec68724eccn%40googlegroups.com.
