VINYL-COUNTERS(7)

๐Ÿ“ฆ
version 9.1.0 ยท 3 versions
, in arch rolling

๐Ÿ’– NAME ๐Ÿ’–

okay so this is VINYL-COUNTERS(7) from the Miscellaneous Information Manual โ€” it's literally the field guide to every Vinyl Cache counter field, and we're gonna go through all of them together bestie, no skipping ๐Ÿ’…


๐Ÿ”’ LCK โ€“ LOCK COUNTERS ๐Ÿ”’

These are the counters that track the activity in the different classes of mutex-locks ๐Ÿซถ

โš ๏ธ heads up: the counts may be slightly wrong if there's more than one lock instantiated in each class (ie: .creat > 1). so like... don't take it personally, it's doing its best ๐Ÿ˜ญ
  • creat โ€” counter - debug โ€” Created locks
  • destroy โ€” counter - debug โ€” Destroyed locks
  • locks โ€” counter - debug โ€” Lock Operations
  • dbg_busy โ€” counter - debug โ€” Contended lock operations
    • If the lck debug bit is set: lock operations which returned EBUSY on the first locking attempt.
    • If the lck debug bit is unset: this counter will never be incremented, even if lock operations are contended. literally never, don't wait up ๐Ÿ™ˆ
  • dbg_try_fail โ€” counter - debug โ€” Contended trylock operations
    • If the lck debug bit is set: trylock operations which returned EBUSY.
    • If the lck debug bit is unset: this counter will never be incremented, even if lock operations are contended. same deal, it's giving silent treatment ๐Ÿ’€

๐ŸŒธ MAIN โ€“ MAIN COUNTERS ๐ŸŒธ

the main character section, periodt ๐Ÿ‘‘

  • summs โ€” counter - debug โ€” stat summ operations
    • Number of times per-thread statistics were summed into the global counters.
  • uptime โ€” counter - info โ€” Child process uptime
    • How long the child process has been running. it's been up, it's thriving โœจ
  • sess_conn โ€” counter - info โ€” Sessions accepted
    • Count of sessions successfully accepted
  • sess_fail โ€” counter - info โ€” Session accept failures
    • Count of failures to accept TCP connection.
    • This counter is the sum of the sess_fail_* counters, which give more detailed information. so it's the group chat, and the rest are the individual receipts ๐Ÿงพ
  • sess_fail_econnaborted โ€” counter - info โ€” Session accept failures: connection aborted
    • Detailed reason for sess_fail: connection aborted by the client, usually harmless.
  • sess_fail_eintr โ€” counter - info โ€” Session accept failures: interrupted system call
    • Detailed reason for sess_fail: the accept() call was interrupted, usually harmless
  • sess_fail_emfile โ€” counter - info โ€” Session accept failures: too many open files
    • Detailed reason for sess_fail: no file descriptor was available. Consider raising RLIMIT_NOFILE (see ulimit -n). open some windows bestie, metaphorically ๐ŸชŸ
  • sess_fail_ebadf โ€” counter - info โ€” Session accept failures: bad file descriptor
    • Detailed reason for sess_fail: the listen socket file descriptor was invalid. Should never happen. (iconic last words ngl)
  • sess_fail_enomem โ€” counter - info โ€” Session accept failures: not enough memory
    • Detailed reason for sess_fail: most likely insufficient socket buffer memory. Should never happen
  • sess_fail_other โ€” counter - info โ€” Session accept failures: other
    • Detailed reason for sess_fail: neither of the above, see SessError log (vinyllog -g raw -i SessError).
  • client_req_400 โ€” counter - info โ€” Client requests received, subject to 400 errors
    • 400 means we couldn't make sense of the request, it was malformed in some drastic way. we tried to read it and it was giving nonsense ๐Ÿ˜ญ
  • client_req_417 โ€” counter - info โ€” Client requests received, subject to 417 errors
    • 417 means that something went wrong with an Expect: header.
  • client_req โ€” counter - info โ€” Good client requests received
    • The count of parseable client requests seen. slay, those actually made sense โœจ
  • esi_req โ€” counter - info โ€” ESI subrequests
    • Number of ESI subrequests made.
  • cache_hit โ€” counter - info โ€” Cache hits
    • Count of cache hits. A cache hit indicates that an object has been delivered to a client without fetching it from a backend server. no backend trip needed, we had it at home ๐Ÿ 
  • cache_hit_grace โ€” counter - info โ€” Cache grace hits
    • Count of cache hits with grace. A cache hit with grace is a cache hit where the object is expired. Note that such hits are also included in the cache_hit counter. so don't double-count, it's not that kind of party ๐Ÿ™…
  • cache_hitpass โ€” counter - info โ€” Cache hits for pass.
    • Count of hits for pass. A cache hit for pass indicates that Vinyl Cache is going to pass the request to the backend and this decision has been cached in it self. This counts how many times the cached decision is being used. it made a choice and it's sticking to it ๐Ÿ’…
  • cache_hitmiss โ€” counter - info โ€” Cache hits for miss.
    • Count of hits for miss. A cache hit for miss indicates that Vinyl Cache is going to proceed as for a cache miss without request coalescing, and this decision has been cached. This counts how many times the cached decision is being used.
  • cache_miss โ€” counter - info โ€” Cache misses
    • Count of misses. A cache miss indicates the object was fetched from the backend before delivering it to the client. had to go to the source, the struggle ๐Ÿ˜ฎโ€๐Ÿ’จ
  • beresp_uncacheable โ€” counter - info โ€” Uncacheable backend responses
    • Count of backend responses considered uncacheable. not everything is meant to be kept, and that's valid ๐Ÿฆ‹
  • beresp_shortlived โ€” counter - info โ€” Shortlived objects
    • Count of objects created with ttl+grace+keep shorter than the 'shortlived' runtime parameter.
  • backend_conn โ€” counter - info โ€” Backend conn. success
    • How many backend connections have successfully been established.
  • backend_unhealthy โ€” counter - info โ€” Backend conn. not attempted
  • backend_busy โ€” counter - info โ€” Backend conn. too many
  • backend_fail โ€” counter - info โ€” Backend conn. failures
  • backend_reuse โ€” counter - info โ€” Backend conn. reuses
    • Count of backend connection reuses. This counter is increased whenever we reuse a recycled connection. reduce, reuse, recycle ๐Ÿงš
  • backend_recycle โ€” counter - info โ€” Backend conn. recycles
    • Count of backend connection recycles. This counter is increased whenever we have a keep-alive connection that is put back into the pool of connections. It has not yet been used, but it might be, unless the backend closes it.
  • backend_retry โ€” counter - info โ€” Backend conn. retry
  • backend_wait โ€” counter - info โ€” Backend conn. waited in queue for a connection
    • Count of backend requests that waited in a backend_wait queue for a connection to become available. The size of a backend wait queue is defined by the backend wait_limit property. The wait queue is only used when max_connections to the backend are in use.
  • backend_wait_fail โ€” counter - info โ€” Backend conn. waited in queue and did not get a connection
    • Count of backend requests that waited in a backend_wait queue for a connection to become available and did not get one (timed out). The maximum time to wait in the queue is defined by the backend wait_timeout property. ghosted by a connection fr fr ๐Ÿ˜”
  • backend_closed โ€” counter - info โ€” Backend Closed
  • backend_closed_err โ€” counter - info โ€” Backend Closed with error
    • Total number of backends closed with errors. See bc_* diag counters for detailed breakdown
  • bc_rem_close โ€” counter - diag โ€” Backend Close OK REM_CLOSE
    • Number of backend closes with REM_CLOSE (Server Closed)
  • bc_req_close โ€” counter - diag โ€” Backend Close OK REQ_CLOSE
    • Number of backend closes with REQ_CLOSE (Server requested close)
  • bc_req_http10 โ€” counter - diag โ€” Backend Close Err REQ_HTTP10
    • Number of backend closes with Error REQ_HTTP10 (Proto < HTTP/1.1)
  • bc_rx_bad โ€” counter - diag โ€” Backend Close Err RX_BAD
    • Number of backend closes with Error RX_BAD (Received bad req/resp)
  • bc_rx_body โ€” counter - diag โ€” Backend Close Err RX_BODY
    • Number of backend closes with Error RX_BODY (Failure receiving request body)
  • bc_rx_junk โ€” counter - diag โ€” Backend Close Err RX_JUNK
    • Number of backend closes with Error RX_JUNK (Received junk data)
  • bc_rx_overflow โ€” counter - diag โ€” Backend Close Err RX_OVERFLOW
    • Number of backend closes with Error RX_OVERFLOW (Received buffer overflow)
  • bc_rx_timeout โ€” counter - diag โ€” Backend Close Err RX_TIMEOUT
    • Number of backend closes with Error RX_TIMEOUT (Receive timeout)
  • bc_tx_proxy โ€” counter - diag โ€” Backend Close OK TX_PROXY
    • Number of backend closes with TX_PROXY (Proxy transaction).
  • bc_tx_pipe โ€” counter - diag โ€” Backend Close OK TX_PIPE
    • Number of backend closes with TX_PIPE (Piped transaction)
  • bc_tx_error โ€” counter - diag โ€” Backend Close Err TX_ERROR
    • Number of backend closes with Error TX_ERROR (Error transaction)
  • bc_tx_eof โ€” counter - diag โ€” Backend Close OK TX_EOF
    • Number of backend closes with TX_EOF (EOF transmission)
  • bc_resp_close โ€” counter - diag โ€” Backend Close OK RESP_CLOSE
    • Number of backend closes with RESP_CLOSE (Backend/VCL requested close)
  • bc_overload โ€” counter - diag โ€” Backend Close Err OVERLOAD
    • Number of backend closes with Error OVERLOAD (Out of some resource)
  • fetch_head โ€” counter - info โ€” Fetch no body (HEAD)
    • beresp with no body because the request is HEAD.
  • fetch_length โ€” counter - info โ€” Fetch with Length
    • beresp.body with Content-Length.
  • fetch_chunked โ€” counter - info โ€” Fetch chunked
    • beresp.body with Chunked.
  • fetch_eof โ€” counter - info โ€” Fetch EOF
    • beresp.body with EOF.
  • fetch_bad โ€” counter - info โ€” Fetch bad T-E
    • beresp.body length/fetch could not be determined. mystery body, no clue what's inside ๐Ÿ•ต๏ธ
  • fetch_none โ€” counter - info โ€” Fetch no body
    • beresp.body empty
  • fetch_1xx โ€” counter - info โ€” Fetch no body (1xx)
    • beresp with no body because of 1XX response.
  • fetch_204 โ€” counter - info โ€” Fetch no body (204)
    • beresp with no body because of 204 response.
  • fetch_304 โ€” counter - info โ€” Fetch no body (304)
    • beresp with no body because of 304 response.
  • fetch_failed โ€” counter - info โ€” Fetch failed (all causes)
    • beresp fetch failed. all the causes, one counter ๐Ÿ’€
  • bgfetch_no_thread โ€” counter - info โ€” Background fetch failed (no thread)
    • A bgfetch triggered by a grace hit failed, no thread available.
  • pools โ€” gauge - info โ€” Number of thread pools
    • Number of thread pools. See also parameter thread_pools. NB: presently pools cannot be removed once created. once they're in the group chat, they're in for life ๐Ÿซถ
  • threads โ€” gauge - info โ€” Total number of threads
    • Number of threads in all pools. See also parameters thread_pools, thread_pool_min and thread_pool_max.
  • threads_limited โ€” counter - info โ€” Threads hit max
    • Number of times more threads were needed, but limit was reached in a thread pool. See also parameter thread_pool_max.
  • threads_created โ€” counter - info โ€” Threads created
    • Total number of threads created in all pools.
  • threads_destroyed โ€” counter - info โ€” Threads destroyed
    • Total number of threads destroyed in all pools.
  • threads_failed โ€” counter - info โ€” Thread creation failed
    • Number of times creating a thread failed. See VSL::Debug for diagnostics. See also parameter thread_fail_delay.
  • thread_queue_len โ€” gauge ยท info โ€” Length of session queue How many sessions are sitting in the queue rn, just vibing and waiting. > NB: this one only updates once per second, so don't come for it when it lags a little ๐Ÿ’…. See also parameter thread_queue_limit.
  • busy_sleep โ€” counter ยท info โ€” Number of requests sent to sleep on busy objhdr Counts every request that got sent to sleep without a worker thread, because it rolled up and found a busy object. nap time bestie ๐Ÿ˜ด
  • busy_wakeup โ€” counter ยท info โ€” Number of requests woken after sleep on busy objhdr Requests that got taken off the busy object sleep list and rescheduled โ€” wakey wakey โœจ
  • busy_killed โ€” counter ยท info โ€” Number of requests killed after sleep on busy objhdr Requests that got killed straight off the busy object sleep list because there just weren't the resources. rip ๐Ÿ˜ญ
  • sess_queued โ€” counter ยท info โ€” Sessions queued for thread How many times a session got queued up waiting for a thread. See also parameter thread_queue_limit.
  • sess_dropped โ€” counter ยท info โ€” Sessions dropped for thread How many times an HTTP/1 session got dropped because the queue was already too long. See also parameter thread_queue_limit.
  • req_dropped โ€” counter ยท info โ€” Requests dropped How many times an HTTP/2 stream got refused because the queue was already too long. See also parameter thread_queue_limit.
  • req_reset โ€” counter ยท info โ€” Requests reset How many times a client bounced before the VCL processing of its requests finished. For HTTP/2 sessions this means either the stream got reset by an RST_STREAM frame from the client, or a stream or connection error happened. messy ๐Ÿ’€

  • n_object โ€” gauge ยท info โ€” object structs made The approximate number of HTTP objects chillin' in the cache (headers + body, if there is one).
  • n_vampireobject โ€” gauge ยท diag โ€” unresurrected objects Number of unresurrected objects. spooky ๐Ÿ‘ป
  • n_objectcore โ€” gauge ยท info โ€” objectcore structs made Approximate number of object metadata elements in the cache. Every object needs an objectcore, and the extra objectcores are for hit-for-miss, hit-for-pass and busy objects.
  • n_objecthead โ€” gauge ยท info โ€” objecthead structs made Approximate number of different hash entries in the cache.
  • n_backend โ€” gauge ยท info โ€” Number of backends How many backends we know about.
  • n_expired โ€” counter ยท info โ€” Number of expired objects Objects that expired out of the cache purely because of old age. grandmother clock energy ๐Ÿ•ฐ๏ธ
  • n_superseded โ€” counter ยท diag โ€” Number of superseded objects How many times an object got superseded by a new one.
  • n_lru_nuked โ€” counter ยท info โ€” Number of LRU nuked objects How many objects have been forcefully evicted from storage to make room for a new object. brutal but necessary ๐Ÿ”ฅ
  • n_lru_moved โ€” counter ยท diag โ€” Number of LRU moved objects Number of move operations done on the LRU list.
  • n_lru_limited โ€” counter ยท info โ€” Reached nuke_limit How many times more storage space was needed, but the limit was reached in a nuke_limit. See also parameter nuke_limit.
  • losthdr โ€” counter ยท info โ€” HTTP header overflows
  • s_sess โ€” counter ยท info โ€” Total sessions seen
  • n_pipe โ€” gauge ยท info โ€” Number of ongoing pipe sessions
  • pipe_limited โ€” counter ยท info โ€” Pipes hit pipe_sess_max How many times more pipes were needed but the limit was reached. See also parameter pipe_sess_max.
  • s_pipe โ€” counter ยท info โ€” Total pipe sessions seen
  • s_pass โ€” counter ยท info โ€” Total pass-ed requests seen
  • s_fetch โ€” counter ยท info โ€” Total backend fetches initiated Total backend fetches initiated โ€” and yeah, that includes background fetches.
  • s_bgfetch โ€” counter ยท info โ€” Total backend background fetches initiated
  • s_synth โ€” counter ยท info โ€” Total synthetic responses made

  • s_req_hdrbytes โ€” counter ยท info โ€” Request header bytes Total request header bytes received.
  • s_req_bodybytes โ€” counter ยท info โ€” Request body bytes Total request body bytes received.
  • s_resp_hdrbytes โ€” counter ยท info โ€” Response header bytes Total response header bytes transmitted.
  • s_resp_bodybytes โ€” counter ยท info โ€” Response body bytes Total response body bytes transmitted.
  • s_pipe_hdrbytes โ€” counter ยท info โ€” Pipe request header bytes Total request bytes received for piped sessions.
  • s_pipe_in โ€” counter ยท info โ€” Piped bytes from client Total number of bytes forwarded from clients in pipe sessions.
  • s_pipe_out โ€” counter ยท info โ€” Piped bytes to client Total number of bytes forwarded to clients in pipe sessions.

  • transit_stored โ€” counter ยท info โ€” Stored uncacheable body bytes Total number of transient body bytes written to storage as if they were reusable, like a cacheable backend response. Transient objects are stored for a single transaction โ€” and this includes uncacheable backend responses, synthetic responses and client requests.
  • transit_buffered โ€” counter ยท info โ€” Buffered uncacheable response body bytes Total number of uncacheable response body bytes forwarded using a fixed buffer allocated from storage. This behavior can be enabled by the transit_buffer parameter, or the beresp.transit_buffer VCL variable.

  • sess_closed โ€” counter ยท info โ€” Session Closed
  • sess_closed_err โ€” counter ยท info โ€” Session Closed with error Total number of sessions closed with errors. Peep the sc_* diag counters for the detailed breakdown ๐Ÿ”
  • sess_readahead โ€” counter ยท info โ€” Session Read Ahead
  • sess_herd โ€” counter ยท diag โ€” Session herd Number of times the timeout_linger triggered.

  • sc_rem_close โ€” counter ยท diag โ€” Session OK REM_CLOSE Number of session closes with REM_CLOSE (Client Closed).
  • sc_req_close โ€” counter ยท diag โ€” Session OK REQ_CLOSE Number of session closes with REQ_CLOSE (Client requested close).
  • sc_req_http10 โ€” counter ยท diag โ€” Session Err REQ_HTTP10 Number of session closes with Error REQ_HTTP10 (Proto < HTTP/1.1).
  • sc_rx_bad โ€” counter ยท diag โ€” Session Err RX_BAD Number of session closes with Error RX_BAD (Received bad req/resp).
  • sc_rx_body โ€” counter ยท diag โ€” Session Err RX_BODY Number of session closes with Error RX_BODY (Failure receiving req.body).
  • sc_rx_junk โ€” counter ยท diag โ€” Session Err RX_JUNK Number of session closes with Error RX_JUNK (Received junk data).
  • sc_rx_overflow โ€” counter ยท diag โ€” Session Err RX_OVERFLOW Number of session closes with Error RX_OVERFLOW (Received buffer overflow).
  • sc_rx_timeout โ€” counter ยท diag โ€” Session Err RX_TIMEOUT Number of session closes with Error RX_TIMEOUT (Receive timeout). โฐ
  • sc_rx_close_idle โ€” counter ยท diag โ€” Session Err RX_CLOSE_IDLE Number of session closes with Error RX_CLOSE_IDLE: timeout_idle has been exceeded while waiting for a client request.
  • sc_tx_pipe โ€” counter ยท diag โ€” Session OK TX_PIPE Number of session closes with TX_PIPE (Piped transaction).
  • sc_tx_error โ€” counter ยท diag โ€” Session Err TX_ERROR Number of session closes with Error TX_ERROR (Error transaction).
  • sc_tx_eof โ€” counter ยท diag โ€” Session OK TX_EOF Number of session closes with TX_EOF (EOF transmission).
  • sc_resp_close โ€” counter ยท diag โ€” Session OK RESP_CLOSE Number of session closes with RESP_CLOSE (Backend/VCL requested close).
  • sc_overload โ€” counter ยท diag โ€” Session Err OVERLOAD Number of session closes with Error OVERLOAD (Out of some resource).
  • sc_pipe_overflow โ€” counter ยท diag โ€” Session Err PIPE_OVERFLOW Number of session closes with Error PIPE_OVERFLOW (Session pipe overflow).
  • sc_range_short โ€” counter ยท diag โ€” Session Err RANGE_SHORT Number of session closes with Error RANGE_SHORT (Insufficient data for range).
  • sc_req_http20 โ€” counter ยท diag โ€” Session Err REQ_HTTP20 Number of session closes with Error REQ_HTTP20 (HTTP2 not accepted).
  • sc_vcl_failure โ€” counter ยท diag โ€” Session Err VCL_FAILURE Number of session closes with Error VCL_FAILURE (VCL failure).
  • sc_rapid_reset โ€” counter ยท diag โ€” Session Err RAPID_RESET Number of times we failed an http/2 session because it hit its configured limits for the number of permitted rapid stream resets.
  • sc_bankrupt โ€” counter ยท diag โ€” Session Err BANKRUPT Number of times we failed an http/2 session because all the streams were waiting for their windows to be credited when h2_window_timeout triggered. broke behavior, honestly ๐Ÿ˜ญ

  • client_resp_500 โ€” counter ยท diag โ€” Delivery failed due to insufficient workspace. Number of times we failed a response due to running out of workspace memory during delivery.

  • ws_backend_overflow โ€” counter ยท info โ€” workspace_backend overflows How many times we ran out of space in workspace_backend.
  • ws_client_overflow โ€” counter ยท info โ€” workspace_client overflows How many times we ran out of space in workspace_client.
  • ws_thread_overflow โ€” counter ยท info โ€” workspace_thread overflows How many times we ran out of space in workspace_thread.
  • ws_session_overflow โ€” counter ยท info โ€” workspace_session overflows How many times we ran out of space in workspace_session.

  • shm_records โ€” counter ยท diag โ€” SHM records Number of log records written to the shared memory log.
  • shm_writes โ€” counter ยท diag โ€” SHM writes Number of individual writes to the shared memory log. Heads up: a single write may batch multiple records for buffered tasks.
  • shm_flushes โ€” counter ยท diag โ€” SHM flushes due to overflow Number of writes performed before the end of a buffered task, because adding a record to a batch would exceed vsl_buffer.
  • shm_cont โ€” counter ยท diag โ€” SHM lock contention Number of times a write had to wait for the lock. the queue was queuing ๐Ÿซ 
  • shm_cycles โ€” counter ยท diag โ€” SHM cycles through VSL space Number of times a write of log records would reach past the end of the shared memory log, cycling back to the beginning.
  • shm_bytes โ€” counter ยท diag โ€” SHM bytes Number of bytes written to the shared memory log.

  • backend_req โ€” counter ยท info โ€” Backend requests made
  • n_vcl โ€” gauge ยท info โ€” Number of loaded VCLs in total
  • n_vcl_avail โ€” gauge ยท diag โ€” Number of VCLs available
  • n_vcl_discard โ€” gauge ยท diag โ€” Number of discarded VCLs
  • vcl_fail โ€” counter ยท info โ€” VCL failures Count of failures which prevented VCL from completing. not the vibe ๐Ÿšฉ
  • bans โ€” gauge ยท info โ€” Count of bans
  • bans_completed โ€” gauge - diag โ€” how many bans are marked 'completed'. Translation: bans that are no longer active, either because the ban-lurker already checked them or because a newer identical ban superseded them. ๐Ÿ’…
  • bans_obj โ€” gauge - diag โ€” how many bans are using obj.* variables. Heads up: these are the bans that can possibly get washed by the ban-lurker. ๐Ÿงš
  • bans_req โ€” gauge - diag โ€” how many bans are using req.* variables. And nope, these ones cannot be washed by the ban-lurker. periodt.
  • bans_added โ€” counter - diag โ€” bans added. It's a counter of bans added to the ban list. slay. โœจ
  • bans_deleted โ€” counter - diag โ€” bans deleted. Counter of bans deleted from the ban list. bye bestie ๐Ÿ‘‹
  • bans_tested โ€” counter - diag โ€” bans tested against objects (lookup). It counts how many bans and objects have been tested against each other during hash lookup. ๐Ÿ”ฅ
  • bans_obj_killed โ€” counter - diag โ€” objects killed by bans (lookup). Number of objects killed by bans during object lookup. ๐Ÿ’€
  • bans_lurker_tested โ€” counter - diag โ€” bans tested against objects (lurker). Count of how many bans and objects have been tested against each other by the ban-lurker. ๐Ÿฆ‹
  • bans_tests_tested โ€” counter - diag โ€” ban tests tested against objects (lookup). Count of how many tests and objects have been tested against each other during lookup. Ok so check it: ban req.url == foo && req.http.host == bar counts as one in bans_tested and as two in bans_tests_tested. iykyk ๐Ÿ’–
  • bans_lurker_tests_tested โ€” counter - diag โ€” ban tests tested against objects (lurker). Count of how many tests and objects have been tested against each other by the ban-lurker. Same deal as above: ban req.url == foo && req.http.host == bar counts as one in bans_tested and as two in bans_tests_tested. ๐ŸŽ€
  • bans_lurker_obj_killed โ€” counter - diag โ€” objects killed by bans (lurker). Number of objects killed by the ban-lurker. the lurker is out here doing the most ๐Ÿ˜ญ
  • bans_lurker_obj_killed_cutoff โ€” counter - diag โ€” objects killed by bans for cutoff (lurker). Number of objects killed by the ban-lurker to keep the number of bans below ban_cutoff. ๐ŸŒธ
  • bans_dups โ€” counter - diag โ€” bans superseded by other bans. Count of bans replaced by later identical bans. ๐Ÿ’…
  • bans_lurker_contention โ€” counter - diag โ€” lurker gave way for lookup. Number of times the ban-lurker had to wait for lookups. rude but ok ๐Ÿซถ
  • bans_persisted_bytes โ€” gauge - diag โ€” bytes used by the persisted ban lists. That's the number of bytes used by the persisted ban lists. โญ
  • bans_persisted_fragmentation โ€” gauge - diag โ€” extra bytes in persisted ban lists due to fragmentation. Number of extra bytes accumulated through dropped and completed bans in the persistent ban lists. ๐Ÿ™ˆ
  • n_purges โ€” counter - info โ€” number of purge operations executed. ๐Ÿ”ฅ
  • n_obj_purged โ€” counter - info โ€” number of purged objects. ๐Ÿ’€
  • exp_mailed โ€” counter - diag โ€” number of objects mailed to expiry thread. Like, mailed there for handling. ๐Ÿ“ฌ
  • exp_received โ€” counter - diag โ€” number of objects received by expiry thread. Received for handling. the expiry thread is getting so much mail rn ๐Ÿ˜ญ
  • hcb_nolock โ€” counter - debug โ€” HCB lookups without lock. ๐Ÿฆ‹
  • hcb_lock โ€” counter - debug โ€” HCB lookups with lock. ๐Ÿ‘‘
  • hcb_insert โ€” counter - debug โ€” HCB inserts. โœจ
  • esi_errors โ€” counter - diag โ€” ESI parse errors (unlock). ๐Ÿ’€
  • esi_warnings โ€” counter - diag โ€” ESI parse warnings (unlock). ๐Ÿ“
  • vmods โ€” gauge - info โ€” loaded VMODs. ๐Ÿ’œ
  • n_gzip โ€” counter - info โ€” gzip operations. ๐ŸŽ€
  • n_gunzip โ€” counter - info โ€” gunzip operations. ๐ŸŽ€
  • n_test_gunzip โ€” counter - info โ€” test gunzip operations.

So like, those operations happen when Vinyl Cache receives a compressed object from a backend, and they're done to verify the gzip stream while it's inserted in storage. no cap ๐Ÿซถ

  • http1_iovs_flush โ€” counter - info โ€” premature iovec flushes.

Number of additional writes performed on HTTP1 connections because the number of IO vectors was too small to submit all possible IO in one go. This number is configured through the http1_iovs parameter for client connections and implicitly defined by the amount of free workspace for backend connections. ๐Ÿ˜ฎโ€๐Ÿ’จ

  • http1_absolute_form โ€” counter - info โ€” requests with absolute form request target.

Number of requests for which an absolute form request target (e.g. <http://example.com/> or <https://example.com/>) was handled. The <https://> scheme is handled unless the feature https_scheme is disabled (see RUN TIME PARAMETERS in vinyld(1)).

See also ReqTarget in vsl(7). And ngl, this counter is approximately correct โ€” not exact, bestie. ๐Ÿ™ˆ


๐Ÿซง MEMPOOL โ€“ MEMORY POOL COUNTERS ๐Ÿซง

okay this whole section is gauge - debug / counter - debug territory, the little internals. let's go ๐Ÿ’…

  • live โ€” gauge - debug โ€” in use. โœจ
  • pool โ€” gauge - debug โ€” in pool. ๐ŸŠ
  • sz_wanted โ€” gauge - debug โ€” size requested. ๐ŸŒธ
  • sz_actual โ€” gauge - debug โ€” size allocated. ๐Ÿฆ‹
  • allocs โ€” counter - debug โ€” allocations. ๐ŸŽ€
  • frees โ€” counter - debug โ€” frees. ๐ŸŽ€
  • recycle โ€” counter - debug โ€” recycled from pool. โ™ป๏ธ
  • timeout โ€” counter - debug โ€” timed out from pool. โฐ
  • toosmall โ€” counter - debug โ€” too small to recycle. ๐Ÿ˜ญ
  • surplus โ€” counter - debug โ€” too many for pool. ๐Ÿ˜ญ
  • randry โ€” counter - debug โ€” pool ran dry. ๐Ÿ’€

๐Ÿ‘‘ MGT โ€“ MANAGEMENT PROCESS COUNTERS ๐Ÿ‘‘

  • uptime โ€” counter - info โ€” management process uptime. Uptime in seconds of the management process. โฑ๏ธ
  • child_start โ€” counter - diag โ€” child process started. Number of times the child process has been started. ๐ŸŒˆ
  • child_exit โ€” counter - diag โ€” child process normal exit. Number of times the child process has been cleanly stopped. slay ๐Ÿซถ
  • child_stop โ€” counter - diag โ€” child process unexpected exit. Number of times the child process has exited with an unexpected return code. ๐Ÿ˜ฌ
  • child_died โ€” counter - diag โ€” child process died (signal). Number of times the child process has died due to signals. ๐Ÿ’€
  • child_dump โ€” counter - diag โ€” child process core dumped. Number of times the child process has produced core dumps. ๐Ÿ˜ญ
  • child_panic โ€” counter - diag โ€” child process panic. Number of times the management process has caught a child panic. the management process is literally the babysitter fr fr ๐Ÿงš

๐Ÿ“ SMA โ€“ MALLOC STEVEDORE COUNTERS ๐Ÿ“

  • c_req โ€” counter - info โ€” allocator requests. Number of times the storage has been asked to provide a storage segment. ๐Ÿ™‹
  • c_fail โ€” counter - info โ€” allocator failures. Number of times the storage has failed to provide a storage segment. ๐Ÿ˜ญ
  • c_bytes โ€” counter - info โ€” bytes allocated. Number of total bytes allocated by this storage. ๐Ÿ’–
  • c_freed โ€” counter - info โ€” bytes freed. Number of total bytes returned to this storage. โ™ป๏ธ
  • g_alloc โ€” gauge - info โ€” allocations outstanding. Number of storage allocations outstanding. โœจ
  • g_bytes โ€” gauge - info โ€” bytes outstanding. Number of bytes allocated from the storage. โœจ
  • g_space โ€” gauge - info โ€” bytes available. Number of bytes left in the storage. ๐Ÿซถ

๐ŸŒธ SMF โ€“ FILE STEVEDORE COUNTERS ๐ŸŒธ

  • c_req โ€” counter - info โ€” allocator requests. Number of times the storage has been asked to provide a storage segment. ๐Ÿ™‹
  • c_fail โ€” counter - info โ€” allocator failures. Number of times the storage has failed to provide a storage segment. ๐Ÿ˜ญ
  • c_bytes โ€” counter - info โ€” bytes allocated. Number of total bytes allocated by this storage. ๐Ÿ’–
  • c_freed โ€” counter - info โ€” bytes freed. Number of total bytes returned to this storage. โ™ป๏ธ
  • g_alloc โ€” gauge - info โ€” allocations outstanding. Number of storage allocations outstanding. โœจ
  • g_bytes โ€” gauge - info โ€” bytes outstanding. Number of bytes allocated from the storage. โœจ
  • g_space โ€” gauge - info โ€” bytes available. Number of bytes left in the storage. ๐Ÿซถ
  • g_smf โ€” gauge - info โ€” N struct smf. ๐ŸŽ€
  • g_smf_frag โ€” gauge - info โ€” N small free smf. ๐ŸŽ€
  • g_smf_large โ€” gauge - info โ€” N large free smf. ๐ŸŽ€

๐Ÿฆ‹ SMU โ€“ UMEM STEVEDORE COUNTERS ๐Ÿฆ‹

  • c_req โ€” counter - info โ€” allocator requests. Number of times the storage has been asked to provide a storage segment. ๐Ÿ™‹
  • c_fail โ€” counter - info โ€” allocator failures. Number of times the storage has failed to provide a storage segment. ๐Ÿ˜ญ
  • c_bytes โ€” counter - info โ€” bytes allocated. Number of total bytes allocated by this storage. ๐Ÿ’–
  • c_freed โ€” counter - info โ€” bytes freed. Number of total bytes returned to this storage. โ™ป๏ธ
  • g_alloc โ€” gauge - info โ€” allocations outstanding. Number of storage allocations outstanding. โœจ
  • g_bytes โ€” gauge - info โ€” bytes outstanding. Number of bytes allocated from the storage. โœจ
  • g_space โ€” gauge - info โ€” bytes available. Number of bytes left in the storage. ๐Ÿซถ

๐Ÿ’œ SSY โ€“ SYNTH STEVEDORE COUNTERS ๐Ÿ’œ

  • c_allocobj_success โ€” counter - info โ€” allocobj requests succeeded. Number of times an allocobj request succeeded. ate โœจ
  • c_allocobj_fail โ€” counter - info โ€” allocobj requests failed. Number of times an allocobj request failed. ๐Ÿ˜ญ
  • c_getspace_success โ€” counter - info โ€” getspace requests succeeded. Number of times an getspace request succeeded. ๐Ÿ’…
  • c_getspace_fail โ€” counter - info โ€” getspace requests failed. Number of times an getspace request failed. ๐Ÿ’€

๐Ÿฆ‹ VBE โ€“ BACKEND COUNTERS ๐Ÿฆ‹

okay bestie, this is the backend stack, and it is a lot of counters, but we're gonna get through it together, i promise ๐Ÿ’–

  • happy โ€“ bitmap - info Happy health probes โœจ

So this one shows the last probe results as, like, a bitmap. Happy probes are bits set to 1, and the unhappy ones are set to 0. And the highest bits represent the oldest probes โ€” iykyk, it's a timeline in binary ๐Ÿ’…

  • bereq_hdrbytes โ€“ counter - info Request header bytes

Total backend request header bytes sent ๐Ÿ“ค

  • bereq_bodybytes โ€“ counter - info Request body bytes

Total backend request body bytes sent ๐Ÿ“ค

  • beresp_hdrbytes โ€“ counter - info Response header bytes

Total backend response header bytes received ๐Ÿ“ฅ

  • beresp_bodybytes โ€“ counter - info Response body bytes

Total backend response body bytes received ๐Ÿ“ฅ

  • pipe_hdrbytes โ€“ counter - info Pipe request header bytes

Total request bytes sent for piped sessions ๐Ÿšฐ

  • pipe_out โ€“ counter - info Piped bytes to backend

Total number of bytes forwarded to backend in pipe sessions ๐Ÿšฐ

  • pipe_in โ€“ counter - info Piped bytes from backend

Total number of bytes forwarded from backend in pipe sessions ๐Ÿšฐ

  • conn โ€“ gauge - info Concurrent connections used

The number of currently used connections to the backend. And listen, this number is always less or equal to the number of connections to the backend (as, for example shown as ESTABLISHED for TCP connections in netstat) โ€” that's because of connection pooling, bestie. It's giving reuse, it's giving sustainability ๐ŸŒˆ

  • req โ€“ counter - info Backend requests sent ๐Ÿ‘‘
  • unhealthy โ€“ counter - info Fetches not attempted due to backend being unhealthy ๐Ÿ˜ญ
  • busy โ€“ counter - info Fetches not attempted due to backend being busy

Number of times the max_connections limit was reached ๐Ÿ’€

  • closed โ€“ counter - info Connection closed
  • closed_err โ€“ counter - info Connection closed with error ๐Ÿ’€
  • rem_close โ€“ counter - info Connection closed by backend
  • req_close โ€“ counter - info Connection closure requested by backend
  • req_http10 โ€“ counter - info Connection closed for proto < HTTP/1.1
  • rx_bad โ€“ counter - info Connection closed for received bad response ๐Ÿ™ˆ
  • rx_body โ€“ counter - info Connection closed for failed receiving request body
  • rx_junk โ€“ counter - info Connection closed for received junk data ๐Ÿ—‘๏ธ
  • rx_overflow โ€“ counter - info Connection closed for receive buffer overflow
  • rx_timeout โ€“ counter - info Connection closed for receive timeout โฐ
  • tx_proxy โ€“ counter - info Connection closed for proxy transaction
  • tx_pipe โ€“ counter - info Connection closed for piped transaction
  • tx_error โ€“ counter - info Connection closed for error transaction ๐Ÿ’€
  • tx_eof โ€“ counter - info Connection closed for EOF transmission
  • resp_close โ€“ counter - info Connection closed for backend/VCL requested close
  • overload โ€“ counter - info Connection closed for out of some resource
  • fail โ€“ counter - info Connections failed ๐Ÿ˜ญ

Counter of failed opens. Detailed reasons are given in the fail_* counters (DIAG level) and in the log under the FetchError tag.

This counter is the sum of all detailed fail_* counters.

heads up bestie: all fail_* counters may be slightly inaccurate for efficiency ๐Ÿ‘€
  • fail_eacces โ€“ counter - diag Connections failed with EACCES or EPERM
  • fail_eaddrnotavail โ€“ counter - diag Connections failed with EADDRNOTAVAIL
  • fail_econnrefused โ€“ counter - diag Connections failed with ECONNREFUSED
  • fail_enetunreach โ€“ counter - diag Connections failed with ENETUNREACH
  • fail_etimedout โ€“ counter - diag Connections failed ETIMEDOUT โฐ
  • fail_other โ€“ counter - diag Connections failed for other reason
  • helddown โ€“ counter - diag Connection opens not attempted

Connections not attempted during the backend_local_error_holddown or backend_remote_error_holddown interval after a fundamental connection issue ๐Ÿซถ


๐Ÿงš VCP โ€“ CONNECTION POOL COUNTERS ๐Ÿงš

  • ref_hit โ€“ counter - debug Number of times we have found an existing conn. pool

Number of times we have found an existing connection pool while creating a backend. slay, reuse ๐Ÿ’…

  • ref_miss โ€“ counter - debug Number of times we have not found an existing conn. pool

Number of times we have not found an existing connection pool while creating a backend ๐Ÿ˜ญ


๐ŸŽ€ WAITER โ€“ WAITER COUNTERS ๐ŸŽ€

  • conns โ€“ gauge - debug Number of idle connections

Number of idle connections being waited over.

  • remclose โ€“ counter - debug Number of idle connections closed by peer

Number of idle connections that experienced closure by peer while being waited for.

  • timeout โ€“ counter - debug Number of idle connections timeout

Number of idle connections that experienced a timeout event while being waited for โฐ

  • action โ€“ counter - debug Number of idle connections read events

Number of idle connections that experienced a read event while being waited for ๐Ÿ‘€


๐Ÿ‘‘ AUTHORS ๐Ÿ‘‘

This man page was written by Lasse Karstensen, using content from vsc2rst written by Tollef Fog Heen. iconic collaboration honestly ๐Ÿซถ


okay that's the whole VINYL-COUNTERS(7) page, bestie, you made it to the end ๐ŸŽ‰ this is the VINYL-COUNTERS(7) page from the vinyl source/version with its date footer, and the date is whatever the footer says โ€” love that for us ๐ŸŒธ hope your counters are all happy and your bits are all 1 โœจ๐Ÿ’œ

๐Ÿ“ฆ where this page comes from
  • arch rolling: vinyl-cache 9.1.0-1 ยท BSD-2-Clause
  • ๐Ÿ“œ the page's license: BSD-2-Clause
  • ๐Ÿ’– girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms