Add crate/library to pipe C++ Glogs to Tracing

[emersonford]

Feature Request

Motivation

I work in a code base that requires quite a bit of Rust -> C++ interop. I'd love to unify all of the logging that happens in my application (both C++ and Rust) to go through tracing, but the C++ libraries I'm calling into makes extensive use of glog and I don't currently see a way for me to pipe those GLOG log statements to tracing.

It'd be nice to have such functionality available, and I believe it would be a huge win not just for me, but for any Rust-C++ hybrid code bases given how much more powerful tracing is compared to glog. :)

Proposal

Glog already offers a way to register a different "sinks" for its log messages:
https://github.com/google/glog/blob/f545ff5e7d7f3df95f6e86c8cb987d9d9d4bd481/src/glog/logging.h.in#L1794

and this is being used by other alternative logging facilities like folly::logging:
https://github.com/facebook/folly/blob/main/folly/logging/BridgeFromGoogleLogging.cpp

I propose a new crate inside of the main tracing repo that would use cxx.rs to configure tracing as the logging sink for glog (with CXX marshaling the data across the FFI barrier).

Then, from the tracing side, this crate could convert the glog log statements to tracing events identically to how tracing-log currently transforms log statements to tracing events:

• https://github.com/tokio-rs/tracing/tree/master/tracing-log
• https://github.com/tokio-rs/tracing/blob/master/tracing-log/src/log_tracer.rs

As far as I can tell, this would also require changes in tracing_subscriber::fmt to support the same kind of event normalization that is done for tracing-log:

tracing/tracing-subscriber/src/fmt/format/mod.rs

Line 926 in 264a417

let normalized_meta = event.normalized_metadata();

Alternatives

Building this as a standalone crate

I don't see any way of avoiding the same approach taken in tracing-log for this, which means this crate would need the exact same hooks tracing-log has inside of tracing-subscriber. As such, I don't think it's feasible to have this as a standalone crate and would need to be in the main tracing repo with a glog-specific feature added to tracing-subscriber.

However, if tracing-subscriber were to publicly expose the normalized_metadata hooks, could reasonably make this a standalone crate.

Open Questions

1. Is taking a dependency on cxx.rs okay?
2. What's a reasonable way to pull in the glog dependency inside of the crate?
3. Does it sound reasonable to add this to the main tracing repo with feature hooks in tracing-subscriber?

---

I'd like to start working on this myself, but want to make sure my approach sounds reasonable to the tracing maintainers before getting started. :)

[davidbarsky]

I talked to Emerson over chat. In short:

1. I don't think we'd accept this crate inside the main tracing repo, but it's not out of the question to live under the tokio-rs/ organization. In any case, I'd be happy to be a maintainer on it so that the bus factor isn't just Emerson.
2. We don't want to have tracing-subscriber take a dependency on cxx or this crate.
3. glog's arguments appear to be non-'static, so it might be better to integrate via the log crate (which has integrating with non-Rust codebases as an explicit) goal and bridge via glog to tracing via tracing-log.