Add initial documentation for OpenTracing and Jaeger extensions #521
Conversation
|
This documentation refers to a quickstart that is provided in quarkusio/quarkus-quickstarts#20. |
cescoffier
added
kind/enhancement
There was a problem hiding this comment.
@objectiser Apparently, @cescoffier merged it but there are a few things that should be fixed. And a few things that might be improved but feel free to ignore my style comments :)
Could you push another PR with the fixes. Thanks.
| ---- | ||
|
|
||
| Notice that there is no tracing specific code included in the application. By default, requests sent to this | ||
| endpoint will be traced without any code changes being required. It is also possible to enhance the tracing information. For more information on this, please see the https://github.com/eclipse/microprofile-opentracing/blob/master/spec/src/main/asciidoc/microprofile-opentracing.asciidoc[ MicroProfile OpenTracing specification]. |
There was a problem hiding this comment.
Very minor, there's one too many spaces here: [ MicroProfile. It should be [MicroProfile
|
|
||
| The supplied `jvm.args` are used to configure the default OpenTracing tracer (Jaeger). If the `JAEGER_SERVICE_NAME` property is not provided then a "no-op" tracer will be configured, resulting in no tracing data being reported to the backend. The other properties are explained in the https://www.jaegertracing.io/docs/latest/client-features/[Tracer configuration via environment variables] section of the Jaeger documentation. | ||
|
|
||
| NOTE: Currently the tracer can only be configured to report spans directly to the collector via HTTP, using the `JAEGER_ENDPONT` property. Support for using the Jaeger agent, via UDP, will be available in a future version. |
There was a problem hiding this comment.
s/JAEGER_ENDPONT/JAEGER_ENDPOINT/
|
|
||
| NOTE: Currently the tracer can only be configured to report spans directly to the collector via HTTP, using the `JAEGER_ENDPONT` property. Support for using the Jaeger agent, via UDP, will be available in a future version. | ||
|
|
||
| The next step is to startup the tracing system to collect and display the captured traces: |
| docker run -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 | ||
| ---- | ||
|
|
||
| Once both are started, you can request the provided endpoint: |
There was a problem hiding this comment.
I would say Once both the application and the tracing system are started....
|
|
||
| [source, text] | ||
| ---- | ||
| docker run -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 |
There was a problem hiding this comment.
It's not clear when this one is really started, maybe we should add info about that. The user should wait for the Connected to peer message?
There was a problem hiding this comment.
I've moved starting the tracing system as the first step - by the time the user would have started up the app and made the curl request, it would definitely have started - would prefer not to be specific about what log messages to look for.
Co-authored-by: allcontributors[bot] <46447321+allcontributors[bot]@users.noreply.github.com>
No description provided.