Add support for Key-Value data in log records.

[tmccombs]

See rust-lang/log#328

[simao]

Any news on this? Could we at least merge it behind a feature flag or something? Does this need any changes besides a rebase?

[hendrikmaus]

I would also love to start using it.

One good addition to the pull-request would probably be a usage example.

[simao]

I tried these changes and they work well. As far as usage examples go, I think that is done in the log crate? https://docs.rs/log/0.4.16/log/#structured-logging

Users of env_log would just need to use the log/kv_unstable feature, which I suppose should be mentioned somewhere?

One thing I noticed is maybe the target should be written after the kv pairs. Currently we get:

[2022-04-01T08:52:43Z INFO  tide::server] Server listening on http://0.0.0.0:8080
[2022-04-01T08:52:50Z INFO  method=POST path=/sensors/inside_weather status=200 - OK duration=11.487824ms tide::log::middleware] --> Response sent

But IMO the following looks cleaner, since target stays aligned with lines that do not have kv pairs:

[2022-04-01T08:54:12Z INFO  tide::log::middleware method=POST path=/sensors/inside_weather status=200 - OK duration=10.166265ms] --> Response sent

Also wanted to mentioned that it might be worth it to consider putting the structured data in different lines, to improve readability. At least for development, IMO the following looks better:

[2022-04-01T08:57:16Z INFO  tide::server] Server listening on http://0.0.0.0:8080
[2022-04-01T08:57:19Z INFO  tide::log::middleware
    method POST
    path /sensors/inside_weather] <-- Request received
[2022-04-01T08:57:19Z INFO  tide::log::middleware
    method POST
    path /sensors/inside_weather
    status 200 - OK
    duration 10.842409ms] --> Response sent

This is what femme does, and it's just using write!(self.0, "\n {} {}", key, value) in visit_pairs.

Though in production we'd probably want everything on the same line.

[hendrikmaus]

Thanks for pointing to the examples in the log crate. That makes sense.

As to your other points: I'd second both of them.

[svanharmelen]

I was just about to open an issue when I found this PR... It would be awesome if this could be merged so I can keep using env_logger and start using structured logging!

[svanharmelen]

Thanks for the rebase @tmccombs! After using this a little I'm thinking that it would (maybe) be good to make it configurable where the K/V's are written? As I'm used that they are written behind the actual log message instead of in front of it.

When reading a lot of log files that all log a different number of K/V's, you really have to scan al lot to find where the actual message is. If the K/V's are added at the end, all the messages are (more or less) directly above each other 🤷🏻‍♂️

[tmccombs]

I added a commit that moves the Key values behind the rest of the option, and made it configurable whether it is on a single line or on separate lines, as @simao suggested.

[svanharmelen]

Looks really good!! Thanks for your efforts, I'll be using your branch until this gets (hopefully) merged 👍🏻

[prasannavl]

Any reason on what this is blocked on? Would be great to get this merged, even until an experimental flag.

[Fishrock123]

@epage could you enable CI runs on this?

[epage]

@tmccombs at this point my thoughts are

• Mirror what tracing-subscriber does for formatting and control of it
• Rename the feature to unstable-kv, other features are using dashes at this point and I tend to put unstable- first.

[tmccombs]

Mirror what tracing-subscriber does for formatting and control of it

I could use a little more direction on what you are looking for here. I'm guessing you mean have something like the FormatFields trait that would allow custom formatting of the fields?

Should I keep an implementation that uses newlines between each field? It looks liek tracing-subscriber always just includes all the fields on the same line as the main message.

Full and Compact use basically the same syntax for displaying fields, but Pretty is sligtly different (it i uses ": " instead of "=", is that a distinction worth having?)?

[epage]

Hadn't looked into that before. Thanks for listing those considerations. As this is unstable, let's focus on an MVP and just use the formatting they do by default and not provide any configuration. We can then explore in an Issue what our formatting configuration options are, both those from the two PRs and from tracing-subscriber.

[epage]

KvFormatFn also works and fits within the style of the existing API. Thanks!

[tmccombs]

I've resolved conflicts and squashed the commits.

[epage]

Is this a zombie from resolving the merge conflicts?

[tmccombs]

ah, yes it is

[epage]

If you are already going back to make a change, can you you check this on RUSTDOCFLAGS=--cfg=docsrs cargo +nightly doc --all-features (I'm hoping that is correct).

Each API item behind a cfg should have a note in the documentation, like clap::command requiring cargo.

Most likely, you'll need to either duplicate this cfg on the items or move the cfg into the kv mod.

[tmccombs]

Looks like it works as is:

[KodrAus]

Hey all! 👋

Firstly, thank you for picking up and carrying this project forwards 🙏

We're (finally) about to stabilize the key-value support in log (see rust-lang/log#617), making this possible to support in env_logger without needing to fiddle with any unstable feature flags. If you'd like any help finishing off support here please do let me know.

[tmccombs]

I've updated to use the stable version of the log kv feature. Fixed merge conflicts, and fixed the compilation error when the color option is not enabled.