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

[Filebeat] Duplicating events in log rotation when output is down #17963

Closed
gemaliano opened this issue Apr 24, 2020 · 3 comments
Closed

[Filebeat] Duplicating events in log rotation when output is down #17963

gemaliano opened this issue Apr 24, 2020 · 3 comments
Labels
bug Filebeat Filebeat Stalled Team:Services (Deprecated) Label for the former Integrations-Services team

Comments

@gemaliano
Copy link

  • Version: 7.5.0

  • Description:
    When filebeat output is not running for long period of time and logs are rotating during this time we can see duplicates.
    All the log files (my-server.log.1,my-server.log.2...) are read again.

  • Configuration:
    Filebeat input: reading from rotation log

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/my-server/my-server.log*

Filebeat output for example logstash.

  • Filebeat process:
1. collect current file stats from disk
2. (State update phase) for each file found:
  2.1 check if file is new and start prepare harvester:
    2.1.1 create harvester
    2.1.2 add state to internal table
    2.1.3 forward new state to the registry
  2.2 if file is known and has been renamed:
    2.2.1 update internal table
    2.2.2 forward updates state to the registry
3. (Cleanup phase) for each file in internal state table:
  3.1 checkf if current file path still matches inode pair
    3.1.1 if file is still open, do nothing
    3.1.2 if they do not match anymore remove it:
      3.1.2.1 remove from internal state table
      3.1.2.2 forward 'removal' to the registry

Step (2.1.3, 2.2.2, and 2.3.2) will block until the output is up again.
When output is down and the logs are rotated, the input is blocked in the "State update phase" (e.g. 2.1.3 or 2.2.2). Once output is up again, the input continues with the 'Cleanup phase', which detects that the current on disk state does not match the internal state anymore. States get removed.

Normally the cleanup phase is expected to run right after the state collection phase. But due to the input being blocked, the input did continue the state cleanup with some very old outdated state.

@urso urso added the Team:Services (Deprecated) Label for the former Integrations-Services team label Apr 24, 2020
@elasticmachine
Copy link
Collaborator

Pinging @elastic/integrations-services (Team:Services)

@andresrc
Copy link
Contributor

This needs changes #15324 to be solved.

@botelastic
Copy link

botelastic bot commented Mar 28, 2021

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.

@botelastic botelastic bot added the Stalled label Mar 28, 2021
@botelastic botelastic bot closed this as completed Apr 27, 2021
@zube zube bot removed the [zube]: Done label Jul 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Filebeat Filebeat Stalled Team:Services (Deprecated) Label for the former Integrations-Services team
Projects
None yet
Development

No branches or pull requests

4 participants