-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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.logging] Remove logging config validation that requires default appender to be present. #97323
[core.logging] Remove logging config validation that requires default appender to be present. #97323
Conversation
Pinging @elastic/kibana-core (Team:Core) |
@@ -36,7 +44,7 @@ logging: | |||
==== Log in json format | |||
|
|||
Log the default log format to json layout instead of pattern (the default). | |||
With `json` layout log messages will be formatted as JSON strings in https://www.elastic.co/guide/en/ecs/current/ecs-reference.html[ECS format] that includes a timestamp, log level, logger, message text and any other metadata that may be associated with the log message itself | |||
With `json` layout log messages will be formatted as JSON strings in https://www.elastic.co/guide/en/ecs/1.9/ecs-reference.html[ECS format] that includes a timestamp, log level, logger, message text and any other metadata that may be associated with the log message itself |
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.
Unrelated to the topic at hand, but figured I would update this while I'm touching the file.
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.
Please note, however, that removing the default appender may break existing logging integrations you have which rely on the legacy Kibana logging format. In particular, if you use the Filebeat Kibana module, we do not recommend removing this setting as it will cause your Kibana logs to be indexed under different field names. The same recommendation applies for folks who have set up other custom integrations with the Kibana logs: keeping the default in place ensures that your logs will not break in 7.x.
IMHO, These are very important caveats and I'd be hesitant to go forward with this until we have approval from Product and the Beats teams to do so. I'd prefer not to rush until we have timeframes from the Beats team and logging use cases that they are taking the necessary steps to migrate to the Kibana logging system configuration.
@TinaHeiligers One alternative here would be to wait on this and try to update the filebeat module to have backwards compatibility with the affected fields (the tags & the log level are the main offenders). If we took an approach like this, we could then release the filebeat update at the same time as this change. I'm not sure how exactly we'd populate the tags, so we'd need to investigate this further to see what's even feasible, but thought I'd raise it as another idea. Still wouldn't solve the issue for folks with a custom integration, though. I don't have strong feelings one way or another on this decision, however I do think it's worth noting that this would still be opt-in, in that by default nobody would have legacy logs taken away. So action would be required before they would get into this situation... today nobody uses the new logging system as we haven't announced it (and I mean literally nobody, according to the telemetry). So it's a question of whether someone is going to take the initiative to update their config in |
💚 Build Succeeded
Metrics [docs]Unknown metric groupsAPI count
API count missing comments
API count with any type
Non-exported public API item count
To update your PR or re-run it, just comment with: cc @lukeelmers |
We're announcing the new logging config in the upcoming 7.13 release. The current implementation enforcing the
I'm okay to wait. Do you have any idea when it will be fixed? The sooner users learn about the changes the more time they have to upgrade their log ingestion pipeline. |
+1 on waiting for filebeat support. Our products should work together without caveats like this. I'm ok with not having compatibility with the |
The issue tracking this is elastic/beats#24136 -- I'll check in to see if there are any timing updates.
This makes sense to me. Since it seems we're all in agreement to wait for filebeat, I'll go ahead and move this back into draft and we can revisit when the time comes. |
cc @mshustov @TinaHeiligers @joshdover As discussed offline, let's use this PR to discuss whether we want to get this change into 7.13, or wait.
Updates the logging config to remove the validation which requires that users of the KP logging system specify a
default
appender for theroot
context.The
default
appender is responsible for forwarding all logs to the legacy logging system to preserve BWC with legacy log formats. The original rationale for enforcing thedefault
appender is present was to ensure that folks don't accidentally break legacy logs when using the new system. The downside of thedefault
appender, however, is that it creates duplicate log entries for every record: one in the legacy format, one in the new format.Now that all of the legacy logging features are available in the new system, we think it would be okay to lift this requirement. Folks who want to opt-in to the new logging system may also opt-out of the legacy one by excluding the
default
appender. And those who need to preserve the legacy formats can keep it in place.One important thing to note here is that filebeat's
kibana
module still relies on the legacy logging format, and will break if users relying on it remove thedefault
appender. The impact here is that the new log format uses different field names, so for filebeat users who have set up dashboards/filters/etc based on these fields, those will no longer work ifdefault
is removed. This situation also applies to anyone who isn't using filebeat but is still relying on the legacy log format for ingesting Kibana logs. I've updated the docs to reflect this.Here's a screengrab showing an example of how the fields differ (These are two different log entries, but you get the idea. Legacy format on the left, new format on the right.)
Plugin API Changes
Kibana's core logging service maintains a
default
logging appender to provide backwards compatibility with our legacy logging format, which will be removed in8.0
. Previously, including thedefault
appender in yourroot
context was a requirement:The downside of this approach was that you would get duplicate entries in your Kibana logs: one in legacy format (via
default
appender), and one in the new format.We have now lifted this requirement for folks who want to fully opt-in to the new system.
Please note, however, that removing the
default
appender may break existing logging integrations you have which rely on the legacy Kibana logging format. In particular, if you use the Filebeat Kibana module, we do not recommend removing this setting as it will cause your Kibana logs to be indexed under different field names. The same recommendation applies for folks who have set up other custom integrations with the Kibana logs: keeping thedefault
in place ensures that your logs will not break in7.x
.