add purge queue observability via cache_purge_status and active_slots - #67
Open
hsntgm wants to merge 1 commit into
Open
add purge queue observability via cache_purge_status and active_slots#67hsntgm wants to merge 1 commit into
hsntgm wants to merge 1 commit into
Conversation
The main aim is observability of the background purge queue. Before this patch, the background purge queue was completely opaque. Once a purge request was enqueued and the 202 was returned to the client, there was no way to know: * whether the purge had actually been processed yet * whether the worker was currently walking the cache directory * whether the queue was backing up or full The patch solves this in two parts that work together: * The tracking mechanism (active_slots) records which cache paths are currently being walked by a background worker. Without this, you could count queued items but you couldn't tell if one was actively being processed right now (it's already been dequeued but the filesystem walk hasn't finished). * The status endpoint (cache_purge_status) exposes that internal state as a queryable JSON API, giving operators a way to poll and answer the question: "Has my purge_all actually happened yet?" The new cache_purge_status directive (e.g. cache_purge_status /data/nginx/cache) serves per‑zone statistics, so operators can monitor each cache directory independently. The endpoint responds with JSON fields queue_size, purge_all_pending, queue_full, and purge_in_flight, all read under the same queue mutex to guarantee a consistent snapshot. A downstream process can reliably determine that purge_all or Partial/wildcard (key*) has completed by polling the endpoint and checking; queue_size == 0 AND purge_in_flight == false (for that cache_path) This signals indicates bg purge completed, the directory walk has finished, and no walk is still in progress. This is practically important in deployment scenarios where something downstream (a CDN origin check, a deployment pipeline, a health check, preload action) needs to wait for a cache zone to actually be cleared before proceeding.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The main aim is observability of the background purge queue.
Before this PR, the background purge queue was completely opaque. Once a purge request was enqueued and the 202 was returned to the client, there was no way to know:
The PR solves this in two parts that work together:
The tracking mechanism (active_slots) records which cache paths are currently being walked by a background worker. Without this, you could count queued items but you couldn't tell if one was actively being processed right now (it's already been dequeued but the filesystem walk hasn't finished).
The status endpoint exposes that internal state as a queryable JSON API, giving operators a way to poll and answer the question: "Has my async purge_all actually happened yet?"
Indroduce new cache_purge_status directive that serves per‑zone statistics,
so operators can monitor each cache directory independently.
The endpoint responds with the following JSON
all read under the same queue mutex to guarantee a consistent snapshot.
A downstream process can reliably determine that async purge_all or Partial/wildcard (key) has completed by polling the endpoint and checking;
queue_size == 0 AND purge_in_flight == false (for that cache_path)
This signals indicates bg purge completed, the directory walk has finished, and no walk is still in progress.
This is practically important in deployment scenarios where something downstream (a CDN origin check, a deployment pipeline, a health check, preload action) needs to wait for a cache zone to actually be cleared before proceeding.
Best~Hasan