-
Notifications
You must be signed in to change notification settings - Fork 651
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
Auto-instrumentation issue after 0.16b1 #1622
Comments
Might be same as #1577. Please install |
cc // @codeboten |
That helped. I'm getting traces now. However, I am seeing other issues that I did not see before. Here's some context: export OTEL_TRACES_EXPORTER="otlp" I am toggling OTEL_TRACES_EXPORTER between "jaeger" and "otlp". With the otlp exporter, I am getting this error which is new since 0.16b1 (otlp worked fine with 016.b1): So I switched over to the Jaeger exporter and found that it is not honoring the service.name set with OTEL_RESOURCE_ATTRIBUTES. service.name shows up as "unknown_service". This may not be a new issue since I did not test this previously. It is setting the environment tag though. Also Jaeger insists on Thrift/HTTP vs gRPC. The code appears to support gRPC but I cannot get it working with pure auto-instrumentation. It looks like I'd have to configure the exporter manually in code. Iow, if I set OTEL_EXPORTER_JAEGER_ENDPOINT to "http://markf-0398:14250", I get this: |
Would you mind creating another issue for this? This is specific to OTLP.
Yes, as of now this is case. There is an issue created for this already #1607.
I don't think there is any insistence, Jaeger sends traces to the agent(Thrift/UDP) by default unless you set the collector endpoint to use with either HTTP or gRPC way. The Exception you shared is not clear. Could you please share the full stack trace (formatted)? |
I opened another issue for the pop() error. Sorry about the formatting, I gave up trying to use "insert code"; it strips out the linefeeds no matter how I do it. For the Jaeger issue, maybe the question should be: how do I configure it to use gRPC vs HTTP with just environment variables and the runtime wrapper? Here's what I'm seeing: OTEL_EXPORTER_JAEGER_ENDPOINT="http://markf-0398:14268/api/traces" works fine. This is HTTP. OTEL_EXPORTER_JAEGER_ENDPOINT="markf-0398:14250" or "http://markf-0398:14250" both fail with: ERROR:opentelemetry.sdk.trace.export:Exception while exporting Span batch. It looks like it is still using HTTP with a gRPC endpoint and therefore failing, which is not surprising, I guess. My thought was that using port 14250 would trigger it to use gRPC because It worked that way with Java Otel up until Java removed support for Thrift/HTTP completely a few weeks ago. I don't think that's how it ought to work, granted. It would be better to explicitly tell it to use gRPC. In the end, this is not a burning issue for me, just bringing it up in the interest of achieving perfection. |
I think the question here is choosing between the following Jaeger endpoints/formats:
I'll create a PR to expose Jaeger's transport format to env vars and improve the documentation a bit. |
This issue was marked stale due to lack of activity. It will be closed in 30 days. |
This was fixed by #1657 |
Describe your environment
Instrumenting this service:
https://github.com/markfink-splunk/microservices-demo/tree/master/src/emailservice
The current commit is with 0.16b1 which works fine with the "opentelemetry-instrument" wrapper (see Dockerfile entrypoint).
When I upgrade to anything after 0.16b1 -- say 0.17b0, 0.18b1, 1.0.0rc1, etc -- I get no traces with the wrapper. I updated the environment variables (see below). I'm getting no traces for any instrumentation, particularly grpc but I also tried requests.
You can see the correct libraries added with requirements.in/txt.
My environment looks like this;
export OTEL_TRACES_EXPORTER="otlp"
export OTEL_EXPORTER_OTLP_INSECURE=true
export OTEL_EXPORTER_OTLP_ENDPOINT="markf-0398:4317"
export OTEL_RESOURCE_ATTRIBUTES="service.name=emailservice, environment=hipster_shop"
All is well with 0.16b1, just nothing after that. I'm using grpc_health_probe to test it.
What is the expected behavior?
I should see grpc traces.
What is the actual behavior?
What did you see instead?
No traces. Nothing is being sent to the Otel Collector. I checked with ngrep. No connection attempt is made.
I've tried in vain to enable debug logging for this app. It looks like it should be supported by the Otel tracer, but when I set the logging level to debug, it produces no additional output. I set it in logger.py in the project and I also tried "OTEL_LOG_LEVEL".
Could someone with deeper skills look at this? This seems like a pretty straightforward app. Or perhaps explain how to enable debug logging.
The text was updated successfully, but these errors were encountered: