Re: [squid-users] Want to monitor squid, by pulling an image which is local.

On 28/05/11 05:02, Tory M Blue wrote:
> On Fri, May 27, 2011 at 1:39 AM, Amos Jeffries<squid3_at_treenet.co.nz> wrote:
>> On 27/05/11 10:05, Tory M Blue wrote:
>>>
>>
>> Seems to be some confusion.
>>
>> Stale vs non-stale content is a matter for the website cache control HTTP
>> headers. Squid *will* serve stale content according to RFC 2616.
>>
>> Proxy up/down merely determines how much lag the client gets exposed to as
>> unavailable peers get contacted for data.
>>
>> A peer is unavailable if either its box is down OR you manually dropped it
>> out. It can't be available while shutdown, for instance.
>>
>> Now why does the Squid box being up/down matter independently of Squid
>> itself?
>
> Say Squid crashes, my icmp host check will succeed and with no other
> check in place the squid server continues to be passed end user
> requests that it can't hope to fulfill.So end users get errors.
> (Remember the F5 accepted the connection and passed it on to a now
> defunct server, so there is no real client side retransmission or
> other, the user will get a 404 or other error.).
>

Aha. Yes. There is the real problem. The F5 itself now knowing the VIP
needs updating.

> Another scenario I have a monitor check that grabs an image from a
> cache_peer through squid, it succeeds squid is up and running, the LB
> leaves squid in the VIP. Now we take the cache_peers down, or they
> fail, overloaded or something<shrug>, the LB tries to pull a test
> image through squid, it fails (cache_peer is not available), the LB
> pulls the squid cache(s) out of the VIP as well. I'm now completely
> down, vs having sometime for the caches to serve data from it's local
> store (I believe with my testing, that if the cache_peer is not
> available and Squid has the requested image, it will serve it up,
> regardless of age (could be stale, can't revalidate it etc). Am I
> mistaken?
>

You are partialy correct. For cacheable objects that is true.
Non-cacheables not being stored at all will just fail.

Then there are a few things in the config file and some in HTTP itself
which can force files out of storage to start producing errors.

>
>> Squid has a set of icons which it loads for FTP directory listings etc.
>> They are configured in the /etc/squid/mime.conf configuration file.
>>
>> If you need a test image loaded by Squid the URL
>> http://$host/squid-internal-static/icons/unknown.gif
>> should come back from squid-2 with a question-mark icon.
>
> Your a prince, but who is Anthony?
>
> squid-internal-static/icons/anthony-unknown.gif :)
>

Doh. Been playing with the new ones to much :)

>>>
>>> monitorurl doesn't quite do it, since I'm looking for a test from a
>>> 3rd party device.
>>
>> monitorurl takes any URL you want *through* the cache_peer link. If it comes
>> back okay the peer is assumed to be accessible and ready to accept traffic.
>>
>
> Yes, but as you can see I'm trying to verify that the squid process is
> working, I have other checks to verify that the cache_peers are up and
> running (Again another LB monitor that checks for a status file,
> up/down (for maintenance reasons).
>
> But.. So what happens if the monitorurl fails?

The peer is declared "dead" and the querying Squid starts selecting
another peer server until the test starts working again.

I think I got a little confused because you have two layers of scenario
going on. client->F5->Squid (icon test F5->Squid) and Squid->peer
(monitorurl test)

>
> -Thanks again sir, I owe you a beer/coffee/soda/some variety of flavored water
>
> Tory

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.12
   Beta testers wanted for 3.2.0.7 and 3.1.12.1