-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: jaeger-query connection refused on 4317 #4680
Comments
So the issue is with helm chart not registering the port correctly? |
sorry, didn't see it right, actually we still have the same connection being stablished on
the only difference to previous versions of the jaeger-query is the additional grpc call to
|
I see, I think what happened is that previously jaeger-query was using Jaeger SDK that defaulted to UDP exporter, which did not log errors if there was nothing listening on the corresponding UDP port. But now that we switched to the OTEL SDK it defaults to gRPC exporter which does fail when there is no received. We did not notice it before the release since all-in-one does have the receiver. If you have a jaeger-collector in your installation, you can pass its address via OTEL_EXPORTER_OTLP_TRACES_ENDPOINT. Perhaps by default jaeger-query should not be instantiating a real tracer unless the user has opted in. Also, OTEL_TRACES_EXPORTER allows |
## Which problem is this PR solving? Resolves #4680 ## Description of the changes - Add an opt-in option `--query.enable-tracing` to enable tracing for the jaeger-query component. - The jaeger all-in-one component does not expose this flag since traces are emitted to port 4317 by default, which all-in-one listens on. ## How was this change tested? ``` # Run jaeger-query component with tracing enabled and verify that the connection errors are appearing in stdout. $ SPAN_STORAGE_TYPE=memory go run -tags ui ./cmd/query/main.go --query.enable-tracing ... {"level":"info","ts":1692363754.9049716,"caller":"grpc/clientconn.go:1301","msg":"[core][Channel #1 SubChannel #2] Subchannel Connectivity change to CONNECTING","system":"grpc","grpc_log":true} {"level":"info","ts":1692363754.9050152,"caller":"grpc/clientconn.go:1414","msg":"[core][Channel #1 SubChannel #2] Subchannel picks a new address \"localhost:4317\" to connect","system":"grpc","grpc_log":true} {"level":"warn","ts":1692363754.9058733,"caller":"grpc/clientconn.go:1476","msg":"[core][Channel #1 SubChannel #2] grpc: addrConn.createTransport failed to connect to {Addr: \"localhost:4317\", ServerName: \"localhost:4317\", }. Err: connection error: desc = \"transport: Error while dialing: dial tcp 127.0.0.1:4317: connect: connection refused\"","system":"grpc","grpc_log":true} {"level":"info","ts":1692363754.9067123,"caller":"grpc/clientconn.go:1303","msg":"[core][Channel #1 SubChannel #2] Subchannel Connectivity change to TRANSIENT_FAILURE, last error: connection error: desc = \"transport: Error while dialing: dial tcp 127.0.0.1:4317: connect: connection refused\"","system":"grpc","grpc_log":true} ... # Run jaeger-query component with tracing disabled and verify that the connection errors no longer appear. # Of course, we can't see traces in Jaeger UI because there's nothing to receive the traces. $ SPAN_STORAGE_TYPE=memory go run -tags ui ./cmd/query/main.go # Start an all-in-one instance just as a quick and dirty way to bring up an in-memory jaeger stack to # receive traces from jaeger-query $ make run-all-in-one # Run jaeger-query as a separate component, listening on different ports to all-in-one to avoid port binding collisions. $ SPAN_STORAGE_TYPE=memory go run -tags ui ./cmd/query/main.go --query.enable-tracing --query.grpc-server.host-port :17685 --query.http-server.host-port :17686 --admin.http.host-port :17687 # Open localhost:17686 in a browser and refresh a few times to emit traces to jaeger all-in-one. ``` Confirmed that `jaeger-query` is visible and contains traces: <img width="1572" alt="Screenshot 2023-08-18 at 11 45 26 pm" src="https://github.com/jaegertracing/jaeger/assets/26584478/a348e804-6d37-49f9-9d9f-f73854e9b6bc"> ## Checklist - [x] I have read https://github.com/jaegertracing/jaeger/blob/master/CONTRIBUTING_GUIDELINES.md - [x] I have signed all commits ~- [] I have added unit tests for the new functionality~ - [x] I have run lint and test steps successfully - for `jaeger`: `make lint test` - for `jaeger-ui`: `yarn lint` and `yarn test` --------- Signed-off-by: albertteoh <[email protected]>
What happened?
After upgrading to v1.48.0 noticed that jaeger-query is trying to connect to port
4317
locally but this port is not exposed when running on a separate pod (not as part of the all-in-one setup).Steps to reproduce
4317
Expected behavior
Compared to previous versions of jaeger-query there seems to be an additional grpc call to
4317
which fails, but don't know exactly what's its purpose. It might be a default connection to a local OTEL collector to send traces, if that's the case it should be possible to provide a different endpoint or just disable it.Relevant log output
Jaeger-query logs:
Jaeger-query listening ports:
Screenshot
No response
Additional context
No response
Jaeger backend version
1.48.0
SDK
No response
Pipeline
No response
Stogage backend
No response
Operating system
Linux
Deployment model
Kubernetes
Deployment configs
The sample
values.yaml
could be used to deploy this setup and reproduce the issue:Steps to install:
The text was updated successfully, but these errors were encountered: