-
Notifications
You must be signed in to change notification settings - Fork 95
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
Features for v3 #275
Comments
Is there anything wrong with: let mut logger = ...;
// ...
logger = logger.new(o!()); ? |
Seems to me like this should be implementable as a 3rd party library. |
|
It doesn't have a separate issue tracker though, so this seemed the right place to discuss. |
Ah, this is about |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problems
Mutable scopes
Typically applications are structured such that there is some scope (eg. a request, a transaction, etc.) in which we want to add some log keys.
However, it is not always the case that these keys are known at the start of the scope (for example, once we have authenticated a request, we want to include the user ID in further logs, but we don't know that at the outset). To solve this, adding keys should be decoupled from beginning a scope.
Boilerplate / interoperability
The "scope" information is not only useful for slog: that information should also be accessible to an applications error-reporting solution, to telemetry systems (eg. statsd) and other tracing systems.
At the moment, this involves duplicating a lot of information as each system wants to own the way these scopes are managed. Pulling keys back out from slog is very painful.
Evaluated keys
The
PushFnValue
andFnValue
types are very useful, but they are not particularly efficient: lets say I have a scoped-thread-local calledTracingCtx
with a bunch of fields, and I want to add these fields to log entries. I have to have a separatePushFnValue
for each field, meaning I have to access the thread-local multiple times per log entry. It would be much more efficient if I could access the thread-local once and emit a sequence of fields.Solution
Instead of converting everything to key-value pairs up-front, integrate with serde. Usage would look something like this:
The text was updated successfully, but these errors were encountered: