嘿家伙，我希望你能帮我在这里。
我有一个NgingxparsingHTTP和https清漆caching（3.0.2）。 从清漆发送到apache2。 现在我有一段时间一直在跟踪一些奇怪的503错误。 但我似乎找不到银弹。
目前我通过varnish通过这种方式logging503错误：
sudo varnishlog -c -m TxStatus:503 >> /home/rj/varnishlog503.log
然后引用apache访问日志来查看是否处理了503个请求。
今天，我从防火墙的健康检查失败：
20 SessionOpen c 127.0.0.1 34319 :8081 20 ReqStart c 127.0.0.1 34319 607335635 20 RxRequest c HEAD 20 RxURL c /health-check 20 RxProtocol c HTTP/1.0 20 RxHeader c X-Real-IP: 192.168.3.254 20 RxHeader c Host: 192.168.3.189 20 RxHeader c X-Forwarded-For: 192.168.3.254 20 RxHeader c Connection: close 20 RxHeader c User-Agent: Astaro Service Monitor 0.9 20 RxHeader c Accept: */* 20 VCL_call c recv lookup 20 VCL_call c hash 20 Hash c /health-check 20 VCL_return c hash 20 VCL_call c miss fetch 20 Backend c 33 aurum aurum 20 FetchError c http first read error: -1 11 (No error recorded) 20 VCL_call c error deliver 20 VCL_call c deliver deliver 20 TxProtocol c HTTP/1.1 20 TxStatus c 503 20 TxResponse c Service Unavailable 20 TxHeader c Server: Varnish 20 TxHeader c Content-Type: text/html; charset=utf-8 20 TxHeader c Retry-After: 5 20 TxHeader c Content-Length: 879 20 TxHeader c Accept-Ranges: bytes 20 TxHeader c Date: Wed, 06 Jun 2012 12:35:12 GMT 20 TxHeader c X-Varnish: 607335635 20 TxHeader c Age: 60 20 TxHeader c Via: 1.1 varnish 20 TxHeader c Connection: close 20 Length c 879 20 ReqEnd c 607335635 1338986052.649786949 1338986112.648169994 0.000160217 59.997980356 0.000402689
现在，后端服务器（apache）在此时的访问日志中没有任何503错误。 所以我很困惑。 这个清漆抛出一个503，因为它认为阿帕奇慢？ 现在有很多stream量，所以我知道服务器正在运行。
我确实有其他503错误代码的post，所以没有任何模式。 这似乎是在随机的时间和随机的请求。 即使在早上，服务器似乎没有做任何事情。
我在日志中看到另一种模式：
4 VCL_call c recv pass 4 VCL_call c hash 4 Hash c /?id=412 4 VCL_return c hash 4 VCL_call c pass pass 4 FetchError c no backend connection 4 VCL_call c error deliver 4 VCL_call c deliver deliver
这里fetcherror说“没有后端连接”。 在今天的日志中的FetchErrors摘要：
16 FetchError c http first read error: -1 11 (No error recorded) 5 FetchError c http first read error: -1 11 (No error recorded) 4 FetchError c http first read error: -1 11 (No error recorded) 19 FetchError c http first read error: -1 11 (No error recorded) 5 FetchError c http first read error: -1 11 (No error recorded) 23 FetchError c http first read error: -1 11 (No error recorded) 24 FetchError c http first read error: -1 11 (No error recorded) 16 FetchError c http first read error: -1 11 (No error recorded) 6 FetchError c http first read error: -1 11 (No error recorded) 4 FetchError c http first read error: -1 11 (No error recorded) 5 FetchError c http first read error: -1 11 (No error recorded) 4 FetchError c http first read error: -1 11 (No error recorded) 4 FetchError c http first read error: -1 11 (No error recorded) 22 FetchError c http first read error: -1 11 (No error recorded) 6 FetchError c http first read error: -1 11 (No error recorded) 21 FetchError c http first read error: -1 11 (No error recorded) 26 FetchError c no backend connection 4 FetchError c no backend connection 20 FetchError c http first read error: -1 11 (No error recorded) 39 FetchError c http first read error: -1 11 (No error recorded)
我没有更改清漆的默认超时值。 这是我的后端服务器之一的configuration。
backend xenon { .host = "192.168.3.187"; .port = "80"; .probe = { .url = "/health-check/"; .interval = 3s; .window = 5; .threshold = 2; } }
我使用这个configuration在apache2上运行prefork模块
<IfModule mpm_prefork_module> StartServers 1 MinSpareServers 2 MaxSpareServers 5 MaxClients 200 MaxRequestsPerChild 75 </IfModule>
只有PHP文件被发送到服务器。 其他的静态文件都是由Nginx处理的。
有任何想法吗？
——-编辑————–
一些更多的debugging信息
我已经运行了varnishadm debug.health
Backend radon is Healthy Current states good: 5 threshold: 2 window: 5 Average responsetime of good probes: 0.002560 Oldest Newest ================================================================ 4444444444444444444444444444444444444444444444444444444444444444 Good IPv4 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy Backend xenon is Healthy Current states good: 5 threshold: 2 window: 5 Average responsetime of good probes: 0.002760 Oldest Newest ================================================================ 4444444444444444444444444444444444444444444444444444444444444444 Good IPv4 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy Backend iridium is Healthy Current states good: 5 threshold: 2 window: 5 Average responsetime of good probes: 0.000849 Oldest Newest ================================================================ 4444444444444444444444444444444444444444444444444444444444444444 Good IPv4 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy Backend aurum is Healthy Current states good: 5 threshold: 2 window: 5 Average responsetime of good probes: 0.002100 Oldest Newest ================================================================ 4444444444444444444444444444444444444444444444444444444444444444 Good IPv4 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy
而且我一直在监测两台负载均衡器的varnishstat
3224774 3.99 2.61 backend_conn - Backend conn. success 27 0.00 0.00 backend_unhealthy - Backend conn. not attempted 63 0.00 0.00 backend_fail - Backend conn. failures 358798 0.00 0.29 backend_reuse - Backend conn. reuses 21035 0.00 0.02 backend_toolate - Backend conn. was closed 379834 0.00 0.31 backend_recycle - Backend conn. recycles 26 0.00 0.00 backend_retry - Backend conn. retry 3217751 5.99 2.61 backend_conn - Backend conn. success 32 0.00 0.00 backend_fail - Backend conn. failures 364185 0.00 0.30 backend_reuse - Backend conn. reuses 27077 0.00 0.02 backend_toolate - Backend conn. was closed 391263 0.00 0.32 backend_recycle - Backend conn. recycles 36 0.00 0.00 backend_retry - Backend conn. retry
请注意，他们都没有报告backend_fail。
/罗尼
我希望这是一个错字，但是您提到访问日志中没有错误？ 这个错误会出现在错误日志中（ – ：如果你还没有检查，那么这个文件叫做error_log ，同时检查你的httpd.conf是否有错误日志级别，尝试设置它进行debug ，然后重新启动以查看更多错误日志中的详细信息，我相信默认值是warn ，请注意，debugging有一个性能开销，所以直到你有必要的数据，并设置回warn 。
另一个要考虑的问题是增加/调整一些prefork设置。 如果你看到大量的stream量“通过，这些都是太低 – 国际海事组织。这是我的RHEL 6.1，Apache 2.2的默认值：
<IfModule prefork.c> StartServers 8 MinSpareServers 5 MaxSpareServers 20 ServerLimit 256 MaxClients 256 MaxRequestsPerChild 4000 </IfModule>
最佳的设置取决于你安装的Apache和你正在运行的硬件 – 内存，CPU等。我会开始轻轻地增加前三个。 有关这些参数的更多信息，请参阅Apache MPM prefork 。
如果这是一个繁忙的服务器，我认为这是因为你说“这里有很多stream量，所以我知道服务器启动和运行”你先评估你的Apacheconfiguration，以处理stream量潮？ 其次，你使用nginx来代理请求清漆，你有没有为请求设置一个重试值？ 例如，当使用Apache Proxypass你可以做这样的事情
ProxyPass / http://192.1.1.11:9001/ retry=3 timeout=5
这将使代理服务器重新尝试这些请求。 find相当于这个nginx。 这可能有助于减less503s的数量，但如果是stream量问题，则需要最终解决。 也可以考虑使用haproxy而不是nginx进行代理，因为这就是它的作用。
我在Apache中遇到了这个问题，解决scheme是下面的组合（请注意，我在AWS EC2的Ubuntu 14.04 LTS上使用Apache / 2.4.7（Ubuntu）+ varnish 3.0.5-2）：
请记住，这是针对Amazon EC2上的M3.Medium实例制作的（1x Intel Xeon E5-2670核心+ 3.75GB RAM）。 根据您的硬件需要进行调整！
在/etc/default/varnish ，编辑你的启动选项：
DAEMON_OPTS="-a :80 \ -T localhost:6082 \ -f /etc/varnish/default.vcl \ -S /etc/varnish/secret \ -p thread_pools=2 \ -p thread_pool_max=600 \ -p listen_depth=1024 \ -p lru_interval=900 \ -p connect_timeout=600 \ -p max_restarts=6 \ -s malloc,1G"
在/etc/varnish/default.vcl或你的VCL是什么，改变后端超时（注意，我们也在/ etc / default / varnish中设置）：
backend default { .host = "127.0.0.1"; .port = "8000"; .connect_timeout = 600s; .first_byte_timeout = 600s; .between_bytes_timeout = 600s; }
禁用KeepAlives。 这个页面有更多的信息（取决于后端networking服务器软件）： http ： //www.feedthebot.com/pagespeed/keep-alive.html
对于Apache，我所要做的就是将/etc/apache2/apache2.conf中的第92行更改为以下内容：
KeepAlive Off
我认为在这里发生的事情是，在后端networking服务器软件中实施的KeepAlive正在发送明确的连接重置，而Varnish并不适用。 这个故事可能还有更多的内容，我鼓励你们深入研究，并在这里发表你的发现，供后人学习。
补充阅读： – https://www.varnish-cache.org/trac/wiki/Future_Feature#Keepalivetimeoutonbackendconnections （还有一些，但不能发布的链接。一些谷歌search“清漆keepalive后端超时”应该浮出水面想）
更多的debugging帮助：如果仍然卡住，请尝试执行以下操作： – 在您的Varnish服务器上启动varnishlog -w err.log – 在您的客户端上，获取Siege： http : //www.joedog.org/siege-home/并加载一些你看过的url503（提示：urls.txt，使用-i -b -c500 -r10 ，它应该足以触发503s） – 启动varnishlog -r temp -c -m 'TxStatus:503' > err-parsed.txt 。 这将获取Varnish返回503的所有Varnish日志条目。FWIW，这是我的一个错误的全文。 TL;错误Varnish报告的错误是FetchError c http first read error: -1 0 (Success) ：
936 SessionOpen c 10.8.226.98 51895 :80 936 ReqStart c 10.8.226.98 51895 357447130 936 RxRequest c GET 936 RxURL c /ip/69.120.68.54 936 RxProtocol c HTTP/1.1 936 RxHeader c Host: 10.201.81.157 936 RxHeader c Accept: */* 936 RxHeader c Accept-Encoding: gzip 936 RxHeader c User-Agent: Mozilla/5.0 (apple-x86_64-darwin11.4.2) Siege/3.0.5 936 RxHeader c Connection: close 936 VCL_call c recv lookup 936 VCL_call c hash 936 Hash c /ip/69.120.68.54 936 Hash c 10.201.81.157 936 VCL_return c hash 936 HitPass c 357445183 936 VCL_call c pass pass 936 Backend c 103 default default 936 FetchError c http first read error: -1 0 (Success) 936 Backend c 269 default default 936 FetchError c http first read error: -1 0 (Success) 936 VCL_call c error deliver 936 VCL_call c deliver deliver 936 TxProtocol c HTTP/1.1 936 TxStatus c 503 936 TxResponse c Service Unavailable 936 TxHeader c Server: Varnish 936 TxHeader c Content-Type: text/html; charset=utf-8 936 TxHeader c Retry-After: 5 936 TxHeader c Content-Length: 418 936 TxHeader c Accept-Ranges: bytes 936 TxHeader c Date: Thu, 05 Jun 2014 23:05:48 GMT 936 TxHeader c X-Varnish: 357447130 936 TxHeader c Age: 0 936 TxHeader c Via: 1.1 varnish 936 TxHeader c Connection: close 936 Length c 418
希望这可以帮助！
503意味着没有健康的后端可用。 Apache没有响应探测超时或200
varnishadm backend.health
可以给后端健康状态。 这就是为什么你的Apache日志没有logging503