--
Guillaume Quintard
On Fri, Dec 17, 2021 at 5:18 AM Batanun B wrote:
> Is there even an official word for this final "cache key"? "Hash" clearly
> isn't specific enough. I'm talking about a word that refers to the unique
> key that always corresponds to only a _single_ version of a cached
> I'd suggest to determine the correct delivery of the front page via an
> external monitoring
> (e.g. icinga2 or a simple script). As far as I understand, you don't need to
> know the exact request, but more of a rough point in time of when the requests
> start failing. So a monitoring script
On 2021-12-17 15:25:31, Batanun B wrote:
> Thanks. I have thought about that too. But I think we might want to include
> non-error transactions as well. I mean, with the problems this post is about
> we want to see when the cached version of the start page was generated and
> when it was last
> I recommend permanent logging, if you want to be able to debug older
> incidents.
> We do it like this:
>
> ```
> /usr/bin/varnishlog -w /var/log/varnish/varnish-500.log -a -D \
> -P /var/run/varnishlog-500.pid \
> -q 'RespStatus >= 500 or BerespStatus >=500'
> ```
>
> I
On 2021-12-17 13:16:42, Batanun B wrote:
> > The default VSL space is 80MB, which is "only" worth a few (tens of)
> > thousands requests, so yeah, it can be a short backlog.
>
> Yeah, I think 80MB is a bit to small for us. Ideally we should be able to sit
> down on a Monday and troubleshoot
> Easy one: you build the key from the request, while the vary header is a
> response property. Therefore, Varnish can't know to put the varied headers
> into the hash, because it doesn't have that information yet.
Of course! Makes perfect sense. But the documentation should make this crystal
