-
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] Elasticsearch Module w/ Kubernetes Autodiscover Causes Logs in Incorrect Fieldsets #16540
Comments
As a first step it would be good to try to reproduce this with Elasticsearch simply running in a Docker container and pointing Filebeat to it's logs. That is, if we can reproduce this without k8s or autodisovery in the picture, it might let us narrow down the source of the problem. |
Can you try 7.x or master? I believe you might get a different behavior with this change #16450, but I could be wrong. I remember when working on that change that multiple filesets where getting merged. I think the issue here is that autodiscovery only reads from the container log, which is a single log file, it will not read from logs inside of the container. With merging the paths are replaced with the container log path and not the actual path inside of the container. |
@ycombinator I can spin up an Elasticsearch node and point Filebeat to it's logs, but I am having trouble figuring out what the filebeat.yml config file to accomplish that would look like without using autodiscover. Is this what you are suggesting for the test? filebeat.yml:
modules.d/elasticsearch.yml:
|
Thanks for the superbly detailed breakdown, @SpencerLN — appreciate it! So it seems like there are two distinct issues here we need to address:
|
@ycombinator I did some additional testing tonight and found that if I disable the default_config for Kubernetes autodiscover, I no longer see the unexpected behavior, and have identical results as I did in Docker.
Unfortunately, this isn't an ideal configuration, since we do want to collect logs from Pods that we don't necessarily control and cannot always annotate. That said, hopefully it helps in narrowing the cause of the issue. We are also running the Kibana module via Kubernetes autodiscover and don't seem to see the same problems there, but the Kibana module only has one fileset, so I am not sure if that is a factor or not. Let me know if there is more verbose logging level for a certain component of filebeat that would provide additional helpful information. Thanks! |
Thanks again @SpencerLN, this does help narrow it down! @blakerouse Do you want to tackle the k8s bits or file an issue for it and reference it in #16540 (comment)? Then we can treat this issue here as a meta issue for the two separate issues referenced from that comment. |
I think this bug covers the issue for the autodiscover, so lets keep this issue open. |
@blakerouse and @ycombinator |
Been looking into this, attaching debug log so I do not lose it. Debug log for
|
Attaching log for
|
Okay after many hours of debugging and retrying different configurations, I finally broke down and made a change that I thought might be the issue. As it was the only thing that I can see between enabled off and a configuration being provided. The code looked like this:
Here I could see that every time this was called it was done on a new result of But in the case that a more than So I changed the |
According to the release notes for 7.6.2 - it looked like this should be resolved, but we are still seeing this same problem. Can someone confirm that this should indeed be corrected in 7.6.2? |
@SpencerLN This should be fixed in 7.6.2, but GC logs would still have an issue. As you still need #16583 to be resolved, which is not in 7.6.2. If you only see the issue with GC logs then this issue can be re-closed, but if you are still seeing this issue across many datasets, more digging will need to be done. I was able to test with master at the time with this fix and it did resolve the issue for me. |
@blakerouse it looks like we are still seeing this for the audit, deprecation, slowlog, and server logs as well when running on Filebeat 7.6.2. Is there any specific information I can provide to help look into this further? |
@SpencerLN The specific manifest (including filebeat config) you are using to run filebeat along with all annotations on the elasticsearch pod. |
@blakerouse I attached the filebeat manifest we are using. These are the labels/annotations on the Elasticsearch pod:
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This is still an ongoing issue. |
This was raised in support case 880159 by @SpencerLN, is there an update on this one and when we might be able to expect a fix? |
Issue: Using the Filebeat Elasticsearch module in combination with Kubernetes autodiscover results in logs in the incorrect filesets or duplicate filesets:
Expected behavior: Each log message should only appear in the destination a single time, and it should have the appropriate fields associated with the fileset of that log (i.e. server, audit, deprecation, gc, etc.)
Deploying Filebeat using Filebeat Helm chart with values.yaml:
In this case Elasticsearch was deployed using ECK, with annotations in the podTemplate to enable the Elasticsearch module:
I am attaching the filebeat.log file, the json of the documents from the above screenshot, and the contents of the bulk request that show the documents are being to the corresponding pipelines for each fileset (4 copies of the same document).
The appropriate pipelines were installed in Elasticsearch prior to these logs being ingested:
filebeat.log
bulk_request.txt
sample-docs.txt
The text was updated successfully, but these errors were encountered: