backend: add VSCs for backend errors
Abstract vbe_close_acct, this is supposed to mimic the ses_close_acct for backends.
We have up until now not exposed htc->doclose (backend errors) to any counters as we do for req->doclose (session errors).
That is unfortunate as these errors code are useful when trubleshooting fetches, so expose them as bc_* counters which is a subset of the sc_* counters.
Also add counters for backend closes: backend_closed and backend_closed_err.
Besides specific comments, I am not sure if adding global counters makes much sense. If users see these increase, won't they immediately ask "yeah, but which backend?". So unless there is some specific background which might need explanations, I would suggest to skip one iteration and go straight to per-backend counters.
Good point, this was actually mentioned to me. I forgot to take that into account, but I think that make sense. However, I think we should keep the global counters such that further breakdown is available for the interested users. The global counter is a quick way to tell if looking into backends make sense.
The global counter is a quick way to tell if looking into backends make sense.
I am not entirely convinced that the double accounting pays off, but I can see that the argument has some relevance for practical purposes.
The global counter is a quick way to tell if looking into backends make sense.
I am not entirely convinced that the double accounting pays off, but I can see that the argument has some relevance for practical purposes.
See: https://github.com/varnishcache/varnish-cache/pull/4337/commits/a3fdba2c91fa602407f778c77665b636a9f1a5bc A snip from the commit message:
As some backends can come and go (dynamic backends), we should maintain the global counters as is.
So I think this is OK, but I would like to ask @asadsa92 to make life easier for reviewers. Could you please
Thanks for your 2nd review, we are getting there :smile: Yes, I will come back to you with a polished PR.
@nigoroll Thanks once again for your review, this should be ready now. To view the full diff compared to the previous version:
$ git range-diff 8a219c644..a3fdba2c9 720b939c2..