ENV_VAR for where to send spans

[naseemkullah]

Hello,
an env var for agent "host" would be nice

In JS/open-census for example, i need this in my code, but could there already be a default "TRACING_AGENT_HOST" ?...

const exporter = new JaegerTraceExporter({
  host: process.env.OT_COLLECTOR_HOST || 'localhost',
});

... if there was a default env var I would set it ` and I could just have in code:

const exporter = new JaegerTraceExporter();

because in k8s, if using the AGENT is running as a daemonset we need to do something like this for the workload:

env:
- name: OT_COLLECTOR_HOST
  valueFrom:
    fieldRef:
      fieldPath: status.hostIP

Thank you

[SergeyKanzhelev]

Is the host similar to Resource API? Maybe dup with the #61

[SergeyKanzhelev]

In OpenCensus it's described here: https://github.com/census-instrumentation/opencensus-specs/blob/master/resource/Resource.md#from-environment-variables

[bogdandrutu]

No activity from the author, I will close this. Please re-open and answer the questions if you still need this feature.

[Oberon00]

It's maybe a bit harsh to close this on Monday when the last question was on Friday.

[bogdandrutu]

Sorry did not see when was asked, so only when the issue was posted. you are correct.

[naseemkullah]

Everything is in original post if anything is unclear please let me know.

[SergeyKanzhelev]

Can you please take a look if resource API is what you are looking for.

Is the host similar to Resource API? Maybe dup with the #61
In OpenCensus it's described here: https://github.com/census-instrumentation/opencensus-specs/blob/master/resource/Resource.md#from-environment-variables

[naseemkullah]

The agent host is where the agent runs to send spans to.

[naseemkullah]

Not sure tbh can you define the agent host with the resource API?

[SergeyKanzhelev]

@naseemkullah I got it. You mean this agent/collector: https://github.com/open-telemetry/opentelemetry-collector

There is a quite similar issue that calls for standardizing of a configuration: #142

[naseemkullah]

@naseemkullah I got it. You mean this agent/collector: https://github.com/open-telemetry/opentelemetry-collector

Yes exactly, the agent in particular.

There is a quite similar issue that calls for standardizing of a configuration: #142

Should we merge the issues then?

something like OTEL_COLLECTOR_HOST could be a good variable.

Please see https://github.com/jaegertracing/jaeger-client-node#environment-variables for an example of what is desired (JAEGER_AGENT_HOST can also be configured directly in exporter config)

[naseemkullah]

I think this can be as simple as telling our Jaeger exporter to look for JAEGER_HOST or JAEGER_AGENT_HOST or what have you env var, and then default to localhost if none is set.

A similar thing can be done for each exporter.

[naseemkullah]

Maybe a generic OT_COLLECTOR variable that is understood by all exporters could be good, (alongside exporter specific env vars such as JAGER_AGENT_HOST if not using the opentelemetry collector).

From my understanding the collector can run as an agent/sidecar (so default value to localhost) or standalone service as per the recent kubecon talk by @SergeyKanzhelev and @mtwo

As a side note I am a little confused by the difference between Jaeger's approach to distinguish agent and collector (the use of both of these) vs opentelemtry's one or the other approach (either collector sidecar or collector service)... @yurishkuro could you kindly chime in here?

[yurishkuro]

Jaeger agent allows SDKs to have minimal requirements, e.g. no RPC framework is needed to submit the spans to the agent, and SDKs don't need to have manual configuration across all applications, such as the address of the collectors (because agents are always available on localhost).

[jmacd]

When using OTLP, it would be nice if there is a default across OTel client libraries that uses localhost and a standard port to support zero configuration by default. An environment variable to specify a remote OTLP endpoint would be nice when the destination is not local.

[naseemkullah]

Jaeger agent allows SDKs to have minimal requirements, e.g. no RPC framework is needed to submit the spans to the agent, and SDKs don't need to have manual configuration across all applications, such as the address of the collectors (because agents are always available on localhost).

Actually there is a case where Jaeger agents are not available on localhost, in the case of kubernetes where the jaeger-agent is run as a daemonset (as opposed to sidecar), it must be set as follows in the app's pod spec:

env:
- name: JAEGER_AGENT_HOST
  valueFrom:
    fieldRef:
      fieldPath: status.hostIP

[naseemkullah]

I guess every exporter should have some standard env var for a host to look for when it is not localhost. In the case of the opentelemetry collector it should be OTEL_COLLECTOR_HOST and for Jaeger exporter it should be JAEGER_AGENT_HOST

[naseemkullah]

We've added JAEGER_AGENT_HOST as an env var for the Jaeger Exporter in JS as per open-telemetry/opentelemetry-js#924. It would be nice that other languages follow suit.

As for the otel collector, can we decide on an env var? OT_COLLECTOR_HOST or OTEL_COLLECTOR_HOST ?

[naseemkullah]

This should be addressed via #572