Les informations à monitorer semblent les suivantes :
Client metrics : * client_req : number of received client requests * sess_dropped : number of connections dropped due to a full queue, if higher than 0, thread_pool_max should be increased
Cache performance : * cache_hit_rate : cache_hit / (cache_hit + cache_miss), the closer to 1 the better * cache_hitpass : the lower the better * n_expired : number of expired objects, the lower the better * n_lru_nuked : number of objects evicted because of lake of space, the lower the better
Thread metric : * threads_failed : number of times that Varnish unsuccessfully tried to create a thread * threads_limited : number of times Varnish failed to create a thread because thread_pool_max was reached * thread_queue_len : 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 metrics : * backend_fail : number of failed connections to the backend * backend_unhealthy : number of backend connections which were not attempted because the backend was unhealthy * backend_busy : number of times the maximum amount of connections to the backend has been reached * backend_req : number of requests to the backend, the rate should be stable, spike indicate cache performance issues