Remove data.json registry info

[dedemorton]

The behavior of the Filebeat registry changed in 7.9. The registry no longer uses a file called data.json.

I've removed the places where we mention the file, but someone on the dev team needs to confirm that the registry settings have not changed.

[botelastic]

This pull request doesn't have a Team:<team> label.

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Build Cause: [Pull request #22165 opened]

• Start Time: 2020-10-26T18:11:06.715+0000

• Duration: 24 min 33 sec

[urso]

We got a new setting named filebeat.registr.clean_interval. The setting does not affect the log input or the container input. But new inputs like o365audit make us of it: The setting configures the interval the inputs check for stale outdated state entries.

New-style inputs that use the registry did get a new setting named clean_timeout. So far o365audit and httpjson are the only once that make use of it (winlog input is not documented and journald is excluded by the build). The clean_timeout setting configures a source time-to-live (TTL). If the source is not collected and latest update timestamp + clean_timeout > now and entry is assumed to be stale and will be removed by the next gc-run whose interval is configured by the filebeat.registry.clean_interval setting.

[dedemorton]

@urso I'm trying to figure out the best way to document the new settings so that users will know whether the settings apply to their config. Saying "new-style input" isn't going to help users, and I'm pretty sure we don't want to list all the inputs that support the new settings. Is there some sway of describing these new-style inputs so that it will be clear to users whether the new settings are applicable?

[urso]

Is there some sway of describing these new-style inputs so that it will be clear to users whether the new settings are applicable?

Unfortunately not. It's an implementation detail. Almost all inputs that store state between restarts have switched to the new API. The only exceptions are the log and docker/container inputs I think.

[urso]

@dedemorton do we want to merge this PR as is and create a follow up issue?

[dedemorton]

@urso Yes, but you should create the follow-up issue because I don't think I can describe this.

[urso]

Follow up issue: #22513 (I hope the issue is a little more clear)