| title | tags | metaDescription | redirects | freshnessValidatedDate | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
Varnish Cache monitoring integration |
|
New Relic's Varnish Cache integration: how to install it and configure it, and what data it reports. |
|
never |
The Varnish Cache on-host integration collects and sends inventory and metrics from your Varnish Cache environment to New Relic so you can monitor its health. We collect metrics at the instance, lock, memory pool, storage, and backend levels.
Read on to install the integration, and to see what data we collect.
Our integration is compatible with Varnish Cache 1.0 or higher.
Before installing the integration, make sure that you meet the following requirements:
- Install the infrastructure agent.
- Linux distribution or Windows version compatible with our infrastructure agent.
Instrument your Varnish Cache environment quickly and send your telemetry data with guided install. Our guided install creates a customized CLI command for your environment that downloads and installs the New Relic CLI and the infrastructure agent.
Ready to get started? Click one of these button to try it out.
Guided install<ButtonLink role="button" to="https://one.eu.newrelic.com/marketplace/install-data-source?state=eda6d17b-58b5-5e7a-18ca-3b4ce777ecff" variant="primary"
EU Guided install
Our guided install uses the infrastructure agent to set up the Varnish Cache integration. Not only that, it discovers other applications and log sources running in your environment and then recommends which ones you should instrument.
The guided install works with most setups. But if it doesn't suit your needs, you can find other methods below to get started monitoring your Varnish Cache environment.
To install the Varnish Cache integration:
1. Install [the infrastructure agent](/docs/integrations/host-integrations/installation/install-infrastructure-host-integrations/#install), and replace the `INTEGRATION_FILE_NAME` variable with `nri-varnish`. 2. Change directory to the integrations folder: ```
cd /etc/newrelic-infra/integrations.d
```
3. Copy of the sample configuration file:
```
sudo cp varnish-config.yml.sample varnish-config.yml
```
4. Edit the `varnish-config.yml` file as described in the [configuration settings](#config).
<Collapser id="windows-install" title="Windows installation"
1. Download the `nri-varnish` .MSI installer image from:
[https://download.newrelic.com/infrastructure_agent/windows/integrations/nri-varnish/nri-varnish-amd64.msi](https://download.newrelic.com/infrastructure_agent/windows/integrations/nri-varnish/nri-varnish-amd64.msi)
2. To install from the Windows command prompt, run:
```
msiexec.exe /qn /i PATH\TO\nri-varnish-amd64.msi
```
3. In the Integrations directory, `C:\Program Files\New Relic\newrelic-infra\integrations.d\`, create a copy of the sample configuration file by running:
```
cp varnish-config.yml.sample varnish-config.yml
```
4. Edit the `varnish-config.yml` file as described in the [configuration settings](#config).
Additional notes:
- Advanced: It's also possible to install the integration from a tarball file. This gives you full control over the installation and configuration process.
- On-host integrations do not automatically update. For best results, regularly update the integration package and the infrastructure agent.
An integration's YAML-format configuration is where you can place required login credentials and configure how data is collected. Which options you change depend on your setup and preference.
The configuration file has common settings applicable to all integrations like interval, timeout, inventory_source. To read all about these common settings, refer to our Configuration Format document.
Specific settings related to Varnish are defined using the env section of the configuration file. These settings control the connection to your Varnish instance, as well as other security settings and features. The list of valid settings is described in the following section.
The Varnish Cache integration collects both metrics(M) and inventory(I) information. Check the Applies To column below to find which settings can be used for each specific collection:
{ ' ' }
<th>
Description
</th>
<th>
Default
</th>
<th>
Applies To
</th>
</tr>
<td>
User defined name to identify data from this instance in New Relic. <DNT>**Required**</DNT>.
</td>
<td>
N/A
</td>
<td style={{ "text-align": "center" }}>
M/I
</td>
</tr>
<tr>
<td>
<DNT>**PARAMS_CONFIG_FILE**</DNT>
</td>
<td>
The location of the `varnish.params` config file. If this argument is omitted, the following locations will be checked:
* `/etc/default/varnish/varnish.params`
* `/etc/sysconfig/varnish/varnish.params`
Note: The location and name of the Varnish configuration file may vary. For details, see [Different locations of the Varnish configuration file](https://book.varnish-software.com/4.0/chapters/Getting_Started.html#different-locations-of-the-varnish-configuration-file).
For Varnish 6 and above, this parameter is not required and the integration should be set up for metrics collection only. See [the example for Varnish 6](#example6).
</td>
<td>
N/A
</td>
<td style={{ "text-align": "center" }}>
I
</td>
</tr>
<tr>
<td>
<DNT>**VARNISH_NAME**</DNT>
</td>
<td>
Name used when executing the `varnishd` daemon with a custom `-n` flag. <DNT>**Optional**</DNT>.
</td>
<td>
N/A
</td>
<td style={{ "text-align": "center" }}>
M
</td>
</tr>
<tr>
<td>
<DNT>**METRICS**</DNT>
</td>
<td>
Set to `true` to enable metrics-only collection.
</td>
<td>
`false`
</td>
<td style={{ "text-align": "center" }}/>
</tr>
<tr>
<td>
<DNT>**INVENTORY**</DNT>
</td>
<td>
Set to `true` to enable inventory-only collection.
</td>
<td>
`false`
</td>
<td style={{ "text-align": "center" }}/>
</tr>
| Setting |
|---|
| **INSTANCE_NAME** |
The varnish-config.yml commands accept the following arguments:
The values for these settings can be defined in several ways:
- Adding the value directly in the config file. This is the most common way.
- Replacing the values from environment variables using the
{{}}notation. This requires infrastructure agent v1.14.0+. Read more here. - Using secrets management. Use this to protect sensitive information, such as passwords that would be exposed in plain text on the configuration file. For more information, see Secrets management.
Environment variables can be used to control config settings, such as your , and are then passed through to the infrastructure agent. For instructions on how to use this feature, see Configure the infrastructure agent.
You can further decorate your metrics using labels. Labels allow you to add key/value pairs attributes to your metrics which you can then use to query, filter or group your metrics on.
Our default sample config file includes examples of labels but, as they are not mandatory, you can remove, modify or add new ones of your choice.
labels:
env: production
role: varnish
Example varnish-config.yml file configuration:
```
integrations:
- name: nri-varnish
env:
INSTANCE_NAME: new_relic
PARAMS_CONFIG_FILE: /etc/default/varnish/varnish.params
interval: 15s
labels:
env: production
role: varnish
inventory_source: config/varnish
```
<Collapser id="example6" title="Configuration for Varnish 6+"
This is a basic configuration for Varnish 6 or above. Only metrics will be collected because, starting in Varnish 6, the params file was deprecated.
```
integrations:
- name: nri-varnish
env:
INSTANCE_NAME: new_relic
METRICS: true
interval: 15s
labels:
env: production
role: varnish
inventory_source: config/varnish
```
For more about the general structure of on-host integration configuration, see Configuration.
To find your integration data in New Relic, go to one.newrelic.com > All capabilities > Infrastructure > Third-party services and select one of the Varnish Cache integration links.
In New Relic, Varnish Cache data is attached to the following event type:
VarnishSampleVarnishLockSampleVarnishStorageSampleVarnishMempoolSampleVarnishBackendSample
For more on how to find and use your data, see Understand integration data.
The Varnish Cache integration collects the following metric data attributes. Each metric name is prefixed with a category indicator and a period, such as bans. or main..
These attributes can be found by querying the VarnishSample event types.
<th>
Description
</th>
</tr>
<td>
Number of times the maximum connection has been reached.
</td>
</tr>
<tr>
<td>
`backend.connectionFails`
</td>
<td>
Number of failed connections to the backed.
</td>
</tr>
<tr>
<td>
`backend.connectionRecycles`
</td>
<td>
Number of backend connections that have been recycled.
</td>
</tr>
<tr>
<td>
`backend.connectionRetries`
</td>
<td>
Number of backend connections that have been retried.
</td>
</tr>
<tr>
<td>
`backend.connectionReuses`
</td>
<td>
Number of backend connections reuses.
</td>
</tr>
<tr>
<td>
`backend.connectionSuccess`
</td>
<td>
Number of successful backend connections,
</td>
</tr>
<tr>
<td>
`backend.connectionUnHealthy`
</td>
<td>
Number of backend connections that were not attempted due to ‘unhealthy’ backend status.
</td>
</tr>
<tr>
<td>
`backend.fetches`
</td>
<td>
Total number of backend fetches initiated.
</td>
</tr>
<tr>
<td>
`backend.requests`
</td>
<td>
Total number of backend connection requests made.
</td>
</tr>
<tr>
<td>
`bans.added`
</td>
<td>
Counter of bans added to ban list.
</td>
</tr>
<tr>
<td>
`bans.completed`
</td>
<td>
Number of bans marked ‘completed'.
</td>
</tr>
<tr>
<td>
`bans.cutoffLurkerKilled`
</td>
<td>
Number of objects killed by bans for cutoff (lurker).
</td>
</tr>
<tr>
<td>
`bans.deleted`
</td>
<td>
Counter of bans deleted from ban list.
</td>
</tr>
<tr>
<td>
`bans.dups`
</td>
<td>
Count of bans replaced by later identical bans.
</td>
</tr>
<tr>
<td>
`bans.fragmentationInBytes`
</td>
<td>
Extra bytes in persisted ban lists due to fragmentation.
</td>
</tr>
<tr>
<td>
`bans.lookupKilled`
</td>
<td>
Number of objects killed by bans during object lookup.
</td>
</tr>
<tr>
<td>
`bans.lookupTestsTested`
</td>
<td>
Count of how many tests and objects have been tested against each other during lookup.
</td>
</tr>
<tr>
<td>
`bans.lurkerCon`
</td>
<td>
Number of times the ban-lurker had to wait for lookups.
</td>
</tr>
<tr>
<td>
`bans.lurkerKilled`
</td>
<td>
Number of objects killed by the ban-lurker.
</td>
</tr>
<tr>
<td>
`bans.lurkerTested`
</td>
<td>
Count of how many bans and objects have been tested against each other by the ban-lurker.
</td>
</tr>
<tr>
<td>
`bans.lurkerTestsTested`
</td>
<td>
Count of how many tests and objects have been tested against each other during by the ban-lurker.
</td>
</tr>
<tr>
<td>
`bans.obj`
</td>
<td>
Number of bans using `obj.*` variables. These bans can possibly be washed by the ban-lurker.
</td>
</tr>
<tr>
<td>
`bans.persistedInBytes`
</td>
<td>
Bytes used by the persisted ban lists.
</td>
</tr>
<tr>
<td>
`bans.req`
</td>
<td>
Number of bans which use `req.*` variables. These bans can not be washed by the ban-lurker.
</td>
</tr>
<tr>
<td>
`bans.tested`
</td>
<td>
Count of how many bans and objects have been tested against each other during hash lookup.
</td>
</tr>
<tr>
<td>
`cache.graceHits`
</td>
<td>
Count of cache hits with grace. A cache hit with grace is a cache hit where the object is expired. These hits also included in the `cache_hit` counter.
</td>
</tr>
<tr>
<td>
`cache.hits`
</td>
<td>
Number of times an object has been delivered to a client without fetching it from a backend server.
</td>
</tr>
<tr>
<td>
`cache.misses`
</td>
<td>
Number of times the object was fetched from the backend before delivering it to the client.
</td>
</tr>
<tr>
<td>
`cache.missHits`
</td>
<td>
Number of times a hit object was returned for a miss response.
</td>
</tr>
<tr>
<td>
`cache.passHits`
</td>
<td>
Number of times a hit object was returned for a pass response.
</td>
</tr>
<tr>
<td>
`esi.errors`
</td>
<td>
Edge Side Includes (ESI) parsing errors (unlock).
</td>
</tr>
<tr>
<td>
`esi.warnings`
</td>
<td>
Edge Side Includes (ESI) parse warnings (unlock).
</td>
</tr>
<tr>
<td>
`fetch.bad`
</td>
<td>
The `beresp.body` length/fetch could not be determined.
</td>
</tr>
<tr>
<td>
`fetch.chuncked`
</td>
<td>
The `beresp.body` chunked.
</td>
</tr>
<tr>
<td>
`fetch.contentLength`
</td>
<td>
The `beresp.body` with content-length.
</td>
</tr>
<tr>
<td>
`fetch.eof`
</td>
<td>
The `beresp.body` with EOF.
</td>
</tr>
<tr>
<td>
`fetch.failed`
</td>
<td>
The `beresp` failed.
</td>
</tr>
<tr>
<td>
`fetch.head`
</td>
<td>
The `beresp` with no body because the request is HEAD.
</td>
</tr>
<tr>
<td>
`fetch.noBody`
</td>
<td>
The `beresp` with no body.
</td>
</tr>
<tr>
<td>
`fetch.noBody1xx`
</td>
<td>
The `beresp` with no body because of 1XX response.
</td>
</tr>
<tr>
<td>
`fetch.noBody204`
</td>
<td>
The `beresp` with no body because of 204 response.
</td>
</tr>
<tr>
<td>
`fetch.noBody304`
</td>
<td>
The `beresp` with no body because of 304 response.
</td>
</tr>
<tr>
<td>
`fetch.noThreadFail`
</td>
<td>
The `beresp` fetch failed, no thread available.
</td>
</tr>
<tr>
<td>
`hcb.inserts`
</td>
<td>
Number of critical bit tree-based hash (HCB) inserts.
</td>
</tr>
<tr>
<td>
`hcb.lock`
</td>
<td>
Number of HCB lookups with lock.
</td>
</tr>
<tr>
<td>
`hcb.noLock`
</td>
<td>
Number of HCB lookups without lock.
</td>
</tr>
<tr>
<td>
`lru.limited`
</td>
<td>
Number of times more storage space was needed, but limit was reached.
</td>
</tr>
<tr>
<td>
`lru.moved`
</td>
<td>
Number of move operations done on the LRU list.
</td>
</tr>
<tr>
<td>
`lru.nuked`
</td>
<td>
Number of least recently used (LRU) objects forcefully evicted from storage to make room for a new object.
</td>
</tr>
<tr>
<td>
`main.backends`
</td>
<td>
Number of backends.
</td>
</tr>
<tr>
<td>
`main.bans`
</td>
<td>
Count of bans.
</td>
</tr>
<tr>
<td>
`main.busyKilled`
</td>
<td>
Number of requests killed after sleep on busy objhdr.
</td>
</tr>
<tr>
<td>
`main.busySleep`
</td>
<td>
Number of requests sent to sleep on busy objhdr.
</td>
</tr>
<tr>
<td>
`main.busyWakeup`
</td>
<td>
Number of requests woken after sleep on busy objhdr.
</td>
</tr>
<tr>
<td>
`main.expired`
</td>
<td>
Number of expired objects.
</td>
</tr>
<tr>
<td>
`main.expiredMailed`
</td>
<td>
Number of objects mailed to expiry thread.
</td>
</tr>
<tr>
<td>
`main.expiredReceived`
</td>
<td>
Number of objects received by expiry thread.
</td>
</tr>
<tr>
<td>
`main.gunzip`
</td>
<td>
Number of gunzip operations.
</td>
</tr>
<tr>
<td>
`main.gunzipTest`
</td>
<td>
Number of test gunzip operations.
</td>
</tr>
<tr>
<td>
`main.gzip`
</td>
<td>
Number of gzip operations.
</td>
</tr>
<tr>
<td>
`main.objectcores`
</td>
<td>
Number of objectcore structs made.
</td>
</tr>
<tr>
<td>
`main.objectheads`
</td>
<td>
Number of objected structs made.
</td>
</tr>
<tr>
<td>
`main.objects`
</td>
<td>
Number of object structs made.
</td>
</tr>
<tr>
<td>
`main.passedRequests`
</td>
<td>
Total pass-ed requests seen.
</td>
</tr>
<tr>
<td>
`main.pipeSessions`
</td>
<td>
Total pipe sessions seen.
</td>
</tr>
<tr>
<td>
`main.pools`
</td>
<td>
Number of thread pools.
</td>
</tr>
<tr>
<td>
`main.purgeObjects`
</td>
<td>
Number of purged objects.
</td>
</tr>
<tr>
<td>
`main.purgeOperations`
</td>
<td>
Number of purge operations executed.
</td>
</tr>
<tr>
<td>
`main.reqDropped`
</td>
<td>
Number of requests dropped.
</td>
</tr>
<tr>
<td>
`main.sessions`
</td>
<td>
Total number of sessions seen.
</td>
</tr>
<tr>
<td>
`main.sessQueueLength`
</td>
<td>
Length of session queue waiting for threads.
</td>
</tr>
<tr>
<td>
`main.summs`
</td>
<td>
Number of times per-thread statistics were summed into the global counters.
</td>
</tr>
<tr>
<td>
`main.syntheticResponses`
</td>
<td>
Total synthethic responses made.
</td>
</tr>
<tr>
<td>
`main.threads`
</td>
<td>
Total number of threads.
</td>
</tr>
<tr>
<td>
`main.threadsCreated`
</td>
<td>
Total number of threads created in all pools.
</td>
</tr>
<tr>
<td>
`main.threadsDestroyed`
</td>
<td>
Total number of threads destroyed in all pools.
</td>
</tr>
<tr>
<td>
`main.threadsFailed`
</td>
<td>
Number of times creating a thread failed.
</td>
</tr>
<tr>
<td>
`main.threadsLimited`
</td>
<td>
Number of times more threads were needed, but limit was reached in a thread pool.
</td>
</tr>
<tr>
<td>
`main.unresurrectedObjects`
</td>
<td>
Number of unresurrected objects.
</td>
</tr>
<tr>
<td>
`main.uptimeInMilliseconds`
</td>
<td>
The child process uptime, in milliseconds.
</td>
</tr>
<tr>
<td>
`main.vclAvailable`
</td>
<td>
Number of Varnish Configuration Languages (VCL) available.
</td>
</tr>
<tr>
<td>
`main.vclDiscarded`
</td>
<td>
Number of discarded VCLs.
</td>
</tr>
<tr>
<td>
`main.vclFails`
</td>
<td>
Number of VCL failures.
</td>
</tr>
<tr>
<td>
`main.vclLoaded`
</td>
<td>
Number of loaded VCLs in total.
</td>
</tr>
<tr>
<td>
`main.vmodsLoaded`
</td>
<td>
Number of loaded Varnish modules (VMOD).
</td>
</tr>
<tr>
<td>
`mgt.childDied`
</td>
<td>
Number of times the child process has died due to signals.
</td>
</tr>
<tr>
<td>
`mgt.childDump`
</td>
<td>
Number of times the child process has produced core dumps.
</td>
</tr>
<tr>
<td>
`mgt.childExit`
</td>
<td>
Number of times the child process has been cleanly stopped.
</td>
</tr>
<tr>
<td>
`mgt.childPanic`
</td>
<td>
Number of times the management process has caught a child panic.
</td>
</tr>
<tr>
<td>
`mgt.childStart`
</td>
<td>
Number of times the child process has been started.
</td>
</tr>
<tr>
<td>
`mgt.childStop`
</td>
<td>
Number of times the child process has been cleanly stopped.
</td>
</tr>
<tr>
<td>
`mgt.uptimeInMilliseconds`
</td>
<td>
The management process uptime, in milliseconds.
</td>
</tr>
<tr>
<td>
`net.400Errors`
</td>
<td>
Number of client requests received, subject to 400 errors.
</td>
</tr>
<tr>
<td>
`net.417Errors`
</td>
<td>
Number of client requests received, subject to 417 errors
</td>
</tr>
<tr>
<td>
`net.httpOverflow`
</td>
<td>
Number of HTTP header overflows.
</td>
</tr>
<tr>
<td>
`net.pipe.inInBytes`
</td>
<td>
Total number of bytes forwarded from clients in pipe sessions.
</td>
</tr>
<tr>
<td>
`net.pipe.outInBytes`
</td>
<td>
Total number of bytes forwarded to clients in pipe sessions.
</td>
</tr>
<tr>
<td>
`net.pipereq.headerInBytes`
</td>
<td>
Total request bytes received for piped sessions.
</td>
</tr>
<tr>
<td>
`net.request.bodyInBytes`
</td>
<td>
Total request body transmitted, in bytes.
</td>
</tr>
<tr>
<td>
`net.request.headerInBytes`
</td>
<td>
Total request headers transmitted, in bytes.
</td>
</tr>
<tr>
<td>
`net.requests`
</td>
<td>
Number of good client requests received.
</td>
</tr>
<tr>
<td>
`net.response.bodyInBytes`
</td>
<td>
Total response body transmitted, in bytes.
</td>
</tr>
<tr>
<td>
`net.response.headerInBytes`
</td>
<td>
Total response headers transmitted, in bytes.
</td>
</tr>
<tr>
<td>
`sess.backendClose`
</td>
<td>
Number of session closes with the error `RESP_CLOSE`, (Backend/VCL requested close).
</td>
</tr>
<tr>
<td>
`sess.badClose`
</td>
<td>
Number of session closes with the error `Error RX_BAD`, (Received bad req/resp).
</td>
</tr>
<tr>
<td>
`sess.bodyFailClose`
</td>
<td>
Number of session closes with the error `Error RX_BODY`, (Failure receiving req.body).
</td>
</tr>
<tr>
<td>
`sess.clientClose`
</td>
<td>
Number of session closes with the error `REM_CLOSE`, (Client closed).
</td>
</tr>
<tr>
<td>
`sess.clientReqClose`
</td>
<td>
Number of session closes with the error `REQ_CLOSE`, (Client requested close).
</td>
</tr>
<tr>
<td>
`sess.closed`
</td>
<td>
Total number of sessions closed.
</td>
</tr>
<tr>
<td>
`sess.closedError`
</td>
<td>
Total number of sessions closed with errors.
</td>
</tr>
<tr>
<td>
`sess.dropped`
</td>
<td>
Number of sessions dropped for thread.
</td>
</tr>
<tr>
<td>
`sess.eofTxnClose`
</td>
<td>
Number of session closes with the error `TX_EOF`, (EOF transmission).
</td>
</tr>
<tr>
<td>
`sess.errorTxnClose`
</td>
<td>
Number of session closes with the error `TX_ERROR`, (Error transaction).
</td>
</tr>
<tr>
<td>
`sess.herd`
</td>
<td>
Number of times the `timeout_linger` triggered.
</td>
</tr>
<tr>
<td>
`sess.junkClose`
</td>
<td>
Number of session closes with the error `RX_JUNK`, (Received junk data).
</td>
</tr>
<tr>
<td>
`sess.overflowClose`
</td>
<td>
Number of session closes with the error `RX_OVERFLOW`, (Received buffer overflow).
</td>
</tr>
<tr>
<td>
`sess.overloadClose`
</td>
<td>
Number of session closes with the error `OVERLOAD`, (Out of some resource).
</td>
</tr>
<tr>
<td>
`sess.pipeOverflowClose`
</td>
<td>
Number of session closes with the error `PIPE_OVERFLOW`, (Session pipe overflow).
</td>
</tr>
<tr>
<td>
`sess.pipeTxnClose`
</td>
<td>
Number of session closes with the error `TX_PIPE`, (Piped transaction).
</td>
</tr>
<tr>
<td>
`sess.queued`
</td>
<td>
Number of sessions queued for thread.
</td>
</tr>
<tr>
<td>
`sess.readAhead`
</td>
<td>
Session Read Ahead.
</td>
</tr>
<tr>
<td>
`sess.requestHTTP10Close`
</td>
<td>
Number of session closes with the error `REQ_HTTP10`, (Proto < HTTP/1.1).
</td>
</tr>
<tr>
<td>
`sess.requestHTTP20Close`
</td>
<td>
Number of session closes with the error `REQ_HTTP20`, (HTTP2 not accepted).
</td>
</tr>
<tr>
<td>
`sess.shortRangeClose`
</td>
<td>
Number of session closes with the error `RANGE_SHORT`, (Insufficient data for range).
</td>
</tr>
<tr>
<td>
`sess.timeoutClose`
</td>
<td>
Number of session closes with the error `RX_TIMEOUT`, (Receive timeout).
</td>
</tr>
<tr>
<td>
`sess.vclFailClose`
</td>
<td>
Number of session closes with the error `VCL_FAILURE`, (VCL failure).
</td>
</tr>
<tr>
<td>
`session.connections`
</td>
<td>
Count of sessions successfully accepted.
</td>
</tr>
<tr>
<td>
`session.drops`
</td>
<td>
Count of sessions silently dropped due to lack of worker thread.
</td>
</tr>
<tr>
<td>
`session.fail`
</td>
<td>
Count of failures to accept TCP connection.
</td>
</tr>
<tr>
<td>
`shm.contentions`
</td>
<td>
Number of shared memory (SHM) MTX contentions.
</td>
</tr>
<tr>
<td>
`shm.cycles`
</td>
<td>
Number of SHM cycles through buffer.
</td>
</tr>
<tr>
<td>
`shm.flushes`
</td>
<td>
Number of SHM flushes due to overflow.
</td>
</tr>
<tr>
<td>
`shm.records`
</td>
<td>
Number of SHM records.
</td>
</tr>
<tr>
<td>
`shm.writes`
</td>
<td>
Number of SHM writes.
</td>
</tr>
<tr>
<td>
`workspace.backendOverflow`
</td>
<td>
Number of times we ran out of space in `workspace_backend`.
</td>
</tr>
<tr>
<td>
`workspace.clientOverflow`
</td>
<td>
Number of times we ran out of space in `workspace_client`.
</td>
</tr>
<tr>
<td>
`workspace.deliveryFail`
</td>
<td>
Delivery failed due to insufficient workspace.
</td>
</tr>
<tr>
<td>
`workspace.sessionOverflow`
</td>
<td>
Number of times we ran out of space in `workspace_session`.
</td>
</tr>
<tr>
<td>
`workspace.threadOverflow`
</td>
<td>
Number of times we ran out of space in `workspace_thread`.
</td>
</tr>
| Metric |
|---|
| `backend.connectionBusy` |
These attributes can be found by querying the VarnishLockSample event type.
<th>
Description
</th>
</tr>
<td>
Count of created locks.
</td>
</tr>
<tr>
<td>
`lock.destroyed`
</td>
<td>
Count of destroyed locks.
</td>
</tr>
<tr>
<td>
`lock.locks`
</td>
<td>
Count of lock operations.
</td>
</tr>
| Metric |
|---|
| `lock.created` |
These attributes can be found by querying the VarnishStorageSample event type.
<th>
Description
</th>
</tr>
<td>
Number of times the storage has failed to provide a storage segment.
</td>
</tr>
<tr>
<td>
`storage.allocInBytes`
</td>
<td>
Number of total bytes allocated by this storage.
</td>
</tr>
<tr>
<td>
`storage.allocOustanding`
</td>
<td>
Number of storage allocations outstanding.
</td>
</tr>
<tr>
<td>
`storage.allocReqs`
</td>
<td>
Number of times the storage has been asked to provide a storage segment.
</td>
</tr>
<tr>
<td>
`storage.availableInBytes`
</td>
<td>
Number of bytes left in the storage.
</td>
</tr>
<tr>
<td>
`storage.freeInBytes`
</td>
<td>
Number of total bytes returned to this storage.
</td>
</tr>
<tr>
<td>
`storage.outstandingInBytes`
</td>
<td>
Number of bytes allocated from the storage.
</td>
</tr>
| Metric |
|---|
| `storage.allocFails` |
These attributes can be found by querying the VarnishMempoolSample event type.
<th>
Description
</th>
</tr>
<td>
Allocated size of memory pool, in bytes.
</td>
</tr>
<tr>
<td>
`mempool.allocs`
</td>
<td>
Memory pool allocations.
</td>
</tr>
<tr>
<td>
`mempool.frees`
</td>
<td>
Number of memory pools free.
</td>
</tr>
<tr>
<td>
`mempool.live`
</td>
<td>
Number of memory pools in use.
</td>
</tr>
<tr>
<td>
`mempool.pool`
</td>
<td>
Count in memory pool.
</td>
</tr>
<tr>
<td>
`mempool.ranDry`
</td>
<td>
Pool ran dry.
</td>
</tr>
<tr>
<td>
`mempool.recycles`
</td>
<td>
Recycled from pool.
</td>
</tr>
<tr>
<td>
`mempool.requestSizeInBytes`
</td>
<td>
Request size of memory pool, in bytes.
</td>
</tr>
<tr>
<td>
`mempool.surplus`
</td>
<td>
Too many for pool.
</td>
</tr>
<tr>
<td>
`mempool.timeouts`
</td>
<td>
Timed out from pool.
</td>
</tr>
<tr>
<td>
`mempool.tooSmall`
</td>
<td>
Too small to recycle.
</td>
</tr>
| Metric |
|---|
| `mempool.allocatedSizeInBytes` |
These attributes can be found by querying the VarnishBackendSample event type.
<th>
Description
</th>
</tr>
<td>
Fetches not attempted due to backend being busy.
</td>
</tr>
<tr>
<td>
`backend.connections`
</td>
<td>
Number of concurrent connections to the backend.
</td>
</tr>
<tr>
<td>
`backend.connectionsFailed`
</td>
<td>
Number of backend connections failed.
</td>
</tr>
<tr>
<td>
`backend.connectionsNotAttempted`
</td>
<td>
Number of backend connection opens not attempted.
</td>
</tr>
<tr>
<td>
`backend.happy`
</td>
<td>
Happy health probes.
</td>
</tr>
<tr>
<td>
`backend.unhealtyFetches`
</td>
<td>
Fetches not attempted due to backend being unhealthy
</td>
</tr>
<tr>
<td>
`net.backend.pipeHeaderInBytes`
</td>
<td>
Total request bytes sent for piped sessions.
</td>
</tr>
<tr>
<td>
`net.backend.pipeInInBytes`
</td>
<td>
Total number of bytes forwarded from backend in pipe sessions.
</td>
</tr>
<tr>
<td>
`net.backend.pipeOutInBytes`
</td>
<td>
Total number of bytes forwarded to backend in pipe sessions.
</td>
</tr>
<tr>
<td>
`net.backend.requestBodyInBytes`
</td>
<td>
Total backend request body bytes sent.
</td>
</tr>
<tr>
<td>
`net.backend.requestHeaderInBytes`
</td>
<td>
Total backend request header bytes sent.
</td>
</tr>
<tr>
<td>
`net.backend.requests`
</td>
<td>
Number of backend requests sent,
</td>
</tr>
<tr>
<td>
`net.backend.responseBodyInBytes`
</td>
<td>
Total backend response body bytes received.
</td>
</tr>
<tr>
<td>
`net.backend.responseHeaderInBytes`
</td>
<td>
Total backend response header bytes received.
</td>
</tr>
| Metric |
|---|
| `backend.busyFetches` |
The Varnish Cache integration captures the configuration parameters. It parses the varnish.params configuration file for all parameters that are active.
The data is available on the Inventory page, under the config/varnish source. For more about inventory data, see Understand integration data.
This integration is open source software. That means you can browse its source code and send improvements, or create your own fork and build it.