Symfony Instrumentation

open-telemetry / opentelemetry-php

The OpenTelemetry PHP Library

https://opentelemetry.io/docs/instrumentation/php/

Apache License 2.0

743 stars 186 forks source link

Symfony Instrumentation #914

Closed bobstrecansky closed 1 year ago

bobstrecansky commented 1 year ago

@cedricziel was working on this PR for Symfony instrumentation: https://github.com/open-telemetry/opentelemetry-php-contrib/pull/58

He had to close it due to a lack of time. Anthony Tetlow may be working on something similar. Following up with him.

codedge commented 1 year ago

Just to get an idea: Is there someone, Anthony Teltow(?), actively working on? I saw the PR started by @cedricziel, which looked quite good, but I understand this has been stopped due to time constraints.

The question is: Is there another WIP version (PR), where support is needed?

piotrantosik commented 1 year ago

@codedge look here: https://github.com/open-telemetry/opentelemetry-php-contrib/tree/main/src/Instrumentation/Symfony I use this with custom logic (i mean instancing sdk in index.php), this week I deployed it into production app, works perfectly. Also, I have internal instrumentation with Symfony Http Client - need to fix some bugs and next week I will try to prepare PR.

sebb-m0 commented 1 year ago

Hey @piotrantosik. Any updates from your side with the PR? Can we support you in any way?

piotrantosik commented 1 year ago

Hi all, PR with Symfony HTTP Client -> https://github.com/open-telemetry/opentelemetry-php-contrib/pull/130 Please look on it and test if you have a possibility.

codedge commented 1 year ago

@piotrantosik I think we misunderstood here. What I would expect is an integration into the Symfony framework, so that you can install a bundle, that

hooks into every request and collect information (we got that ✔️ )
gives you a config/packages/opentelemetry.yaml to configure option to your needs, f. ex. where do you want to collect data: Elasticsearch, Prometheus, ..
adds a JAEGER_URL env var in your .env file
adds a PROMETHEUS_URL env var in your .env file .. so the data is automatically exported to the configured backend...

When looking at the closed PR this was exactly what @cedricziel would have done.

Is that what you, @piotrantosik, are implementing now or did I understand something wrong?

piotrantosik commented 1 year ago

No, I don't create any bundle - I'm focused right now on auto instrumentation. In my SF project, I enable collector via configuring SDK, I want to update readme with similar code to this example: https://gist.github.com/piotrantosik/56d7ab585fe1c5c96e028cd6c08f7de5

I don't think a bundle will be needed, everything can be set up via ENV variables and SDK.

cedricziel commented 1 year ago

To be fair: with PHP we'll need both. It's not a common ability to install custom extensions into shared hosting environments. From a users perspective, they should be able to observe their apps regardless of where they are. I would like a bundle that uses an observable http client so that I don't have to fiddle around with tedious compilation of additional extensions.

In scope of this PR: instead of starting with high-level components like the Symfony HTTP Client, it would probably a good choice if we Auto instrumented the primitives below such as curl and file_get_contents to make sure we would provide value beyond just Symfony. However: this is good work

brettmc commented 1 year ago

I think we can close this, since https://github.com/open-telemetry/opentelemetry-php-contrib/pull/169 has gotten Symfony instrumentation back in working order.