Skip to content
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

Release a build with kv support #616

Closed
3 tasks done
KodrAus opened this issue Feb 20, 2024 · 4 comments · Fixed by #617
Closed
3 tasks done

Release a build with kv support #616

KodrAus opened this issue Feb 20, 2024 · 4 comments · Fixed by #617

Comments

@KodrAus
Copy link
Contributor

KodrAus commented Feb 20, 2024

Now that #613 is merged we have a "stable" API on the main branch that's ready to release. Before we do that, I'd like to run over any related projects we should look at and see whether there are any blocking API concerns (non-blocking additions in log for better support would be ok) we can discover at this last-responsible-moment.

Off the top of my head:

Any others? This isn't a list of all projects that could use log's structured logging support, just those that are likely to need substantial work to integrate and may reveal any design issues.

@KodrAus
Copy link
Contributor Author

KodrAus commented Feb 20, 2024

I did start looking at slog-rs/stdlog and found we'd need to buffer the entire set of key-value pairs from slog before we'd be able to use them as a Source in log. This is because log's Source is borrowing, so you need to be able to get a (Key<'v>, Value<'v>) from a &'v Source. I think we can improve this by supporting some way to stash owned values in Key<'v> and Value<'v>, so we could at least produce (Key<'static>, Value<'static>) from any arbitrary &'_ Source. That's an API addition so isn't blocking.

@KodrAus
Copy link
Contributor Author

KodrAus commented Feb 27, 2024

Proper support in tracing-log will depend on something like tokio-rs/tracing#2048 for proper support, otherwise it'll need to be integrated into the event macros like log support currently is. I can't see the tracing maintainers wanting to integrate with log so directly for much longer though.

If they end up going down the valuable route as their value data model then we should be able to support conversion to and from it. I've spent some time integrating with valuable in the past.

@KodrAus
Copy link
Contributor Author

KodrAus commented Feb 27, 2024

For opentelemetry, they have a value type defined as a proto: https://docs.rs/opentelemetry/latest/opentelemetry/logs/enum.AnyValue.html

I've also written a serde::Serializer in the past that converts any serde::Serialize into an AnyValue, and done the same for sval too so there shouldn't be any trouble integrating there.

@KodrAus
Copy link
Contributor Author

KodrAus commented Feb 27, 2024

So there is something we can potentially improve for slog, but I didn't find any blocking concerns. Which means, I think we're ready to release 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant