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

[Core] Logs in JSON layout follow ECS format #90406

Closed
mshustov opened this issue Feb 5, 2021 · 2 comments · Fixed by #96350
Closed

[Core] Logs in JSON layout follow ECS format #90406

mshustov opened this issue Feb 5, 2021 · 2 comments · Fixed by #96350
Assignees
Labels
Feature:Logging Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc

Comments

@mshustov
Copy link
Contributor

mshustov commented Feb 5, 2021

Log records emitted in JSON layout contain meta key with additional information (HTTP request/response, process identifier) attached:

meta: {
version: {
from: 'v7',
to: 'v8',
},
},

This structure doesn't follow ECS format. The logging system should restructure additional information from meta key to ECS format as close as possible:
before:

meta: {
  http: {
    request: {
      method: 'GET'
    },
  }
}

after:

http: {
  request: {
    method: 'GET'
  },
}
@mshustov mshustov added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Feature:Logging labels Feb 5, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-core (Team:Core)

@lukeelmers
Copy link
Member

The logging system should restructure additional information from meta key to ECS format as close as possible:

Looking at this more closely, it seems we are already merging the meta with the rest of the json log, however we should still be trying to nudge devs toward including proper ECS-compliant meta in their logs.

We discussed the following plan to address this:

  • We will make a full set of ECS typings to enforce on the meta field, with a catch-all to accommodate custom fields
    • Could consider forcing everyone to include the ECS version in their meta, will look into how many problems this would cause
    • Long-term we will consider whether it's worth officially supporting ECS types out of core
  • Look into renaming meta to something more obvious like ecsMeta & audit usage of log meta across Kibana
  • Include special handling for "reserved" keys that should not be overwritten, like timestamp, message, log level
    • In some cases, like someone putting an error object in the meta, preserving the message could be important
    • We should look at whether we can somehow "quarantine" conflicting items in their own custom key so they don't get lost

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Logging Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants