-
Notifications
You must be signed in to change notification settings - Fork 742
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-journald: allow custom journal fields #2708
Conversation
`custom_field` implied that the user could set this to anything; instead, the fields here have to be valid journal fields.
…funciton through the search function
This is harmless. We don't need to go way out of our way to prevent the user from deliberately sending strange things to journald. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
@Ralith What now? Waiting for more reviewers? |
Yep, this LGTM so I expect @hawkw will merge once they have time to skim it. |
@Ralith Had to fix the doctest, might need a CI retrigger |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overall, this looks good to me. i think we ought to make sure the behavior with duplicate fields is stated in the docs, though!
@hawkw Thanks :) |
@Finomnis I'm hoping to get a bunch of releases out in the near future, hopefully today or tomorrow. Feel free to ping me if it doesn't happen! |
@hawkw Ping :) |
## Motivation It's currently not possible to customize how messages will get send to journald. This became apparent in #2425, where first a specific API got designed, but then it was decided that users should not get restricted in only a subset of fields, but should be able to simply choose by themselves what fields get set with what values. So in a sense, this is the successor/rework of #2425. ## Solution Allow custom fields to be set in tracing-journald. ## Open Questions - [x] How should we deal with fields that also get supplied by other options? For example, setting `SYSLOG_IDENTIFIER` here and also setting `.with_syslog_identifier()` will send said field twice, potentially with differing values. Is that a problem? - Answer: No, this is not a problem. Closes #2425
## Motivation It's currently not possible to customize how messages will get send to journald. This became apparent in #2425, where first a specific API got designed, but then it was decided that users should not get restricted in only a subset of fields, but should be able to simply choose by themselves what fields get set with what values. So in a sense, this is the successor/rework of #2425. ## Solution Allow custom fields to be set in tracing-journald. ## Open Questions - [x] How should we deal with fields that also get supplied by other options? For example, setting `SYSLOG_IDENTIFIER` here and also setting `.with_syslog_identifier()` will send said field twice, potentially with differing values. Is that a problem? - Answer: No, this is not a problem. Closes #2425
## Motivation It's currently not possible to customize how messages will get send to journald. This became apparent in #2425, where first a specific API got designed, but then it was decided that users should not get restricted in only a subset of fields, but should be able to simply choose by themselves what fields get set with what values. So in a sense, this is the successor/rework of #2425. ## Solution Allow custom fields to be set in tracing-journald. ## Open Questions - [x] How should we deal with fields that also get supplied by other options? For example, setting `SYSLOG_IDENTIFIER` here and also setting `.with_syslog_identifier()` will send said field twice, potentially with differing values. Is that a problem? - Answer: No, this is not a problem. Closes #2425
It's currently not possible to customize how messages will get send to journald. This became apparent in #2425, where first a specific API got designed, but then it was decided that users should not get restricted in only a subset of fields, but should be able to simply choose by themselves what fields get set with what values. So in a sense, this is the successor/rework of #2425. Allow custom fields to be set in tracing-journald. - [x] How should we deal with fields that also get supplied by other options? For example, setting `SYSLOG_IDENTIFIER` here and also setting `.with_syslog_identifier()` will send said field twice, potentially with differing values. Is that a problem? - Answer: No, this is not a problem. Closes #2425
It's currently not possible to customize how messages will get send to journald. This became apparent in #2425, where first a specific API got designed, but then it was decided that users should not get restricted in only a subset of fields, but should be able to simply choose by themselves what fields get set with what values. So in a sense, this is the successor/rework of #2425. Allow custom fields to be set in tracing-journald. - [x] How should we deal with fields that also get supplied by other options? For example, setting `SYSLOG_IDENTIFIER` here and also setting `.with_syslog_identifier()` will send said field twice, potentially with differing values. Is that a problem? - Answer: No, this is not a problem. Closes #2425
It's currently not possible to customize how messages will get send to journald. This became apparent in #2425, where first a specific API got designed, but then it was decided that users should not get restricted in only a subset of fields, but should be able to simply choose by themselves what fields get set with what values. So in a sense, this is the successor/rework of #2425. Allow custom fields to be set in tracing-journald. - [x] How should we deal with fields that also get supplied by other options? For example, setting `SYSLOG_IDENTIFIER` here and also setting `.with_syslog_identifier()` will send said field twice, potentially with differing values. Is that a problem? - Answer: No, this is not a problem. Closes #2425
It's currently not possible to customize how messages will get send to journald. This became apparent in #2425, where first a specific API got designed, but then it was decided that users should not get restricted in only a subset of fields, but should be able to simply choose by themselves what fields get set with what values. So in a sense, this is the successor/rework of #2425. Allow custom fields to be set in tracing-journald. - [x] How should we deal with fields that also get supplied by other options? For example, setting `SYSLOG_IDENTIFIER` here and also setting `.with_syslog_identifier()` will send said field twice, potentially with differing values. Is that a problem? - Answer: No, this is not a problem. Closes #2425
It's currently not possible to customize how messages will get send to journald. This became apparent in #2425, where first a specific API got designed, but then it was decided that users should not get restricted in only a subset of fields, but should be able to simply choose by themselves what fields get set with what values. So in a sense, this is the successor/rework of #2425. Allow custom fields to be set in tracing-journald. - [x] How should we deal with fields that also get supplied by other options? For example, setting `SYSLOG_IDENTIFIER` here and also setting `.with_syslog_identifier()` will send said field twice, potentially with differing values. Is that a problem? - Answer: No, this is not a problem. Closes #2425
@hawkw I guess you are planning to release this as |
# 0.3.1 (November 29, 2024) [ [crates.io][crate-0.3.1] ] | [ [docs.rs][docs-0.3.1] ] ### Changed - disable default features of tracing-subscriber ([#1476]) - allow custom journal fields ([#2708]) - Bump MSRV to 1.63 ([#2793]) - make level mappings configurable ([#2824]) [#1476]: #1476 [#2708]: #2708 [#2793]: #2793 [#2824]: #2824 [docs-0.3.1]: https://docs.rs/tracing-journald/0.3.1 [crate-0.3.1]: https://crates.io/crates/tracing-journald/0.3.1
# 0.3.1 (November 29, 2024) [ [crates.io][crate-0.3.1] ] | [ [docs.rs][docs-0.3.1] ] ### Changed - disable default features of tracing-subscriber ([#1476]) - allow custom journal fields ([#2708]) - Bump MSRV to 1.63 ([#2793]) - make level mappings configurable ([#2824]) [#1476]: #1476 [#2708]: #2708 [#2793]: #2793 [#2824]: #2824 [docs-0.3.1]: https://docs.rs/tracing-journald/0.3.1 [crate-0.3.1]: https://crates.io/crates/tracing-journald/0.3.1
# 0.3.1 (November 29, 2024) [ [crates.io][crate-0.3.1] ] | [ [docs.rs][docs-0.3.1] ] ### Changed - disable default features of tracing-subscriber ([#1476]) - allow custom journal fields ([#2708]) - Bump MSRV to 1.63 ([#2793]) - make level mappings configurable ([#2824]) [#1476]: #1476 [#2708]: #2708 [#2793]: #2793 [#2824]: #2824 [docs-0.3.1]: https://docs.rs/tracing-journald/0.3.1 [crate-0.3.1]: https://crates.io/crates/tracing-journald/0.3.1
Motivation
It's currently not possible to customize how messages will get send to journald.
This became aparent in #2425, where first a specific API got designed, but then it was decided that users should not get restricted in only a subset of fields, but should be able to simply choose by themselves what fields get set with what values.
So in a sense, this is the successor/rework of #2425.
Solution
Allow custom fields to be set in tracing-journald.
Open Questions
SYSLOG_IDENTIFIER
here and also setting.with_syslog_identifier()
will send said field twice, potentially with differing values. Is that a problem?