I have certain applications that run jaeger-client when I enable OpenTracing and start them.
First I start Jaeger collector using the command- docker run -d -e COLLECTOR_ZIPKIN_HTTP_PORT=9411 -p 5775:5775/udp -p 6831:6831/udp -p 6832:6832/udp -p 5778:5778 -p 16686:16686 -p 14268:14268 -p 9411:9411 jaegertracing/all-in-one:latest
Then I start the applications like user- start.sh user -apiserver=localhost:9900 -configfile=conf/configuration.json -traceroption enabled=true following which they become visible as enabled services http://localhost:16686/api/services
The problem is that if I kill the Docker running the jaeger collector- systemctl stop docker and later restart docker and jaegertracing/all-in-one, the services are no longer up at http://localhost:16686/api/services
Does the jaeger client die on its own in absence of a Jaeger collector? Does the Jaeger collector needs to be running before starting the Jaeger clients? If so, how can I flush the memory used by Jaeger OpenTracing so that my host doesn't run out of memory?
I wasn't able to find any clear API in RegisterRoutes method of https://github.com/jaegertracing/jaeger/blob/master/cmd/query/app/handler.go
The problem is that if I kill the Docker running the jaeger collector- systemctl stop docker and later restart docker and jaegertracing/all-in-one, the services are no longer up at http://localhost:16686/api/services
That's because you are using the in-memory storage. If you stop and start the container, the storage is reset, so, you'll effectively lose your data. For production purposes, you should use a backing storage like Cassandra or Elasticsearch.
Does the Jaeger collector needs to be running before starting the Jaeger clients?
No, but spans reported by clients when the collector isn't available might get dropped. Note that clients will send spans to the agent by default, and will not contact the collector directly. So, if the agent isn't available, spans might get dropped as well.
how can I flush the memory used by Jaeger OpenTracing so that my host doesn't run out of memory?
Use the configuration option --memory.max-traces. With this option, older traces will get overwritten by new ones once this limit is reached.