1. Output of
root@n311:~# docker compose exec caddy caddy version
2. How I run Caddy:
a. System environment:
- Ubuntu 20.04.4 LTS
- Docker 20.10.17
- Docker compose v2.6.1
c. Docker compose file
d. My complete Caddy config:
# Compress responses according to Accept-Encoding headers
encode gzip zstd
3. The problem I’m having:
No spans are visible in the Jaeger UI. Tested multiple configs but couldn’t find a working one. Jaeger is deployed on a VPS using the all-in-one docker image, using the example command:
docker run -d --name jaeger \
-e COLLECTOR_ZIPKIN_HOST_PORT=:9411 \
-e COLLECTOR_OTLP_ENABLED=true \
-p 6831:6831/udp \
-p 6832:6832/udp \
-p 5778:5778 \
-p 16686:16686 \
-p 4317:4317 \
-p 4318:4318 \
-p 14250:14250 \
-p 14268:14268 \
-p 14269:14269 \
-p 9411:9411 \
I tried the following configs:
4. Error messages and/or full log output:
gRPC protocol config yields this error, hinting that the INSECURE parameter is ignored
root-caddy-1 | 2022/08/04 08:08:53 max retry time elapsed: rpc error: code = Unavailable desc = connection error: desc = "transport: authentication handshake failed: tls: first record does not look like a TLS handshake"
HTTP protocol config (using both json and protobuf) yields this error:
root-caddy-1 | 2022/08/04 08:10:05 max retry time elapsed: rpc error: code = Unavailable desc = connection closed before server preface received
5. What I already tried:
Configs posted above.
6. Links to relevant resources:
caddy source shows that only the
otlptracegrpc exporter is implemented, so expecting that only gRPC will work
prometheus had a similar bug that was fixed in this PR
maybe I can use another instance of Caddy as a gRPC reverse proxy in front of the Jaeger docker container and let Caddy issue an SSL certificate.
I think you need to configure
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT as per the docs example:
FYI @andriikushch if you could take a look at this, since you implemented this feature!
tried this (along with the other INSECURE variables), same outcome. I also tried setting the endpoint to a non-existing domain and then I got a DNS resolver error message, so I know that the environmental variables set in docker-compose.yml indeed are visible by Caddy.
My plan is to add a reverse proxy in front of Jaeger for SSL termination and then it should all work. But if the insecure option can be enabled, that’d definitely be easier
Hi @francislavoie , @tobias0289
I will be at my PC on Monday and can take a look.
I tried to run caddy/jaeger with the following config:
docker run -d --name jaeger -e COLLECTOR_ZIPKIN_HOST_PORT=:9411 -e COLLECTOR_OTLP_ENABLED=true -p 6831:6831/udp -p 6832:6832/udp -p 5778:5778 -p 16686:16686 -p 4317:4317 -p 4318:4318 -p 14250:14250 -p 14268:14268 -p 14269:14269 -p 9411:9411 jaegertracing/all-in-one:1.37
respond "Hello, world!"
encode gzip zstd
After I executed:
$ curl -D- localhost:80
HTTP/1.1 200 OK
Date: Mon, 08 Aug 2022 10:28:00 GMT
I was able to see, trace information on UI (http://localhost:16686/search in my case).
I would suggest we try the following:
- Could you please double-check the port in your configuration (
- Try to verify connectivity between the caddy container and jaeger. For example execute from caddy container
telnet <jaeger-ip> 4317.
- Please add
to the caddy’s docker-compose file and try to send a request.
- After, please provide a full log from the jaeger and caddy containers.
I hope we will see a reason in the logs
Weird, I thought I basically already used that configuration… I copy/paste’d your environmental variables and it worked right away! Thanks a ton!!!
It seems like the difference was
4318 (what you used) and
4317. You did try that port, but it looks like you used
https:// there which might’ve been the problem.