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

Consider adopting more log fields from ECS #134

Open
ChrsMark opened this issue Jun 26, 2023 · 2 comments
Open

Consider adopting more log fields from ECS #134

ChrsMark opened this issue Jun 26, 2023 · 2 comments
Assignees

Comments

@ChrsMark
Copy link
Member

ChrsMark commented Jun 26, 2023

ECS comes with a list of the following fields for log signal.
We can consider adding some or all of them to the Otel log's schema.

ECS fields

ECS Field ECS Description ECS Level Otel
log.file.path Full path to the log file this event came from, including the file name. It should include the drive letter, when appropriate.If the event wasn’t read from a log file, do not populate this field.type: keywordexample: /var/log/fun-times.log extended log.file.path
log.level Original log level of the log event.If the source of the event provides a log level or textual severity, this is the one that goes in log.level. If your source doesn’t specify one, you may put your event transport’s severity here (e.g. Syslog severity).Some examples are warn, err, i, informational.type: keywordexample: error core severity_text
log.logger The name of the logger inside an application. This is usually the name of the class which initialized the logger, or can be a custom name.type: keywordexample: org.elasticsearch.bootstrap.Bootstrap core
log.origin.file.line The line number of the file containing the source code which originated the log event.type: longexample: 42 extended Zap caller
log.origin.file.name The name of the file containing the source code which originated the log event.Note that this field is not meant to capture the log file. The correct field to capture the log file is log.file.path.type: keywordexample: Bootstrap.java extended Zap caller
log.origin.function The name of the function or method which originated the log event.type: keywordexample: init extended Zap caller (?)
log.syslog The Syslog metadata of the event, if the event was transmitted via Syslog. Please see RFCs 5424 or 3164.type: object extended
log.syslog.appname The device or application that originated the Syslog message, if available.type: keywordexample: sshd extended APP-NAME
log.syslog.facility.code The Syslog numeric facility of the log event, if available.According to RFCs 5424 and 3164, this value should be an integer between 0 and 23.type: longexample: 23 extended FACILITY
log.syslog.facility.name The Syslog text-based facility of the log event, if available.type: keywordexample: local7 extended FACILITY
log.syslog.hostname The hostname, FQDN, or IP of the machine that originally sent the Syslog message. This is sourced from the hostname field of the syslog header. Depending on the environment, this value may be different from the host that handled the event, especially if the host handling the events is acting as a collector.type: keywordexample: example-host extended HOSTNAME
log.syslog.msgid An identifier for the type of Syslog message, if available. Only applicable for RFC 5424 messages.type: keywordexample: ID47 extended MSGID
log.syslog.priority Syslog numeric priority of the event, if available.According to RFCs 5424 and 3164, the priority is 8 * facility + severity. This number is therefore expected to contain a value between 0 and 191.type: longexample: 135 extended
log.syslog.procid The process name or ID that originated the Syslog message, if available.type: keywordexample: 12345 extended
log.syslog.severity.code The Syslog numeric severity of the log event, if available.If the event source publishing via Syslog provides a different numeric severity value (e.g. firewall, IDS), your source’s numeric severity should go to event.severity. If the event source does not specify a distinct severity, you can optionally copy the Syslog severity to event.severity.type: longexample: 3 extended SEVERITY
log.syslog.severity.name The Syslog numeric severity of the log event, if available.If the event source publishing via Syslog provides a different severity value (e.g. firewall, IDS), your source’s text severity should go to log.level. If the event source does not specify a distinct severity, you can optionally copy the Syslog severity to log.level.type: keywordexample: Error extended SEVERITY
log.syslog.structured_data Structured data expressed in RFC 5424 messages, if available. These are key-value pairs formed from the structured data portion of the syslog message, as defined in RFC 5424 Section 6.3.type: flattened extended STRUCTURED-DATA
log.syslog.version The version of the Syslog protocol specification. Only applicable for RFC 5424 messages.type: keywordexample: 1 extended

cc: @AlexanderWert @kaiyan-sheng @mlunadia

@AlexanderWert
Copy link
Member

@ChrsMark In OTel, log.level is modeled as the protobuf fields (severity_number and severity_text) for the logs signal. So, not a semantic conventions attribute.

@jsuereth
Copy link
Contributor

Can you denote which of these is (a) already modeled in OTLP logging signal and (b) already copnsidered in this document: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model-appendix.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants