editoast: setup tracing with opentelemetry for TestApp

[hamz2a]

closes #10123

I added the OpenTelemetry layer in TestApp to capture the trace_id set in the header, so we can test the endpoint we'll add in the ticket.

• Refactored init_tracing to accept a custom SpanExporter for better flexibility, including support for testing scenarios.
• Updated main.rs to configure and initialize tracing.
• Modified setup tracing in test_app.rs to use opentelemetry layer.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 86.66667% with 8 lines in your changes missing coverage. Please review.

Project coverage is 81.44%. Comparing base (6a105bf) to head (52acc68).
Report is 1 commits behind head on dev.

Files with missing lines	Patch %	Lines
editoast/src/client/telemetry_config.rs	0.00%	6 Missing ⚠️
editoast/editoast_common/src/tracing.rs	95.34%	2 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev   #10122      +/-   ##
==========================================
+ Coverage   79.93%   81.44%   +1.50%     
==========================================
  Files        1057     1058       +1     
  Lines      106302   104318    -1984     
  Branches      724      724              
==========================================
- Hits        84977    84966      -11     
+ Misses      21283    19310    -1973     
  Partials       42       42              

Flag	Coverage Δ
editoast	73.58% <86.66%> (-0.34%)	⬇️
front	89.19% <ø> (ø)
gateway	2.18% <ø> (ø)
osrdyne	3.28% <ø> (ø)
railjson_generator	87.50% <ø> (ø)
tests	87.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[woshilapin]

Thank you for the PR. Let's see if we can improve it.

[leovalais]

Thanks for this PR. A few comments about architecture and test isolation. Besides, with the context of what you're working on I suppose this is about collecting logs for unit testing, but it's not clear to me how that would work. Why does printing logs on stdout help? Do you plan to capture the stream? A bit more context in the PR description or in the related issue would help.

[hamz2a]

Thanks for this PR. A few comments about architecture and test isolation. Besides, with the context of what you're working on I suppose this is about collecting logs for unit testing, but it's not clear to me how that would work. Why does printing logs on stdout help? Do you plan to capture the stream? A bit more context in the PR description or in the related issue would help.

Apologies for that. I've added more details in the description, and I hope it helps clarify things.

[leovalais]

I added the OpenTelemetry layer in TestApp to capture the trace_id set in the header, so we can test the endpoint we'll add in the #9724.

Thanks for adding some context. So if I get it right, the point is not to necessarily print on stdout, but rather to setup OpenTelemetry so that the request header can be read. The fact that it prints on stdout is irrelevant, or am I missing smth?

I'm surely lacking OpenTelemetry and tracing knowledge, but I still don't understand what setting up a span exporter has to do with reading the HTTP request headers? Especially since the middleware OtelAxumLayer::default() is set in the TestApp.

[hamz2a]

Thanks for adding some context. So if I get it right, the point is not to necessarily print on stdout, but rather to setup OpenTelemetry so that the request header can be read. The fact that it prints on stdout is irrelevant, or am I missing smth?

I'm surely lacking OpenTelemetry and tracing knowledge, but I still don't understand what setting up a span exporter has to do with reading the HTTP request headers? Especially since the middleware OtelAxumLayer::default() is set in the TestApp.

You're right, printing to stdout is irrelevant.
The goal is to have the same init_tracing setup for both editoast webservice and TestApp. That's why I kept the same configuration. @woshilapin, do you confirm?

[woshilapin]

I'm surely lacking OpenTelemetry and tracing knowledge, but I still don't understand what setting up a span exporter has to do with reading the HTTP request headers? Especially since the middleware OtelAxumLayer::default() is set in the TestApp.

@leovalais From what I understand, OtelAxumLayer emits span events, the SpanExporter is used in the subscriber to these events and will consume these span events to export them somewhere (to Datadog, to stdout, etc.). But you're right, we shouldn't need opentelemetry_stdout since we already have the tracing::layer::fmt() configured, which prints to the terminal.

But as said by @hamz2a, one of the main idea of this PR is to have a similar setup of the subscriber for tests and for production code. We had a hard time debugging what was not working and part of it was that it was working well with a cargo run -- runserver but not with cargo test, and some of the problems came from this difference between production code and tests.

[woshilapin]

I believe it's in a much better state now 🚀. Thank you 🎉

[leovalais]

Almost there, thanks for the changes! There's still a dependency order issue, but apart from that, lgtm.

[leovalais]

si je bouge create_tracing_subscriber je dois bouger aussi

   mode: EditoastMode,
   telemetry_config: TelemetryConfig,

Yes, but TelemetryConfig is a clap definition and EditoastMode doesn't make sense outside of the CLI. I'd suggest making a new struct for configuration:

struct TracingConfig {
   stream: enum { Stderr, Stdout },
   telemetry: Option<struct {
		service_name: String,
		telemetry_endpoint: Url
	}>
}

Wdyt?

[leovalais]

LGTM, thanks for all the modifications!