Add AWS SDK Instrumentation

[willarmiros]

Is your feature request related to a problem?

I am unable to easily instrument aws-sdk-php clients for tracing.

Describe the solution you'd like

The expected outcome is an instrumentation library that can be used to capture the requests made to AWS resources via the AWS SDK for PHP as spans.

Describe alternatives you've considered

None

Additional context Add any other context about the feature request here.

[Grunet]

I think this may be possible in userland today, though I have yet to try it myself (but have been wanting to). I think there would be 2 main aspects

1. Injecting an OTEL-ified version of Guzzle into the AWS SDK as described in their docs here on handlers and middleware.
2. Injecting OTEL into a Guzzle instance, probably as described in their docs here on handlers and middleware.

I have less of a sense on how that would be converted into auto-instrumentation though. Like presumably if Guzzle were monkey patched via reflection (like I believe is similar to how Python and JS handle their auto-instrumentation libraries?) near the start of PHP execution, the AWS SDK's default usage of Guzzle would just automatically use the modified version? I'm not entirely sure.

[Grunet]

I made a little POC of the 2nd bullet here - https://github.com/Grunet/opentelemetry-php/tree/poc-for-instrumenting-guzzle - the basics seemed to work fine from what I could tell.

I'm struggling to figure out how to make an auto-instrumentation version of this though. PHP's reflection APIs don't seem to support modifying constructors, and the runkit PHP extension seems ever so slightly unstable on the face (though maybe I'm just unfamiliar with it) though it does seem like it would support constructor modification.

The only alternative I can think of would be to get OTEL directly embedded into Guzzle itself, but idk what that process would look like

EDIT: This SO post also has an answer suggest loading then modifying the PHP source code and eval-ing it before the autoloader gets to actually loading it. Maybe some variation of that could work here too, though it also seems plenty unstable.

EDIT 2: I wonder if doing some kind of namespace redirection would be stable. Like creating a package that wraps Guzzle and just extends it the little bit needed to add in OTEL, then auto-setting Composer autoloading config (when? where? For all auto-instrumentation at once? Maybe in a Composer plugin that responds whenever an autoload dump happens?) to have it point to this package instead of Guzzle proper

[brettmc]

Resolved by https://github.com/open-telemetry/opentelemetry-php-contrib/pull/75