Update from 0.16b1 to 0.17b0 stopped to export spans

[mat-rumian]

Describe your environment
After update from release 0.16b1 to 0.17b0 exporting the spans stopped to work in my demo application - simple Flask HTTP servers with some requests.

Steps to reproduce
Clone the test application: https://github.com/SumoLogic/the-coffee-bar

How to run:

# Run the docker images build script
./scripts/build_local_all.sh`

# Run the docker-compose
cd dockerization
docker-compose up

Spans should be present in the otelcol console and they are available also under http://localhost:16686 - look for services called the-coffee-* - they come from Python apps.

What is the expected behavior?
Exported spans.

What is the actual behavior?
Focus on the apps/containers with prefix the-coffee-*. Other apps are implemented in different languages.
TraceId and SpanId are injected in the logs so I can see that application is instrumented but spans are not exported via exporters OTLP, Jaeger, Zipkin

Additional context
Used packages:

opentelemetry-sdk==0.17b0
opentelemetry-instrumentation==0.17b0
opentelemetry-exporter-jaeger==0.17b0
opentelemetry-exporter-otlp==0.17b0
opentelemetry-exporter-zipkin==0.17b0
Flask==1.1.2
requests==2.25.1

[srikanthccv]

@mat-rumian Please add opentelemetry-distro = "0.17b0" to your Pipfile that should solve this problem.

[srikanthccv]

@codeboten @lzchen @owais
Shouldn't opentelemetry-instrumentation (auto-instrumentation) package have the dependency on opentelemetry-distro and load&configure that by default?

[srikanthccv]

I got the same issue. Installing opentelemetry-distro did not help

@ankitnayan are you sure? Can you share a reproducible example? I have the fork of the original issue working with suggested change.

[ankitnayan]

@lonewolf3739 I got it working for -e jaeger but OTLP doesn't seem to send data

OTEL_SERVICE_NAME=pythonApp OTEL_EXPORTER_OTLP_SPAN_ENDPOINT="https://ingest.signoz.io:55681/v1/traces" OTEL_EXPORTER_OTLP_HEADERS="signoz-access-token=<token here>" opentelemetry-instrument -e otlp_span python3 app.py --loglevel=info

The above command should work, right? if the endpoint is returning some error then it should show an error...The below command works fine.

OTEL_SERVICE_NAME=pythonApp OTEL_EXPORTER_JAEGER_ENDPOINT="https://ingest.signoz.io:14268/api/traces" opentelemetry-instrument -e jaeger python3 app.py --loglevel=info

I hope 55681 is the port for OTLP HTTP endpoint

[ankitnayan]

I went through the docs and code. It is difficult to understand how to make OTLP HTTP calls? Is the default GRPC call? How can I set whether to choose OTLP HTTP vs OTLP GRPC?

[lzchen]

@codeboten
The issue of users not knowing which is the default is obvious now. We should decide on what to do about the splitting up of packages.

[srikanthccv]

I went through the docs and code. It is difficult to understand how to make OTLP HTTP calls? Is the default GRPC call? How can I set whether to choose OTLP HTTP vs OTLP GRPC?

The OTLP exporter only supports gRPC as of now and you should pass the endpoint without scheme in it.

I hope 55681 is the port for OTLP HTTP endpoint

No, it has been updated to 4317 to be consistent with collector guidelines recently. Here is the changelog for the release.

[mat-rumian]

@lonewolf3739 thanks a lot for a tip with installation of opentelemetry-distro everything work now as expected. But what's the main purpose of installation of this package? It's not mentioned in any documentation that it is needed.

[srikanthccv]

@lonewolf3739 thanks a lot for a tip with installation of opentelemetry-distro everything work now as expected. But what's the main purpose of installation of this package? It's not mentioned in any documentation that it is needed.

I have a half knowledge about it and didn't follow the development around this. I believe @codeboten would be the right person to answer this.

[codeboten]

@ankitnayan the issue to support OTLP exporter over HTTP with protobuf is here and with JSON here

@mat-rumian the purpose of the opentelemetry-distro package is to configure the OTLP exporter as a default for users. The functionality was removed out of the SDK because it caused users to have to turn something off if they didn't want to use OTLP as an exporter. This separation of the default configuration behaviour allows users of otel python to create their own distro with whatever configuration defaults they prefer.

[codeboten]

The documentation around distros could use some serious improvements though :D

[srikanthccv]

@mat-rumian I believe your questions are answered. You may want to close this issue as the issue is resolved. I have a some questions around the defaults and current behaviour for which I want to have another separate follow up issue/discussion.

[lzchen]

Follow-up discussion here #1606