Update Symfony Messenger instrumentation to use SpanKind::KIND_PRODUCER, SpanKind::KIND_CONSUMER #1314

[RichardChukwu]

This implements instrumentation for the Symfony Messenger component in the OpenTelemetry PHP SDK. It fixes the spanKind label to follow https://opentelemetry.io/docs/specs/semconv/messaging/messaging-spans/#span-kind for both the dispatch and send methods, allowing for better tracing and monitoring of message handling within Symfony applications.

This PR addresses Issue regarding the need for appropriate span kinds and attributes for message processing in the Symfony Messenger. @brettmc

Closes: open-telemetry/opentelemetry-php#1314

[welcome]

Thanks for opening your first pull request! If you haven't yet signed our Contributor License Agreement (CLA), then please do so that we can accept your contribution. A link should appear shortly in this PR if you have not already signed one.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.33%. Comparing base (67ce817) to head (8ad2de6).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##               main     #304   +/-   ##
=========================================
  Coverage     80.33%   80.33%           
  Complexity     1026     1026           
=========================================
  Files            98       98           
  Lines          4114     4114           
=========================================
  Hits           3305     3305           
  Misses          809      809           

Flag	Coverage Δ
Aws	85.51% <ø> (ø)
Context/Swoole	0.00% <ø> (ø)
Instrumentation/CakePHP	20.00% <ø> (ø)
Instrumentation/CodeIgniter	73.94% <ø> (ø)
Instrumentation/ExtAmqp	89.58% <ø> (ø)
Instrumentation/Guzzle	69.73% <ø> (ø)
Instrumentation/HttpAsyncClient	81.33% <ø> (ø)
Instrumentation/IO	70.90% <ø> (ø)
Instrumentation/MongoDB	77.33% <ø> (ø)
Instrumentation/OpenAIPHP	86.82% <ø> (ø)
Instrumentation/PDO	89.56% <ø> (ø)
Instrumentation/Psr14	78.12% <ø> (ø)
Instrumentation/Psr15	93.50% <ø> (ø)
Instrumentation/Psr16	97.50% <ø> (ø)
Instrumentation/Psr18	82.08% <ø> (ø)
Instrumentation/Psr3	60.25% <ø> (ø)
Instrumentation/Psr6	97.61% <ø> (ø)
Instrumentation/Slim	86.95% <ø> (ø)
Instrumentation/Symfony	89.07% <100.00%> (ø)
Instrumentation/Yii	77.77% <ø> (ø)
Logs/Monolog	100.00% <ø> (ø)
Propagation/ServerTiming	100.00% <ø> (ø)
Propagation/TraceResponse	100.00% <ø> (ø)
ResourceDetectors/Container	93.02% <ø> (ø)
Sampler/RuleBased	32.14% <ø> (ø)
Shims/OpenTracing	92.99% <ø> (ø)
Symfony	88.20% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...mentation/Symfony/src/MessengerInstrumentation.php	97.00% <100.00%> (ø)

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 67ce817...8ad2de6. Read the comment docs.

[RichardChukwu]

Friendly ping on this @brettmc good to go?

[RichardChukwu]

@brettmc thank you for the feedback.

Any further updates please or is this good to go?

[RichardChukwu]

Noticed some CI tests failures though, but are unrelated to this issue.🤔

I may be wrong, but I'm guessing this can be merged and those looked at separately, right? @brettmc

[brettmc]

I'm guessing this can be merged and those looked at separately

Yes, those failures are unrelated and won't affect this PR.

[cedricziel]

I agree with the sentiment of this PR - I introduced the INTERNAL spans, because I added instrumentation for ext-amqp in addition to this one that would create the relevant PRODUCER spans. I wonder if this PR should also address this possible span duplication by modifying the ext-amqp instrumentation to enrich the spans created here?

[RichardChukwu]

Thank you for your feedback! @cedricziel

I agree that modifying the ext-amqp instrumentation to enrich the spans created here would be a valuable enhancement to avoid span duplication.

However, I believe this could be addressed as a separate issue to keep the scope of this PR focused on resolving the KIND_PRODUCER instrumentation for dispatch and send.

I’m happy to open a new issue to track this work and contribute to implementing it once this PR is merged. Let me know if that approach works for you!

@brettmc would love to hear your thoughts too