-
Notifications
You must be signed in to change notification settings - Fork 186
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
OTLP/GRPC Exporter Implementation #272
Conversation
Signed-off-by:Ritick Gautam <riticksinghrajput@gmail.com>
updated .gitignore
updated script file updated Makefile
What's working? * Sends spans to the Otel Collector * Spans contain: Attributes, Status Code, Kind, Start/End timestamp, Lib Version * Sucessfully sent OTLP to Honeycomb.io What's not working? * Need to rebase main onto this branch * Trace ID and Span ID are too long, and have been fudged to trim them. * No tests. Unit/Integ * Events on spans haven't been tested * Child spans haven't been tested * Example code needs to be updated (been testing with laravel-otel) * Need to check the status returned * Links not implemented * Generally just unfinished Anything more to add? * Thank you to the Ruby OTLP Exporter, lots of inspiration was taken from there
@zsistla - I know you were planning on working on something similar, wanted to tag you for awareness. |
Hi Bob,
Thanks for the heads up, this was pretty much what I was working on. I
guess I'll try to give him comments instead.
regards,
Amber
…On Fri, Mar 5, 2021 at 7:21 AM Bob Strecansky ***@***.***> wrote:
@zsistla <https://github.com/zsistla> - I know you were planning on
working on something similar, wanted to tag you for awareness.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#272 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKNQUTZAMCDNQ5VV227NP2TTCDZHRANCNFSM4YUATN5A>
.
--
Amber Sistla
Software Engineer
New Relic
|
… `make style` to format the code
contrib/OtlpGrpc/Exporter.php
Outdated
$this->compression = getenv('OTEL_EXPORTER_OTLP_COMPRESSION') ?: $compression; // TODO | ||
$this->timeout =(int) getenv('OTEL_EXPORTER_OTLP_TIMEOUT') ?: $timeout; // TODO | ||
|
||
$this->spanConverter = new SpanConverter('foo'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other exporters have passed the service name (foo
in this case) in via the constructer but it can also be set from OTEL_RESOURCE_ATTRIBUTES
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I've looked into this a little more, I see that most of the PHP Exporters take in the serviceName
. So I went down the rabbit hole of OTEL_RESOURCE_ATTRIBUTES
in other languages, and they seem to pass in service.name
etc into a Resource
on the TracerProvider
rather than passing the service name via the Exporter. See these two examples:
https://github.com/lightstep/opentelemetry-examples/blob/main/go/opentelemetry/server/server.go#L116
https://github.com/honeycombio/examples/blob/main/python-otlp/app.py#L20
Which is swaying me more to removing the $serviceName
from the Exporter entirely. What are your thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If OTEL_RESOURCE_ATTRIBUTES
exists it is prioritized; if it doesn't exist, then the service.name
is set in the tracer and should be pulled from there to set the service name for export.
You can get the ResourceInfo
from the tracer then iterate through the keys and set the attributes on the span like python.
https://github.com/open-telemetry/opentelemetry-python/blob/main/exporter/opentelemetry-exporter-otlp-proto-grpc/src/opentelemetry/exporter/otlp/proto/grpc/exporter.py#L127
The progress you made on this is fantastic! Once you make the metadata not hardcoded, it'll be completely flexible to send to whatever backend(s) the collector is set up for. If you comment out those lines, the Actually, I don't think the metadata doesn't even needs to be passed here. You can set it in the collector configuration file. For example, the config file for honeycomb would be something like this. Great job :) |
|
||
$sdk->setSpanStatus(SpanStatus::OK); | ||
|
||
$sdk->end($end_time); // Setting the end timestamp does not work how I expect it to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the line that I'm struggling to make the test pass. /cc @bobstrecansky
- Tried passing in a timestamp
- Tried not passing a timestamp, but fetching it later with
$sdk->getEnd()
and passing this to the Proto Span didn't work either.
I've ran into complications with setting an end time/duration when trying to write database instrumentation in Laravel too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I spoke with Sean about this in DM, I think we can use:
Clock::get())->timestamp()
To accomplish his timing demands here.
I asked on one of the weekly calls, but I forgot to add a comment here. I think we need to generate the proto files and add them into the repo. In the call it seemed like a good idea.
|
Definitely happy to add the proto files to the repo! |
I pushed the proto files and build is complaining, not sure if we want to exclude this dir from linting or not? Testing it formatted so I can try to get this build green.
1. Moved out ResourcesSpans into the SpanConverter 2. Time is almost fixed, well tests pass but... I learned the clock didn't work as I expected it to. Wall clock and monotonic clock are entirely unrelated. I still think this needs more work but I _think_ it tests that the duration is correctly set on the otlp span. 3. ResourceInfo is now populated on otlp ResourceSpans.
No, we do not want generated code to be formatted with php-cs-fixer This reverts commit 996b473.
… it's implemented
Hey all, Flagging this as ready for review. There's a few things which still need to be fixed but I believe it's 90% there.
Since it's almost there, merging it will open the floor for more contributors to resolve some of these without being blocked. |
Codecov Report
@@ Coverage Diff @@
## main #272 +/- ##
============================================
- Coverage 94.09% 94.09% -0.01%
- Complexity 495 551 +56
============================================
Files 47 49 +2
Lines 1185 1337 +152
============================================
+ Hits 1115 1258 +143
- Misses 70 79 +9
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The codecov part of this is unimportant to me right now. I think we can merge this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job on all your work on this!!!
What's working?
What's not working?
Anything more to add?