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

Tracing with JSON Logging #77

Open
Mythra opened this issue Dec 6, 2020 · 2 comments
Open

Tracing with JSON Logging #77

Mythra opened this issue Dec 6, 2020 · 2 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@Mythra
Copy link
Contributor

Mythra commented Dec 6, 2020

Using this lovely library, and as such I've got a new use case (oh yay!), Currently when telling tracing to log in json by configuring it as such:

let chosen_level = match std::env::var("RUST_LOG_LEVEL").as_ref().map(String::as_str) {
  Ok("off") => LevelFilter::OFF,
  Ok("error") => LevelFilter::ERROR,
  Ok("warn") => LevelFilter::WARN,
  Ok("debug") => LevelFilter::DEBUG,
  Ok("trace") => LevelFilter::TRACE,
  _ => LevelFilter::INFO,
};
let fmt_layer = fmt_layer().with_target(false);
let filter_layer = EnvFilter::from_default_env().add_directive(chosen_level.into());
tracing_subscriber::registry()
				.with(filter_layer)
				.with(fmt_layer.json())
				.with(ErrorLayer::default())
				.init();

let res = get_tasks(project_root_path, etype);
if let Err(reportable /*: Report*/) = res {
  tracing::error!("{:?}", e);
}

you get the following:

{
  "timestamp": "Dec 06 00:39:39.365",
  "level": "ERROR",
  "fields": {
    "message": "\n   0: \u001b[91mpyra::starlark::loop: break used outside of a loop\u001b[0m\n\nLocation:\n   \u001b[35msrc/diagnostic/starlark/critical_semantic.rs\u001b[0m:\u001b[35m42\u001b[0m\n\n \u001b[34m\u001b[1m-->\u001b[0m /home/cynthia/projects/personal/pyra/.github/pyra.star:4:3\n\u001b[34m\u001b[1m  |\u001b[0m\n...\n\u001b[34m\u001b[1m7 |\u001b[0m   break\n\u001b[34m\u001b[1m  |\u001b[0m\u001b[31m\u001b[1m   ^^^^^\u001b[0m \u001b[31m\u001b[1mthe break keyword is reserved, and can ony be used in a loop\u001b[0m\n\u001b[34m\u001b[1m  |\u001b[0m\n\n\u001b[96mSuggestion\u001b[0m: The indentation is less than the line before, perhaps missing an indent?"
  }
}

These are the normal fields as tracing for any log message, and if you notice the main error content is all in "message". I'm curious though if there's a way with a Report object to reverse engineer it back to the "sections"/"notes" that compose that Report'able object so I can say create a json field, one for each section/note/etc. Curious if you have any thoughts?

@yaahc
Copy link
Collaborator

yaahc commented Dec 6, 2020

there are a few ways to approach this imo. We can absolutely make error reports output in json instead of as plain text, the question is when? Do we do it all the time or based on certain formatting flags? I'm not sure if we'd be able to trigger the specific formatting flags we care about when logging via tracing so it may have to be an always on thing, which would mean all errors reported, via tracing or otherwise, would be formatted in json. Would this be okay for your use case?

@Mythra
Copy link
Contributor Author

Mythra commented Dec 6, 2020

Yeah, that's more than fine! It's actually in a similar use case to reporting span traces I filed awhile back. I check an env var RUST_LOG_FORMAT and if it's set to JSON I want the entire output to be JSON (one object per line so it works with things like jq out of the box).

@yaahc yaahc mentioned this issue Feb 4, 2022
@yaahc yaahc added enhancement New feature or request help wanted Extra attention is needed labels Feb 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants