Filebeat new registry#12908
Conversation
|
@urso is that a draft? I've put the work in progress label on it. |
6799ac9 to
43a1d61
Compare
061835b to
37ef309
Compare
569f2f9 to
4027ecf
Compare
8183bcd to
75b470e
Compare
d5faecf to
03bf7b9
Compare
75b470e to
870239c
Compare
ef8c2be to
40bed88
Compare
870239c to
285ab8d
Compare
f8cbeb2 to
dc050b0
Compare
5a8c7e4 to
b5219e1
Compare
b5219e1 to
76fec47
Compare
65b125f to
0a47376
Compare
19757f0 to
fb3b053
Compare
0a47376 to
5d37a2f
Compare
filebeat/registrar/migrate.go
Outdated
There was a problem hiding this comment.
Why isn't this function a private function of Migrator?
func (m *Migrator) ensureCurrent() error {And looking at the other functions in this file, those can be part of the Migrator as well.
There was a problem hiding this comment.
True. I wanted to keep the change minimal, also to reduce the chance of messing up variables. The NewRegistry has been split into Migrator and the current implementation of New, so to explicitely require Filebeat to call migration before instantiating any registry. As all functionality is private to this package I didn't see this as a critical change.
b9eff45 to
f24f242
Compare
Registry file becomes a shared resource. As a long running write transaction can block others from making progress, we want a more short lived transaction.
f24f242 to
750f462
Compare
💔 Build FailedExpand to view the summary
Build stats
Test stats 🧪
Test errorsExpand to view the tests failures
Steps errorsExpand to view the steps failures
Log outputExpand to view the last 100 lines of log output
|
💔 Build FailedExpand to view the summary
Build stats
Steps errorsExpand to view the steps failures
Log outputExpand to view the last 100 lines of log output
|
This PR updates the current filebeat registry to use libbeat/registry as backend. This is the same new registry to be used with #14229. This way inputs using the old input API and inputs using the new inputs API will use the very same registry file.
The reason for having both using the same backend is to ease migration. This PR introduces some initial support for registry file migration (in case we update the backend in the future). The migration support already copies the old registry file into the new location. By migrating the old file from the get go we do not have to deal with 2 different file formats now and in the future.
Mixing the registrar with the new registry is not exactly optimal. Traditionally filebeat stores states per input and in the registrar. Now we need to store it in the input, the registrar, and the new registry (also in-memory). Plus the new registry supports selective field updates, but the registrar doesn't make use of it. This means all fields need to be serialized and written twice. Once for generic in memory state and once for writing to disk. Although in most cases only one field would be enough, we need to serialize all fields all the time, due to the registrar mixing internal and external state in one common structure. This can't be really helped and is a temporary limitation.
To get an idea about the impact I did run a few tests. Each test runs filebeat for ~90s and we measure throughput, memory, and CPU usage (besides small peaks and lows run was rather stable). NASA HTTP access logs are chosen as sample data.
All in all there is a performance degragation due to this change. This becomes most noticable in increased CPU usage. Each update serializes the complete state, no matter if only one field is updated. With separating meta-data and read-offset updates in the future I'd expect the overhead for serializing and writing updates to be reduced.