You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It sets the default exporter to http://otel-collector:4317, which is gRPC, but then has custom env for most languages to change to http://otel-collector:4318, which is an HTTP endpoint (for receiving either http/proto or http/json).
I haven't been involved much with the OTel Operator, but I wonder if it would consider switching the default for nodejs over to http://otel-collector:4318 as well. I realize that would be a breaking change.
The benefit is that "autoinstrumentation.ts" could just use the NodeSDK defaults, and not have to handle selecting a traceExporter at all. The NodeSDK's envvar handling will do the right thing.
By default the
NodeSDK
will use thehttp/proto
trace exporter. Over timehttp/proto
has become the default OTLP protocol used by most OTel languages. You can see this somewhat from the YAML configuration for the OTel OperatorInstrumentation
given here: https://github.com/open-telemetry/opentelemetry-operator/blob/main/README.md#opentelemetry-auto-instrumentation-injectionIt sets the default exporter to
http://otel-collector:4317
, which is gRPC, but then has custom env for most languages to change tohttp://otel-collector:4318
, which is an HTTP endpoint (for receiving eitherhttp/proto
orhttp/json
).I haven't been involved much with the OTel Operator, but I wonder if it would consider switching the default for
nodejs
over tohttp://otel-collector:4318
as well. I realize that would be a breaking change.The benefit is that "autoinstrumentation.ts" could just use the
NodeSDK
defaults, and not have to handle selecting atraceExporter
at all. The NodeSDK's envvar handling will do the right thing.Originally posted by @trentm in #3413 (comment)
The text was updated successfully, but these errors were encountered: