-
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 flag to disable deviceId as part of the file identification in the registry #13314
Comments
I am the author of said workaround in https://github.com/breml/beats/tree/ignore-device-id. It was a rather quick implementation and it does not include any tests. The idea is to gain some experience in our integration environment to find out, if the workaround does in fact work. |
I would like to see this made available. My use case is this: filebeat is running in a scripted AWS instance that is prospecting from an dedicated AWS volume. During an update/upgrade, the instance is rebuilt, and the AWS volume is reattached to the new instance (remounted by AWS volume id). But, since the filebeat's calculates a different device id, all of the existing files are re-prospected. (in my case, duplicates are not the issue, rather it could take days to reprocess all of the data.) Making filebeat able to detect that the same volume is remounted, or making it ignore device id changes would be very helpful. |
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 issue doesn't have a |
@breml You are right. Thank you for the ping. |
Based on the issue we described in discuss
, we added a flag
ignore_device_id
to the filebeat log input configuration, which allows to disable the deviceId in the registry. This is done by setting the deviceId always to0
.The first version of the implementation can be seen here: https://github.com/breml/beats/tree/ignore-device-id
The text was updated successfully, but these errors were encountered: