Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KIND::CONSUMER instrumentation implemented #307

Open
wants to merge 15 commits into
base: main
Choose a base branch
from

Conversation

RichardChukwu
Copy link
Contributor

Fixes #1314
Related #304

-Added the "consume" operation with SpanKind::KIND_CONSUMER for receiving messages.

-Updated span names to use publish, send, and consume as per the spec, ensuring naming consistency for operations.

-Instrumented the SenderInterface for both sending and receiving spans, with the appropriate SpanKind (producer for sending and consumer for receiving).

@RichardChukwu RichardChukwu requested a review from a team as a code owner October 17, 2024 10:27
Copy link

codecov bot commented Oct 17, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.41%. Comparing base (ee99079) to head (ee4522d).
Report is 3 commits behind head on main.

❗ There is a different number of reports uploaded between BASE (ee99079) and HEAD (ee4522d). Click for more details.

HEAD has 9 uploads less than BASE
Flag BASE (ee99079) HEAD (ee4522d)
Instrumentation/Psr16 1 0
Instrumentation/PDO 1 0
Instrumentation/HttpAsyncClient 1 0
Instrumentation/Symfony 1 0
Instrumentation/CodeIgniter 1 0
Instrumentation/Psr6 1 0
Symfony 1 0
Instrumentation/Guzzle 1 0
Instrumentation/Slim 1 0
Additional details and impacted files

Impacted file tree graph

@@             Coverage Diff              @@
##               main     #307      +/-   ##
============================================
- Coverage     85.87%   80.41%   -5.46%     
+ Complexity     1081      592     -489     
============================================
  Files            73       43      -30     
  Lines          4480     2211    -2269     
============================================
- Hits           3847     1778    -2069     
+ Misses          633      433     -200     
Flag Coverage Δ
Instrumentation/CakePHP 20.00% <ø> (ø)
Instrumentation/CodeIgniter ?
Instrumentation/Curl 90.66% <ø> (ø)
Instrumentation/Guzzle ?
Instrumentation/HttpAsyncClient ?
Instrumentation/IO 70.68% <ø> (ø)
Instrumentation/MongoDB 72.64% <ø> (ø)
Instrumentation/MySqli 96.10% <ø> (ø)
Instrumentation/OpenAIPHP 87.31% <ø> (ø)
Instrumentation/PDO ?
Instrumentation/Psr14 77.14% <ø> (ø)
Instrumentation/Psr15 93.82% <ø> (ø)
Instrumentation/Psr16 ?
Instrumentation/Psr18 81.15% <ø> (ø)
Instrumentation/Psr6 ?
Instrumentation/Slim ?
Instrumentation/Symfony ?
Instrumentation/Yii 77.68% <ø> (ø)
Propagation/ServerTiming 100.00% <ø> (ø)
Propagation/TraceResponse 100.00% <ø> (ø)
ResourceDetectors/Container 93.02% <ø> (ø)
Sampler/RuleBased 33.51% <ø> (?)
Shims/OpenTracing 92.45% <ø> (ø)
Symfony ?

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

see 56 files with indirect coverage changes


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 ee99079...ee4522d. Read the comment docs.

composer.json Outdated Show resolved Hide resolved
return new LegacyInMemoryTransport();
}

protected function getReceiver()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this different enough from getTransport to require a method? It doesn't return a receiver but a transport...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@RichardChukwu have you had any time to look further into this?

Copy link
Contributor Author

@RichardChukwu RichardChukwu Oct 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @ChrisLightfootWild, thanks for asking.

Not really, I'll appreciate any assistance please

$builder = $instrumentation
->tracer()
->spanBuilder(\sprintf('DISPATCH %s', $messageClass))
->setSpanKind(SpanKind::KIND_PRODUCER)
->spanBuilder(\sprintf('publish %s', $messageClass))
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not "dispatch"?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The span types and names should be consistent with the spec here:
https://opentelemetry.io/docs/specs/semconv/messaging/messaging-spans/#span-kind

But it's kind of confusing TBH, it mentions both "publish" and "send", in the example it gives publish shop.orders, but then it doesn't give publish in operation type or span kind. 🤯

@brettmc can you clarify the spec wording here maybe?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants