Hi Rodney,
There are far better qualified folks than me on here to answer this
question, but to get you started, the following are worth monitoring:
--
cache_miss
If this is high then you can probably improve your configuration to get
more requests served from the cache.
--
n_lru_nuked
If this has data then your cache memory is not enough to support
everything you could be caching.
--
And it's not in your list, but I would monitor:
uptime
If this keeps getting reset then there is a problem with your setup and
the server is having to restart itself.
--
As I said, some to get you started, there are certainly others you could
monitor. You may want to consider reading the Varnish book and making
your own decisions:
http://book.varnish-software.com/4.0/
-or -
https://info.varnish-software.com/the-varnish-book
Best,
Nigel
On 26/04/2017 09:02, Rodney Bizzell wrote:
Hello,
What are some suggestions for selecting what should be monitored with
third party software such as Solar Winds to ensure optimal performance
of the varnish servers. My Network operations team just asked me what
specifically do I need to have monitored within Varish
*Name*
*Description*
*sess_conn*
Cumulative number of accepted client connections by Varnish Cache
*client_req*
Cumulative number of received client requests. Increments after a
request is received, but before Varnish responds
*sess_dropped*
Number of connections dropped due to a full queue
*cache_hit*
Cumulative number of times a file was served from Varnish’s cache
*cache_miss*
Cumulative number of times a file was requested but was not in the
cache, and was therefore requested from the backend
*cache_hitpass*
Cumulative number of hits for a “pass” file
*n_expired*
Cumulative number of expired objects for example due to TTL
*n_lru_nuked*
Least Recently Used Nuked Objects: Cumulative number of cached objects
that Varnish has evicted from the cache because of a lack of space
*threads*
Number of threads in all pools
*threads_created*
Number of times a thread has been created
*threads_failed*
Number of times that Varnish unsuccessfully tried to create a thread
*threads_limited*
Number of times a thread needed to be created but couldn't because
varnishd maxed out its configured capacity for new threads
*thread_queue_len*
Current queue length: number of requests waiting on worker thread to
become available
*sess_queued*
Number of times Varnish has been out of threads and had to queue up a
request
*backend_conn*
Cumulative number of successful TCP connections to the backend
*backend_recycle*
Cumulative number of current backend connections which were put back to
a pool of keep-alive connections and have not yet been used
*backend_reuse*
Cumulative number of connections that were reused from the keep-alive pool
*backend_toolate*
Cumulative number of backend connections that have been closed because
they were idle for too long
*backend_fail*
Cumulative number of failed connections to the backend
*backend_unhealthy*
Cumulative number of backend connections which were not attempted
because the backend has been marked as unhealthy
*backend_busy*
Cumulative number of times the maximum amount of connections to the
backend has been reached
*backend_req*
Number of requests to the backend
This email (including any attachments) may contain confidential
information intended solely for acknowledged recipients. If you think
you have received this information in error, please reply to the sender
and delete all copies from your system. Please note that unauthorized
use, disclosure, or further distribution of this information is
prohibited by the sender. Note also that we may monitor email directed
to or originating from our network. Thank you for your consideration and
assistance. |
_______________________________________________
varnish-misc mailing list
[email protected]
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
_______________________________________________
varnish-misc mailing list
[email protected]
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
