-
Notifications
You must be signed in to change notification settings - Fork 451
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 python service - trace data doesn't arrive in Endpoint #924
Comments
Could you please provide full logs from the python service - recommendation? Could you please set |
well there's only 1 format of log in this pod except this fine line. and there's no log for the init container |
@tybalex did you try to set the sampling to After the setting is applied the pod needs to be restarted |
Yes I did set the sampling to 1 in the instrumentation like this:
and then i've re-deployed my services. |
@tybalex please set for Python instrumentation different exporter endpoint as Python instrumentation is using OTLP HTTP exporter by default. Please use eg.
|
This worked! thank you @mat-rumian . Just curious why python is treated differently from the other 2... |
we should take some action item here and fix the problem for all users. This should be either documented or the operator can set env var |
@pavolloffay based on that open-telemetry/opentelemetry-specification#1885 (comment) I think we should set our instrumentations exporters to OTLP HTTP protocol. |
From the linked issues it seems like there is no strong opinion what is the default exporter and SDKs might choose one or the other depending on circumstances. To me it seems like that we should follow what the language SDKs do and choose the right default based on the language. |
+1, @srikanthccv any thoughts on this? I'm happy to send a PR for this if we agree on the approach. |
We have been using OTLP/gRPC as a default exporter in the auto instrumentation package https://github.com/open-telemetry/opentelemetry-python-contrib/blob/51ba801bfda31c3d57902d9f9df938cee1236eb8/opentelemetry-distro/src/opentelemetry/distro/__init__.py#L37-L38. This was the choice of default partly because we didn't have HTTP exporters for OTLP. Even outside this operator deployment, I have seen people run into weird issues because gRPC sometimes doesn't work well with their env. Personally, I am in favor of using OTLP/HTTP + Protobuf. With that change people who already run gRPC will face issues because the env like endpoint needs to be updated. |
For this issue, I wonder if instead of overriding See here: |
Don't we do that already today? when the And the priority order |
You're right it needs to be fixed in the operator 👍 sorry for the confusion. @pavolloffay @mat-rumian would you accept a PR setting the port to 4318 for Python? |
@aabmass what did you have in mind for setting the port to |
I am trying out the auto-instrumentation feature of Open Telemetry with an example demo application. I tried to applied auto-instrumentation to the 2 python services
recommendation
andemail
, as well as 2 nodejs servicespayment
andcurrency
. However I was only able to find trace data from nodejs services in my endpoint (Opensearch), but not python services'.My environment
k3s-1.23
example demo application(https://github.com/GoogleCloudPlatform/microservices-demo)
python 3.7 for the python services
manifest of the python service:
Example logs in the recommendation service pod:
they do have Otel traceID and ServiceName assigned.
What is the expected behavior?
trace data available in the Opensearch index
otel-v1-apm-span*
, as I do see the trace data from nodejs services.What is the actual behavior?
trace data from python services are missing.
additional information
here's the instrumentation :
The text was updated successfully, but these errors were encountered: