-
Notifications
You must be signed in to change notification settings - Fork 0
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
feat: Add OpenTelemetry setup function #11
base: main
Are you sure you want to change the base?
Conversation
7eb6574
to
181e5cf
Compare
Codecov ReportAttention: Patch coverage is
✅ All tests successful. No failed tests found.
Additional details and impacted files@@ Coverage Diff @@
## main #11 +/- ##
===========================================
+ Coverage 67.24% 77.80% +10.55%
===========================================
Files 5 8 +3
Lines 232 491 +259
===========================================
+ Hits 156 382 +226
- Misses 76 109 +33
... and 1 file with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
2cc3d5e
to
9f45534
Compare
We should probably guard this behind cargo feature |
3bb5329
to
4c1d1df
Compare
7e9a05f
to
ac11152
Compare
06f3601
to
5ad809d
Compare
What's the difference between stdout layer and logs layer? |
5ad809d
to
e355992
Compare
the stdout layer only logs to the stdout and the logs layer only exports the logs to and otel collector |
ea95e16
to
85d0e49
Compare
f8994cd
to
c7bf78c
Compare
9f8bb11
to
31bd81d
Compare
c899ea2
to
4dce311
Compare
ea2004a
to
cc1cd81
Compare
3ce66fe
to
5f81383
Compare
5f81383
to
f21c2ab
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.
LGTM aside from few cosmetic nits
|
||
For setup all that's needed it to run the function `famedly_rust_utils::famedly_rust_utils::telemetry::init_otel`. The function returns a guard that takes care of properly shutting down the providers. | ||
|
||
If no configuration is present the exporting of logs traces and metrics is disable and the stdout logging is enable. |
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.
If no configuration is present the exporting of logs traces and metrics is disable and the stdout logging is enable. | |
If no configuration is present the exporting of logs traces and metrics is disabled and the stdout logging is enabled. |
} | ||
|
||
impl ProviderConfig { | ||
#[allow(clippy::expect_used)] |
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.
#[allow(clippy::expect_used)] |
self.logger_provider.as_ref().inspect(|logger_provider| { | ||
if let Err(err) = logger_provider.shutdown() { | ||
tracing::error!("Could not shutdown LoggerProvider: {err}"); | ||
} | ||
}); |
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.
IMHO: I think it makes more sense for if let
syntax on self
fields as it's more about flow control, while inspect
and inspect_err
semantially are more about "inspection", about some side effects that are not part of general flow, like tracing. Feel free to disagree, I would just write it like this:
self.logger_provider.as_ref().inspect(|logger_provider| { | |
if let Err(err) = logger_provider.shutdown() { | |
tracing::error!("Could not shutdown LoggerProvider: {err}"); | |
} | |
}); | |
if let Some(logger_provider) = self.logger_provider.as_ref() { | |
logger_provider.shutdown().inspect_err(|err| | |
tracing::error!("Could not shutdown LoggerProvider: {err}") | |
) | |
}; |
The functions on the crate exporting opentelemetry traces should be annotated with `tracing::instrument` to generate a new span for that function. Documentation on this macro can be found on the [here](https://docs.rs/tracing/latest/tracing/attr.instrument.html) | ||
|
||
The opentelemetry information is exported using gRPC to and opentelemetry collector. By default the expected endpoint is `http://localhots:4317` | ||
The default level of logging and traces is `info` and the default filter directive is `opentelemetry=off,tonic=off,h2=off,reqwest=info,axum=info,hyper=info,hyper-tls=info,tokio=info,tower=info,josekit=info,openssl=info` |
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.
This part is outdated, I suppose
|
||
### Propagate the context | ||
|
||
A context can be propagated to allow linking the traces from two different services. This is done by injecting the context information on the request and retrieving it on the other service. |
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.
A context can be propagated to allow linking the traces from two different services. This is done by injecting the context information on the request and retrieving it on the other service. | |
A context can be propagated to allow linking the traces from two different services. This is done by injecting the context information into the request and retrieving it in another service. |
Still not sure if this is gramatically correct :/
|
||
#### reqwest | ||
|
||
For injecting the current context using the reqwest client we can warp a client on a [reqwest-middleware](https://crates.io/crates/reqwest-middleware) and use the `OtelMiddleware` middleware present on the crate. |
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.
For injecting the current context using the reqwest client we can warp a client on a [reqwest-middleware](https://crates.io/crates/reqwest-middleware) and use the `OtelMiddleware` middleware present on the crate. | |
For injecting the current context using the reqwest client we can wrap a client in a [reqwest-middleware](https://crates.io/crates/reqwest-middleware) and use the `OtelMiddleware` middleware present in this crate. |
|
||
### Metrics | ||
|
||
For adding metrics all that it's needed it to make a trace with specific prefix. The documentation on how it works is [here](https://docs.rs/tracing-opentelemetry/latest/tracing_opentelemetry/struct.MetricsLayer.html#usage) |
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.
For adding metrics all that it's needed it to make a trace with specific prefix. The documentation on how it works is [here](https://docs.rs/tracing-opentelemetry/latest/tracing_opentelemetry/struct.MetricsLayer.html#usage) | |
For adding metrics all that is needed is to make a trace with specific prefix. The documentation on how it works is [here](https://docs.rs/tracing-opentelemetry/latest/tracing_opentelemetry/struct.MetricsLayer.html#usage) |
|
||
For adding metrics all that it's needed it to make a trace with specific prefix. The documentation on how it works is [here](https://docs.rs/tracing-opentelemetry/latest/tracing_opentelemetry/struct.MetricsLayer.html#usage) | ||
|
||
For adding metrics to axum servers creates like [tower-otel-http-metrics](https://github.com/francoposa/tower-otel-http-metrics) |
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.
For adding metrics to axum servers creates like [tower-otel-http-metrics](https://github.com/francoposa/tower-otel-http-metrics) | |
For adding metrics to axum servers see crates like [tower-otel-http-metrics](https://github.com/francoposa/tower-otel-http-metrics) |
This PR adds a function to setup the Opentelemetry exporting for logs, traces and metrics.
This function will setup everything, all that will be left to do on the services is to setup the propagation layer (example for axum) and configure the
#[instrument]
macro on the functions.For metric I setup to use the traces for metrics using the crate tracing-opentelemetry. Other options are the opentelemetry sdk itself, and the metrics.
The metrics doesn't seem to have an opentelemtry exporter but it does have an prometheus exporter. If we choose to use an collector that supports both, otel and prometheus endpoints, like grafana alloy, the metrics crate can also be an option