ZENOTME commented on issue #482: URL: https://github.com/apache/iceberg-rust/issues/482#issuecomment-2267510308
> Some additional context. Renjie mentioned: > > > Cons: > > It's mixing logging with tracing. If we use tracing for logging, our logging compability will not be compatible with logger system. > > This is not quite right. You can use the [tracing_log](https://crates.io/crates/tracing-log) crate to redirect any other crates logs that went to `log` to `tracing`: > > ```rust > use tracing_log::LogTracer; > > // redirects all output sent to log:* to their tracing::* equivalent > LogTracer::init().expect("Failed to set logger"); > ``` > > Regarding metrics, my preference would be either `metrics` or `opentelemetry`. Both are vendor-agnostic with pluggable exporters. My first choice would be opentelemetry as it seems to have better cross-language recognition and a bit more active / vibrant community (I'm basing this on github stars, watchers, number of contributors and commit / merge frequency) I have a question: the [LogTracer](https://docs.rs/tracing-log/latest/tracing_log/struct.LogTracer.html) in tracing_log is used to convert the log record into a trace event. Does this mean that if the user uses log originally and after they introduce iceberg-rust, they have two choices: 1. maintain trace and log separately 2. use trace and redirect all original log records into trace events. For users, is it a more ideal behavior to redirect the trace to the original log? 🤔 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
