-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
[filebeat] Upgrade Kibana module to prepare for 8.0 breaking changes #24136
Comments
Pinging @elastic/integrations-services (Team:Services) |
The impact here (from a Beats perspective) is on the @lukeelmers what's the plan for Kibana logs through the deprecation period? Will each log entry contain both sets of fields (legacy + new)? Or are the new logs being written to a separate file along side the legacy ones (if so, how would this work in a containerized environment where logs might be emitted to STDOUT)? Or something else? |
cc: @sayden |
@ycombinator @sayden The short answer is that there are duplicate log entries (one in new & one in old format).
The deprecation strategy looks like this:
Example log snippets7.x through 7.last - using old/deprecated configjson
stdout
7.x through 7.last - using new configjson
stdout
8.0json
stdout
Technically Kibana has shipped for the last several minors with the behavior described above (both formats alongside each other), however in practice folks will most likely have not seen any change as we haven't yet communicated to users that the legacy settings are deprecated. That's what will be changing in 7.13 -- users will start to see the warnings and switch over to the new configs, and then start to get the duplicate entries. As the entries are duplicates, that means users can safely throw away/ignore the new format until 8.0 and not lose any data. |
One other thing to add: The new logs will be ECS compliant after we address elastic/kibana#90406, so hopefully that makes things easier 🙂 |
Thanks for all the details, including sample log snippets, @lukeelmers — super helpful! @sayden let me know if you have any questions about handling any of this from the Filebeat |
Hey @sayden, just wanted to follow up now that we've closed elastic/kibana#90406. At this point we are considering our new logging system "done". Do you have any idea yet where this might fall on the Beats roadmap? One thing we are hoping to do soon is lift the requirement that folks log everything to both the legacy and the new system. Currently we force everything to still be logged to the legacy system for backwards compatibility, however we'd like to allow folks to opt-out of the legacy system when they are ready to do so. Ideally we'd do this soon in 7.x to give folks as much time as possible to shift to the new system and ensure a smooth 8.0 upgrade. We decided that we want to wait to lift this restriction until the filebeat module is ready (see discussion on this PR), so let me know if there's any further resources we could provide to ensure you have all the info you need. We have updated the Kibana docs with details, including a general overview and a guide on migrating to the new system. The planned breaking changes have also been documented in our 8.0 breaking changes docs. Lastly, I've put together a 30 minute crash course screencast which demonstrates some of the changes, including a look at how the log formats differ. I'd be happy to sync if you want to chat about any of this or have questions -- feel free to ping me. 🙂 |
Just checking in to see if this was still in the works, as we are planning to remove the legacy logging format from Kibana's Don't hesitate to reach out if any questions come up! |
@elastic/integrations-services just a heads up that we are planning on merging the breaking changes to Kibana's master branch in the next week or two -- we will follow up soon with an exact date. Are these changes in progress on your side? |
Was just talking to @yspotts on the Cloud team, and learned that these changes to Filebeat will be a blocker to Cloud's ability to update to support the new logging system. In addition to the near-term goal of supporting 8.0, Cloud will eventually aim to support the new log format in 7.16 (as this will help us greatly for debugging purposes). While this won't necessarily need to coincide with the 7.16 release on Cloud's side -- they can add support after the fact -- they would still require a 7.16-compatible version of Filebeat to be able to handle the new format. The implication here is that Beats would need to support both formats in 7.16, and then just the new format in 8.0. |
//cc @andrew-moldovan @gmarz @nikulinivan Talking with @AlexP-Elastic Just discovered another fly in the ointment that we need to be aware of:
In order not to step on anyone's toes, I bring it up here, and allow the stack team to work with @elastic/cloud-platform-data-services to co-ordinate strategy on this point. |
@gigerdo FYI |
I don't really understand that, can you elaborate? I believe our stance is that we won't upgrade the L+M (ECE) and RLC (ESS) to 8.0 right away, and we would keep beats-runner on 7.x until we upgrade L+M and RLC. |
Yes, your understanding is correct - I expressed in inelegantly. |
Thanks I understand now 🙇 |
@yspotts Thanks for pinging us 👍 On the Cloud Platform side (in terms of the beats-runner upgrade) we are OK with the changes proposed in elastic/kibana#50660, as long as support for the legacy format is backported to some 7.x version that we can upgrade to before 8.0. @planadecu Can you coordinate with the beats team on determining what version that will be? Separately, @lucasmoore we'll need to work out how we plan to roll out the beats-runner upgrade (https://github.com/elastic/cloud/issues/79840) to ESS in order to prepare for this change. I'll send something out to discuss when @przemek-grzedzielski (who has been driving the beats upgrade) returns next week. |
@gmarz Were you meaning to say "as long as support for the new format is backported"? If so, I think that's a question for @sayden to confirm, but we will need to support both as I mentioned above:
|
Maybe the folks from the beats team can shed some light on the topic @ruflin @ravikesarwani. How feasible is it that Filebeats supports both versions? In which version do you think you could do it? |
I managed to spend some time on this today and started to modify the pipeline. So as far as I can understand, a TLDR is that Filebeat needs to support ASAP Kibana logs for 7.x and 8.x at the same time, right? (all blame on my about the ASAP, don't assume malice). |
@sayden thank you! (And I certainly dont ascribe any malice; we are all working hard on so many things and it seems like there is a never ending list of stuff that is ASAP, no worries at all my friend!) |
@sayden Thanks for looking into this! Yep, 8.x is most critical, however I know we have 7.16 FF coming up first, so unless this is something you'd envision going out in a 7.16.x patch release (which would be up to you all), you may want to consider tackling both of them at once. There would still be benefit to users to have support on 7.x, even if we are still working out some of the details on the cloud side. And of course, Filebeat would only need to support both versions on |
Backlog grooming: @lukeelmers as 8.0 is already out for a while, shouldn't we close this issue? |
The @elastic/kibana-core team has been working on improvements to our new platform logging service in preparation for removing Kibana's legacy logging system in 8.0.
As a part of these changes, the log formats have been updated to be more in line with the Elasticsearch logs which are based on log4j 2. In particular, our log format for http request/response logs has been updated to include ECS-compliant meta, and we've also adjusted how ops metrics are logged, among other changes.
After looking at the ingest pipeline for the Kibana module, it appears that several of these referenced fields will break once the legacy logger is deprecated.
Wanted to raise this issue now so that we can discuss implications on Beats & answer any questions you might have around these changes. We have not yet removed the legacy logs from Kibana's
master
branch, but will likely do so as we get closer to the 8.0 alpha.cc @alexh97 @kobelb
The text was updated successfully, but these errors were encountered: