Hello everyone, I work for Blackfire.io/Platform.sh on the Profiler and APM PHP extension. We are interested by this working group and would be happy to help.
If you want to talk to me, I've just joined the Discord with the username iamluc. Kind regards Le mardi 15 mars 2022 à 16:58:40 UTC+1, ad...@allport.me.uk a écrit : > 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 > > > On Tuesday, 15 March 2022 at 14:29:48 UTC Larry Garfield wrote: > >> On Tue, Mar 15, 2022, at 5:49 AM, Adam Allport wrote: >> > Hi All, >> > >> > Observability for web applications is becoming increasingly common, and >> > as such decreasingly interoperable. >> > >> > Whilst tools like Sentry & Elastic exist, the lack of a standard >> > restricts the ability for frameworks and libraries to add useful spans >> > to the possibly slow processes that they are building. >> > This lack of interoperability makes integrating or migrating between >> > tools a lengthy process, as you are then required to re-implement all >> > of your tracing efforts. >> > >> > As such, I suggesting PSR & interface's package to bring the >> > OpenTelemetry spec to PHP in a manner that may push frameworks and >> > libraries to finally standardise. >> > >> > I look forward to hearing your feedback on this suggestion >> > >> > Many Thanks >> > Adam Allport >> >> I'm not too familiar with this space myself, so a few key questions for >> such a PSR: >> >> 1) How would this be different from/not serviced by PSR-3? >> >> 2) Do you have a rough, vague sketch of what such a spec might look like? >> Or a sample of an existing implementation/API docs you can link to for >> those of us who don't know the space well? >> >> 3) Who are the players in that space that should be involved in such a >> working group? Off hand it sounds like we'd want someone from Sentry >> involved, for instance, both for their expertise and to help ensure it >> actually gets adopted. Have you reached out to them to see if they're >> interested? (Making a spec from on high and then handing it to 3rd party >> implementers to adopt doesn't have the greatest track record.) >> >> --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/392f2e27-ccca-4edf-989b-2c75951c9c0cn%40googlegroups.com.
