[open-telemetry/transport-grpc] Endpoint has to contain scheme, host and path
If I use the gRPC protocol in conjunction with Jaeger (direct export without collector), according to the documentation it should be enough to use the address without path (https://opentelemetry.io/docs/instrumentation/php/exporters/).
However, without path it will not pass the validation in grpcTransportFactory:
if (substr_count($parts['path'], '/') !== 2) { throw new InvalidArgumentException(sprintf('Endpoint path is not a valid GRPC method "%s"', $method)); }
On the other hand, when I add path to the address, it fails on the fact that it doesn't know the service name. However the service for Jaeger should be created automatically.
My env settings:
OTEL_PHP_AUTOLOAD_ENABLED=true OTEL_TRACES_EXPORTER=otlp OTEL_METRICS_EXPORTER=none OTEL_LOGS_EXPORTER=none OTEL_EXPORTER_OTLP_PROTOCOL=grpc OTEL_EXPORTER_OTLP_TRACES_ENDPOINT="http://jaeger:14250" OTEL_PROPAGATORS=baggage,tracecontext
You are using OTEL_EXPORTER_OTLP_TRACES_ENDPOINT, which per spec is used unchanged, so you'll need to append a path of /opentelemetry.proto.collector.trace.v1.TraceService/Export. Alternatively, try switching to the OTEL_EXPORTER_OTLP_ENDPOINT var with your current value.
What path did you add to the address when it complained about service name? I'm using the collector rather than straight to jaeger, but it looks happy with this value: OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://collector:4317/opentelemetry.proto.collector.trace.v1.TraceService/Export
Thank you, the path you mentioned works. It wasn't exactly clear to me from the documentation how to set up the path. I am closing this issue as it is not a bug.
@brettmc However, I'm still confused about this, I'm now testing the implementation directly with the collector:
env:
OTEL_PHP_AUTOLOAD_ENABLED=true OTEL_TRACES_EXPORTER=otlp OTEL_EXPORTER_OTLP_PROTOCOL=grpc OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://otel-collector:4317/opentelemetry.proto.collector.trace.v1.TraceService/Export OTEL_PROPAGATORS=baggage,tracecontext
OTEL config:
receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317
processors:
exporters: prometheus: endpoint: 0.0.0.0:55680 namespace: default zipkin: endpoint: http://zipkin:9411/api/v2/spans service: pipelines: traces: receivers: [otlp] processors: [] exporters: [zipkin] metrics: receivers: [otlp] processors: [] exporters: [prometheus]
container
otel-collector: image: otel/opentelemetry-collector-contrib volumes:
- ./otel-collector-config.yaml:/etc/otelcol-contrib/config.yaml ports:
- "55680:55680" # Prometheus
- "4317:4317" # GRPC
At this setting, it will return to me:
unknown service opentelemetry.proto.collector.trace.v1.TraceService
If, on the other hand, I use a generic endpoint as you suggested, I get:
Error during opentelemetry initialization: Endpoint has to contain scheme, host and path #0 /app/vendor/open-telemetry/exporter-otlp/SpanExporterFactory.php(56): OpenTelemetry\Contrib\Grpc\GrpcTransportFactory->create('otel-collector:...', 'application/x-p...', Array, > 'none')
If, on the other hand, I use a generic endpoint as you suggested
To use the generic endpoint, you must put it in the OTEL_EXPORTER_OTLP_ENDPOINT variable, then a factory will take care of appending the path for each signal. Is that what you're doing?
unknown service opentelemetry.proto.collector.trace.v1.TraceService
This is an interesting error. AFAICT, it means that a successful grpc connection was made (ie, to otel-collector:4317), but the endpoint is not known to the service. I've seen that before with people trying to send signals to a backend that doesn't understand or has not implemented it (eg trying to send logs or metrics to jaeger), but the collector understands all of the signals...
Is anything interesting logged by the collector?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.