VARNISH-COUNTERS(7)

🌸 VARNISH-COUNTERS 🌸

okay bestie, welcome to VARNISH-COUNTERS(7) from the Miscellaneous Information Manual 💖 this is literally the dictionary of every counter field Varnish knows about, and we're going through all of them, no skipping, no cap 🫶

---

✨ NAME ✨

varnish-counters — Varnish counter field definitions 👑

Each counter below gets its name, its type (counter or gauge), and its level (debug, info or diag), plus what it actually means. Let's get into it, we're gonna eat 💅

---

🔒 LCK – LOCK COUNTERS 🔒

These ones track the activity inside the different classes of mutex-locks. Real "who's touching the locks" energy 🔥

ngl the counts may be slightly wrong if there's more than one lock instantiated in each class (ie: .creat > 1). Not a vibe, just a fact 🙈

• creat — counter — debug — Created locks. Lock babies being born ✨
• destroy — counter — debug — Destroyed locks. Lock babies going to the great lock farm upstate 😭
• locks — counter — debug — Lock Operations. Every time a lock gets operated on, this goes up 💫
• 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. Like, it's just sitting there. Silently. 💀
• 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, same silence 🫠

---

👑 MAIN – MAIN COUNTERS 👑

The main character section, obviously 🌈 every counter the child process wants you to know about.

• summs — counter — debug — stat summ operations. Counts how many times per-thread statistics got summed into the global counters 🧮
• uptime — counter — info — Child process uptime. How long the child process has been running. Living its life ⏳
• 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 if you want the tea, read the ones below 🍵
• sess_fail_econnaborted — counter — info — Session accept failures: connection aborted. Detailed reason for sess_fail: connection aborted by the client, usually harmless. The client just ghosted ✌️
• 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). We ran out of file descriptors bestie, it happens 😭
• 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. Like, if you see this, something is deeply wrong 💀
• 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 (varnishlog -g raw -i SessError). The mystery box option 📦
• 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. Not us, it's them 💅
• client_req_417 — counter — info — Client requests received, subject to 417 errors. 417 means that something went wrong with an Expect: header. Expectations? Not met 🎭
• client_req — counter — info — Good client requests received. The count of parseable client requests seen. The well-behaved ones ⭐
• 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. The dream scenario fr fr 🔥
• 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. Yes, they double dip, that's just how it is 🫠
• cache_hitpass — counter — info — Cache hits for pass. Count of hits for pass. A cache hit for pass indicates that Varnish 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. The decision said "go to backend" 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 Varnish 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. Same energy, different decision 💫
• 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 get it ourselves 😤
• beresp_uncacheable — counter — info — Uncacheable backend responses. Count of backend responses considered uncacheable. Sorry babe, not staying in the cache 🚫
• beresp_shortlived — counter — info — Shortlived objects. Count of objects created with ttl+grace+keep shorter than the 'shortlived' runtime parameter. Blink and they're gone 🦋
• backend_conn — counter — info — Backend conn. success. How many backend connections have successfully been established. We made it 🤝
• backend_unhealthy — counter — info — Backend conn. not attempted. Not even tried 😷
• backend_busy — counter — info — Backend conn. too many. Too many bestie, we're full 🚦
• backend_fail — counter — info — Backend conn. failures. It did not work 💔
• 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. Just chilling in the pool, waiting for its moment 🌊
• backend_retry — counter — info — Backend conn. retry. One more time with feeling 🔁
• 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. Standing in line, patiently 🧍
• 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. Waited the whole time and still got nothing 😭
• fetch_head — counter — info — Fetch no body (HEAD). beresp with no body because the request is HEAD. No body, just vibes 🎩
• fetch_length — counter — info — Fetch with Length. beresp.body with Content-Length. We know exactly how long it is 📏
• fetch_chunked — counter — info — Fetch chunked. beresp.body with Chunked. Chunk by chunk by chunk 🧱
• fetch_eof — counter — info — Fetch EOF. beresp.body with EOF. It just... ends 🌅
• fetch_bad — counter — info — Fetch bad T-E. beresp.body length/fetch could not be determined. Unknowable, honestly 🌀
• fetch_none — counter — info — Fetch no body. beresp.body empty. Nothing there, bestie 🕳️
• fetch_1xx — counter — info — Fetch no body (1xx). beresp with no body because of 1XX response. Just an update, no content 💌
• fetch_204 — counter — info — Fetch no body (204). beresp with no body because of 204 response. Success, but make it empty ✨
• fetch_304 — counter — info — Fetch no body (304). beresp with no body because of 304 response. Not modified, so not re-sent 💅
• fetch_failed — counter — info — Fetch failed (all causes). beresp fetch failed. Every possible way it can go wrong, rolled into one 💀
• bgfetch_no_thread — counter — info — Background fetch failed (no thread). A bgfetch triggered by a grace hit failed, no thread available. Nobody was free to do it 😴
• 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 here, they're here forever 🫶
• 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. The whole squad 🧵
• 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. We wanted more, we couldn't have more 🛑
• threads_created — counter — info — Threads created. Total number of threads created in all pools. New thread, who dis 🌱
• threads_destroyed — counter — info — Threads destroyed. Total number of threads destroyed in all pools. Gone but not forgotten 🪦
• 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. It tried to make a thread and could not 😔
• thread_queue_len — gauge — info — Length of session queue. Length of session queue waiting for threads. NB: only updates once per second. See also parameter thread_queue_limit. The line is long and it refreshes slowly ⏰
• busy_sleep — counter — info — Number of requests sent to sleep on busy objhdr. Number of requests sent to sleep without a worker thread because they found a busy object. Nap time 😴
• busy_wakeup — counter — info — Number of requests woken after sleep on busy objhdr. Number of requests taken off the busy object sleep list and rescheduled. Rise and shine ☀️
• busy_killed — counter — info — Number of requests killed after sleep on busy objhdr. Number of requests killed from the busy object sleep list due to lack of resources. Never woke up 💀
• sess_queued — counter — info — Sessions queued for thread. Number of times session was queued waiting for a thread. See also parameter thread_queue_limit. Waiting in line 🚶♀️
• sess_dropped — counter — info — Sessions dropped for thread. Number of times an HTTP/1 session was dropped because the queue was too long already. See also parameter thread_queue_limit. The line was too long, so out you go 🙈
• req_dropped — counter — info — Requests dropped. Number of times an HTTP/2 stream was refused because the queue was too long already. See also parameter thread_queue_limit. Same energy, but HTTP/2 this time 🚪
• req_reset — counter — info — Requests reset. Number of times a client left before the VCL processing of its requests completed. For HTTP/2 sessions, either the stream was reset by an RST_STREAM frame from the client, or a stream or connection error occurred. They left mid-conversation 😭
• n_object — gauge — info — object structs made. Approximate number of HTTP objects (headers + body, if present) in the cache. Approximate, so don't come for it 📦
• n_vampireobject — gauge — diag — unresurrected objects. Number of unresurrected objects. Vampire objects, undead but not back yet 🧛
• n_objectcore — gauge — info — objectcore structs made. Approximate number of object metadata elements in the cache. Each object needs an objectcore, extra objectcores are for hit-for-miss, hit-for-pass and busy objects. Every object needs its little core 🧠
• n_objecthead — gauge — info — objecthead structs made.

…and yeah, that's the approximate number of different hash entries vibing in the cache. anyway. Moving on, bestie, we got MORE counters 💖

---

• n_backend — gauge · info — Number of backends — literally just how many backends we know about. that's it, that's the counter 🫶
• n_expired — counter · info — Number of expired objects — how many objects got evicted from the cache because they were simply too old. grandma objects, gone 💀
• n_superseded — counter · diag — Number of superseded objects — how many times an object got replaced by a newer one. out with the old, in with the slay ✨
• n_lru_nuked — counter · info — Number of LRU nuked objects — how many objects got forcibly yeeted out of storage to make room for a new one. not a vibe, but necessary 😭
• n_lru_moved — counter · diag — Number of LRU moved objects — how many move operations went down on the LRU list.
• n_lru_limited — counter · info — Reached nuke_limit — how many times we needed more storage space but hit the limit 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 we needed more pipes 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, including background fetches. yes, the sneaky ones count too 🙈
• 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.

---

okay now we're getting into the transit girlies, and they're lowkey iconic 👑

• 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. one transaction and done, no cap ✨
• transit_buffered — counter · info — Buffered uncacheable response body bytes — total number of uncacheable responses 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. see sc_* diag counters for the detailed breakdown. it's giving receipts 🔍
• sess_readahead — counter · info — Session Read Ahead
• sess_herd — counter · diag — Session herd — number of times the timeout_linger triggered.

---

and now… the sc_* squad 💜 these are your session-close diag counters, one for literally every way a session can dip out:

• 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). junk fr 🗑️
• 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. bestie ghosted us 😭
• 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. slow down, queen 💅
• 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. no funds, no streams 💀
• 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 · diag — workspace_backend overflows — number of times we ran out of space in workspace_backend.
• ws_client_overflow — counter · diag — workspace_client overflows — number of times we ran out of space in workspace_client.
• ws_thread_overflow — counter · diag — workspace_thread overflows — number of times we ran out of space in workspace_thread.
• ws_session_overflow — counter · diag — workspace_session overflows — number of times we ran out of space in workspace_session.

---

shm girlies, rise ✨🌈 this is your shared memory log clique:

• 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. a single write may batch multiple records for buffered tasks. multitasking icon 🎀
• 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. waiting room behavior 😤
• 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. round and round bestie 🌀
• 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.

---

and finally for this stretch: the BANS 🚫 (not the dramatic kind, the cache kind):

• bans — gauge · info — Count of bans — number of all bans in system, including bans superseded by newer bans and bans already checked by the ban-lurker.
• bans_completed — gauge · diag — Number of bans marked 'completed' — number of bans which are no longer active, either because they got checked by the ban-lurker or superseded by newer identical bans. retired, but with honor 🫡
• bans_obj — gauge · diag — Number of bans using obj.* — number of bans which use obj.* variables. these bans can possibly be washed by the ban-lurker.
• bans_req — gauge · diag — Number of bans using req.* — number of bans which use req.* variables. these bans cannot be washed by the ban-lurker. stubborn queens 💅
• bans_added — counter · diag — Bans added — counter of bans added to ban list.
• bans_deleted — counter · diag — Bans deleted — counter of bans deleted from ban list.
• bans_tested — counter · diag — Bans tested against objects (lookup) — count of 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. rip bozo 😭
• 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. 'ban req.url == foo && req.http.host == bar' counts as one in 'bans_tested' and as two in 'bans_tests_tested'. math is mathing 🔥
• 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. '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.
• 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. 🫶

• bans_persisted_bytes — gauge / diag — Bytes used by the persisted ban lists

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

Number of objects mailed to expiry thread for handling. 📬

• exp_received — counter / diag — Number of objects received by expiry thread

Number of objects received by expiry thread for handling. 💌

• 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

Those operations occur when Varnish receives a compressed object from a backend. They are done to verify the gzip stream while it's inserted in storage. 🫧

• 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 varnishd(1)).

See also ReqTarget in vsl(7). This counter is approximately correct. 👀

---

🧺 MEMPOOL – MEMORY POOL COUNTERS

• 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

• 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 😱

---

🧱 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.

---

🌈 VBE – BACKEND COUNTERS

• happy — bitmap / info — Happy health probes

Represents the last probe results as a bitmap. Happy probes are bits set to 1, and the unhappy ones are set to 0. The highest bits represent the oldest probes. 🌸

• 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. 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) due to connection pooling.

• 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

• 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.

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. 🎯

• 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.

---

and that's a WRAP bestie 🎀 you just read the whole of VARNISH-COUNTERS(7), source and version and date footer included — go forth and read your counters like the main character you are 💅✨