-
Notifications
You must be signed in to change notification settings - Fork 71
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
confgenerator : Add otel logging support for systemd_journald
receiver.
#1872
base: master
Are you sure you want to change the base?
Conversation
6e369a7
to
c731e31
Compare
systemd_journald
receiver.systemd_journald
receiver.
}) | ||
} | ||
|
||
func testSystemdLog(t *testing.T, otel bool) { |
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.
I'd like to see this actually test the schema of the log entries, instead of just testing that one exists.
Probably that means we should send a particular canary message to journald and then check how it is represented in Cloud Logging.
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.
I added a canary
with different explicitly set priorities (e.g. INFO
, ERROR
) and verified the resulting message in Cloud Logging matches the expected schema. I'm thinking of ways this test could be improved (e.g. check the CODE_LINE, more priorities ... ).
32e04b0
to
af35993
Compare
eb0751e
to
f485480
Compare
…ectly at the moment.
f485480
to
7416dee
Compare
Fields: map[string]*ModifyField{ | ||
`severity`: { | ||
CopyFrom: "jsonPayload.PRIORITY", | ||
// This mapping sets SeverityText in otel logs data model which naming differs from Cloud Logging model. |
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.
We should be accepting the Cloud Logging values in severityText. Users can be writing this field directly, either with their own modify_fields or directly with JSON, and they can filter on those values. I think we should try to get this fixed in the exporter.
Note that the OTel spec allows (and encourages) arbitrary strings as severityText: https://opentelemetry.io/docs/specs/otel/logs/data-model/#severity-fields
For now I'd put this back to LogSeverity, change the test to only use severities where the name matches, and then file a bug to add support for the rest of the severities in the exporter.
Description
Add otel logging support for
systemd_journald
receiver.Related issue
b/394593541
How has this been tested?
Checklist: