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

Use a common prefix for logged errors #3894

Closed
wants to merge 1 commit into from

Conversation

jtgeibel
Copy link
Member

@jtgeibel jtgeibel commented Sep 6, 2021

The at=error prefix is used for Heroku error messages and using a common prefix aids in metrics collection and is easily searchable. This is the first step in monitoring logged errors discussed further in rust-lang/crates-io-heroku-metrics#3.

r? @pietroalbini

The `at=error ` prefix is used for Heroku error messages and using a
common prefix aids in metrics collection and is easily searchable.
@jtgeibel jtgeibel force-pushed the error-logging-prefix branch from c68b9de to c608802 Compare September 6, 2021 18:03
@Turbo87 Turbo87 added A-backend ⚙️ C-internal 🔧 Category: Nonessential work that would make the codebase more consistent or clear labels Sep 7, 2021
eprintln!(
"at=error mod=git error=\"Resetting index from {} to {}\"",
original_head, head
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if we should use error!(...) instead, and use a custom tracing formatter to produce this output. tracing seems to explicitly be made for this kind of structured logging.

@bors
Copy link
Contributor

bors commented Jan 13, 2022

☔ The latest upstream changes (presumably #4440) made this pull request unmergeable. Please resolve the merge conflicts.

@Turbo87
Copy link
Member

Turbo87 commented Apr 5, 2023

we switched over to using tracing since this PR was opened and we tried out /~https://github.com/EmbarkStudios/tracing-logfmt, but since we're currently not ingesting the logs in a machine readable way there was no benefit compared to the default tracing formatter.

given all that, I guess we can close this PR? let me know if you would like to reopen and still land this :)

@Turbo87 Turbo87 closed this Apr 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-backend ⚙️ C-internal 🔧 Category: Nonessential work that would make the codebase more consistent or clear
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants