Allow selecting Jaeger protocol via env vars

[seemk]

Description

Fixes #1622

It was not possible to change Jaeger protocol via env vars when attempting to use gRPC or Thrift over HTTP. Besides, the exporter configuration started deviating from the Zipkin exporter configuration where Zipkin has an optional protocol input field (example).

Zipkin already has a reserved environment variable OTEL_EXPORTER_ZIPKIN_PROTOCOL in the spec for the same purpose so this is an attempt to unify the configurations.

There's an existing spec PR to add OTEL_EXPORTER_JAEGER_PROTOCOL here.

Updated documentation to reflect the supported Jaeger exporter environment variables.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Unit tests and manual run with the service described in #1622

Does This PR Require a Contrib Repo Change?

Answer the following question based on these examples of changes that would require a Contrib Repo Change:

• The OTel specification has changed which prompted this PR to update the method interfaces of opentelemetry-api/ or opentelemetry-sdk/

• The method interfaces of opentelemetry-instrumentation/ have changed

• The method interfaces of test/util have changed

• Scripts in scripts/ that were copied over to the Contrib repo have changed

• Configuration files that were copied over to the Contrib repo have changed (when consistency between repositories is applicable) such as in

  • pyproject.toml
  • isort.cfg
  • .flake8

• When a new .github/CODEOWNER is added

• Major changes to project information, such as in:

  • README.md
  • CONTRIBUTING.md

• Yes. - Link to PR:

• No.

Checklist:

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[srikanthccv]

@seemk I have opened a PR sometime back to add two new env vars to address this problem here open-telemetry/opentelemetry-specification#1453. It is still in review.

[seemk]

@seemk I have opened a PR sometime back to add two new env vars to address this problem here open-telemetry/opentelemetry-specification#1453. It is still in review.

Thanks! Did not notice that 🙂

[ocelotl]

Missing license, I believe.

[lzchen]

@seemk @lonewolf3739
Is this PR and this specs pr still relevant if we complete this for jaeger/zipkin as well?

[srikanthccv]

@seemk @lonewolf3739
Is this PR and this specs pr still relevant if we complete this for jaeger/zipkin as well?

Probably not. Will we have opentelemetry-exporter-jaeger package along with protocol specific packages which includes everything?

[lzchen]

@lonewolf3739

Probably not. Will we have opentelemetry-exporter-jaeger package along with protocol specific packages which includes everything?

I believe we will have protocol specific packages, each taking a dependency on the respective protocol library.

[srikanthccv]

OTEL_EXPORTER_JAEGER_(TLS)CERTIFICATE would still be relevant either way. Do all language SIGs interested in splitting up the Jaeger/Zipkin based on protocol/encoding? If no, OTEL_EXPORTER_JAEGER_PROTOCOL could be part of spec.

[lzchen]

@lonewolf3739
I believe this is up to the language. We just don't want users to take a dependence on a library that they are not interested in using.

I'm not to familiar with jaeger. What is OTEL_EXPORTER_JAEGER_(TLS)CERTIFICATE and how is it relevant to selecting the protocol?

[srikanthccv]

I'm not to familiar with jaeger. What is OTEL_EXPORTER_JAEGER_(TLS)CERTIFICATE and how is it relevant to selecting the protocol?

I should have been more clear. OTEL_EXPORTER_JAEGER_CERTIFICATE is used to specify path to certificate file for TLS credentials of gRPC client. It is not listed here https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/sdk-environment-variables.md#jaeger-exporter. It is only applicable to Jaeger protobuf/gRPC.

[lzchen]

@lonewolf3739
Right, so if we are splitting up the packages, it would only be relevant to the grpc package. I don't think that will affect that decision, and thus this PR is probably not needed anymore correct?

[seemk]

Splitting them up would be a better choice anywyay. Closing this, thanks 🙂