Closed paulgrav closed 9 months ago
But should contrib-auto-psr18 support both scenarios? Should there be a separate library for non-psr18 implementations?
I think it should be a new library, rather than trying to hack guzzle support into psr-18. There are also other guzzle methods which could also be handled (get
, post
, etc) for a guzzle auto-instrumentation library to be as useful as possible.
@paulgrav please try out https://packagist.org/packages/open-telemetry/opentelemetry-auto-guzzle
@brettmc Thank you very much! It works as expected.
Is your feature request related to a problem?
There are no PHP auto-instrumentation libraries that support
GuzzleHttp\ClientInterface
andpublic function send(RequestInterface $request, array $options = []): ResponseInterface;
We can’t easily migrate to Psr18 because
Psr\Http\Client\ClientInterface
andpublic function sendRequest(RequestInterface $request): ResponseInterface;
doesn’t support specifying options.Describe the solution you'd like
There would be an auto-instrumentation library, very similar to https://github.com/opentelemetry-php/contrib-auto-psr18 that would support the use case described above.
Describe alternatives you've considered
We could create our own PHP library that is almost identical to https://github.com/opentelemetry-php/contrib-auto-psr18 but with a couple of line changes that would auto-instrument our GuzzleHttp calls. But should
contrib-auto-psr18
support both scenarios? Should there be a separate library for non-psr18 implementations?Additional context
The code change would look something like: