Notification based Promtail WAL Watcher polling approach#9135
Conversation
cstyan
left a comment
There was a problem hiding this comment.
I think we're missing a way of removing the client/manager from the list of subscribers when it goes away?
Do we need such subscriber removal action implemented? The only time a subscriber, be it a watcher or a write to, are stopped, is when Promtail is stopped. This could happen when the config is re-loaded, or it's actually stopped. Since when re-loading the whole |
Got it. I was incorrectly assuming that the Manager struct itself supported reloading, but you're right I just read the code and we create the Manager when reloading the config file. |
546cd23 to
901c11e
Compare
What this PR does / why we need it:
This PR implements a new mechanism for the wal Watcher in Promtail, to know there are new records to be read. It uses a combination of:
The main idea is that the primary mechanism is a notification channel between the
wal.Writerandwal.Watcher. The Watcher subscribes to write events the writer publishes, getting notified if the wal has been written. The same subscriptions design is used for cleanup events.As a backup, the watcher has a timer that implements an exponential backoff strategy, which is constrained by a minimum and maximum that the user can configure.
Below the cpu difference is shown of running both main and this branch against the same scrape target.
The yellow line is the latest main build from where this branch started, and the green line is this branch. Both promtails tailing docker logs, and using the following metrics to get cpu usage from cadvisor:
Which issue(s) this PR fixes:
Part of #8197
Special notes for your reviewer:
Checklist
CONTRIBUTING.mdguide (required)CHANGELOG.mdupdateddocs/sources/upgrading/_index.md