Add a minimal tracing-subscriber configuration#104
Merged
dongsupark merged 1 commit intoAzure:mainfrom Jul 16, 2024
Merged
Conversation
While debugging why running azure-init in a local VM hung forever, I
added some minimal log configuration to figure out what was happening.
Note that this only logs to stderr and is only configurable via the
`AZURE_INIT_LOG` environment variable. The most minimal usage is like
this:
AZURE_INIT_LOG=info azure-init
Which emits anything at info level or high. Refer to the
tracing-subscriber documentation[0] for more complex examples.
Logs look like this:
```
2024-07-16T14:41:16.924909Z INFO provision: azure_init: new
2024-07-16T14:41:16.928668Z INFO provision:get_environment: azure_init: new
...
2024-07-16T14:41:17.065528Z INFO provision:get_environment: azure_init: close time.busy=133ms time.idle=4.21ms
2024-07-16T14:41:17.073142Z INFO provision:get_username: azure_init: new
2024-07-16T14:41:17.076323Z INFO provision:get_username: azure_init: close time.busy=23.3µs time.idle=3.16ms
2024-07-16T14:41:17.081070Z INFO provision: azure_init: close time.busy=153ms time.idle=3.12ms
```
It's configured to emit logs when a span opens and closes in addition to
any explicit `tracing::{debug,info,warn,error}!` call, although we can
disable that if folks don't like it. I also added spans to most of the
library functions. All the spans are at the default `INFO` level and the
default log configuration is to write logs for warning or higher, so
running this without specifying `AZURE_INIT_LOG` results in the same
behavior as before.
This doesn't try to integrate with OpenTelemetry or pipe logs to KVP;
those are being wired up in Azure#83.
[0] https://docs.rs/tracing-subscriber/0.3.18/tracing_subscriber/filter/struct.EnvFilter.html#directives
peytonr18
reviewed
Jul 16, 2024
Contributor
peytonr18
left a comment
peytonr18
left a comment
There was a problem hiding this comment.
LGTM! Shouldn't be hard to rebase the KVP with this.
dongsupark
approved these changes
Jul 16, 2024
balakreddy
pushed a commit
to balakreddy/azure-init
that referenced
this pull request
Jul 19, 2024
While debugging why running azure-init in a local VM hung forever, I
added some minimal log configuration to figure out what was happening.
Note that this only logs to stderr and is only configurable via the
`AZURE_INIT_LOG` environment variable. The most minimal usage is like
this:
AZURE_INIT_LOG=info azure-init
Which emits anything at info level or high. Refer to the
tracing-subscriber documentation[0] for more complex examples.
Logs look like this:
```
2024-07-16T14:41:16.924909Z INFO provision: azure_init: new
2024-07-16T14:41:16.928668Z INFO provision:get_environment: azure_init: new
...
2024-07-16T14:41:17.065528Z INFO provision:get_environment: azure_init: close time.busy=133ms time.idle=4.21ms
2024-07-16T14:41:17.073142Z INFO provision:get_username: azure_init: new
2024-07-16T14:41:17.076323Z INFO provision:get_username: azure_init: close time.busy=23.3µs time.idle=3.16ms
2024-07-16T14:41:17.081070Z INFO provision: azure_init: close time.busy=153ms time.idle=3.12ms
```
It's configured to emit logs when a span opens and closes in addition to
any explicit `tracing::{debug,info,warn,error}!` call, although we can
disable that if folks don't like it. I also added spans to most of the
library functions. All the spans are at the default `INFO` level and the
default log configuration is to write logs for warning or higher, so
running this without specifying `AZURE_INIT_LOG` results in the same
behavior as before.
This doesn't try to integrate with OpenTelemetry or pipe logs to KVP;
those are being wired up in Azure#83.
[0] https://docs.rs/tracing-subscriber/0.3.18/tracing_subscriber/filter/struct.EnvFilter.html#directives
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
While debugging why running azure-init in a local VM hung forever, I added some minimal log configuration to figure out what was happening. Note that this only logs to stderr and is only configurable via the
AZURE_INIT_LOGenvironment variable. The most minimal usage is like this:AZURE_INIT_LOG=info azure-init
Which emits anything at info level or high. Refer to the tracing-subscriber documentation[0] for more complex examples.
Logs look like this:
It's configured to emit logs when a span opens and closes in addition to any explicit
tracing::{debug,info,warn,error}!call, although we can disable that if folks don't like it. I also added spans to most of the library functions. All the spans are at the defaultINFOlevel and the default log configuration is to write logs for warning or higher, so running this without specifyingAZURE_INIT_LOGresults in the same behavior as before.This doesn't try to integrate with OpenTelemetry or pipe logs to KVP; those are being wired up in #83.
[0] https://docs.rs/tracing-subscriber/0.3.18/tracing_subscriber/filter/struct.EnvFilter.html#directives