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
[v9] Allow custom trace exporter for tsh #19588
Conversation
8174377
to
95149ad
Compare
95149ad
to
523aac3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we first fix the flaky test before backporting the changes to release branches?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the test failure is related to #19597 and not this test itself.
Trace forwarding via `tsh --trace` only works to date if Auth is configured with the `tracing_service` enabled. In all other scenarios the traces are still forwarded to Auth but are silently dropped. This makes it difficult to capture valuable traces from customers with latency issues as they are first required to setup a Telemetry backend and enable tracing in their cluster. A new `--trace-exporter` flag is added to `tsh` to make it possible to direct traces from `tsh` to a file or local instance of jaeger without hacing to modify their Teleport cluster. The url must follow the same semantics as the config file equivalent. One important caveat is that **only** the `tsh` spans will be captured. Any corresponding `teleport` spans are exported acording to the `tracing_service`. While this only paints half the picture, it is still a good indicator of where `tsh` may be experiencing latency. An example usage to send traces to local files: ```bash tsh --trace --trace-exporter=file:///some/path/traces ssh user@foo ```
88c3495
to
ee86240
Compare
Backport #19405 to branch/v9