Queue size variables

[maximk-1]

Added $cache_purge_queue_size/$cache_purge_queue_max_size to track queue size in logs or metrics.

[maximk-1]

To be honest, I'm not familiar in nginx module development and this PR was fully vibecoded with claude.

[denji]

Architectural Alternative: Status Handler

Exposing global shared-memory state via per-request variables can be risky.

Recommendation: Instead of variables, consider implementing a dedicated status handler (similar to src/http/modules/ngx_http_stub_status_module.c).

Benefits: This allows external monitoring tools (like Prometheus or Datadog) to scrape the queue metrics at a fixed interval (e.g., every 5 seconds) rather than forcing NGINX to calculate and log the data for every single request. This keeps the request path clean and provides the same level of observability.

Status-handler shape is cleaner for production observability. NGINX’s own stub_status module is explicitly a small endpoint for scraping basic status data, and it also exposes embedded variables for that purpose. That makes a dedicated /status location a better fit for queue metrics than pushing the data through every request.

So the best compromise is probably: keep the variables for ad hoc debugging, but add a dedicated status endpoint for real monitoring. That keeps the request path simple while still giving operators the visibility they need. Also, the fact that NGINX modules commonly register embedded variables during module init, like ngx_http_upstream does, means the variable approach is architecturally acceptable; it is just not the lowest-overhead observability surface.

[maximk-1]

imho variables are more flexible as they can be used in own handlers, like basic return 200 $cache_purge_queue_size; inside location or in nginx-lua-prometheus handlers.