上周末出去骑车，狂奔 140km+，回来没看 小美搬家 的访问统计就直接睡了，第二天醒来发现网站宕机了几乎一整天，周末一天只有一个 ip ，Run-Cry （ ＴДＴ）

由于网站换成 rails 后，类似的宕机这已经是第二次了，加上本来就是一台只有 512M 内存的 ECS，一直都有内存不够的疑虑。今天有空，于是把最近的日志 down 下来试着分析了一下。

Problem 1. 日志没有设置截断

所有的日志都记录在一个文件中，从29号清空日志到现在竟然已经有 60M 了，无论是查看还是查找都极为不方便。这个问题是由于 Rails 原生的日志组件比较薄弱，之前自己也没意识到这个问题，解决方法通常有两种：一种是使用 Gem，另一种是在系统中安装其他的日志组件并使用，比如：logrotate。从 ruby-china 的讨论中来看，如果直接使用 Rails 来处理日志，多线程处理会成为比较头大的问题，所以选择 logrotate 的成本相对低很多。

Problem 2. 搜狗图片蜘蛛抓取导致大量 500 错误

打开日志发现最多的错误就是一个来自 218.30.103.38 的请求导致的 500，这个 IP 是搜狗负责抓取图片的蜘蛛，每次和另外两个蜘蛛一起访问。

搜狗的蜘蛛感觉有点小神经，可以看到其中两个都指定了请求文件的类型，一个 html，一个 jepg。html 倒没什么问题，但是对着一个网站的主页抓取却期望得到一个 jpg 的返回，这个设定真的好么？如果做了适当的处理还好，像这个网站这样的必然只能导致 500.对于这一点我真有点摸不着头脑了，先 Mark 一下，回头了解一下搜狗这么做的原因再作应对。

另外，我还发现搜狗蜘蛛的访问频率颇高，稳定的一个小时来一波，只逛首页，每一波持续的时间不定，通常会有5-15组请求，每组就是上图的三个请求，两组间间隔是两分钟。不确定这个频率是否偏高，于是我将频率和图片蜘蛛的问题一起反馈给了搜狗，希望能收到回复。

Problem 3. 请求被带上了奇怪的尾巴

本来小美的首页地址是没有带任何 Url 参数的（带了也没用~），也没有生成什么带参数的首页链接，但是有些来访的访客（应该都是蜘蛛）却带上了奇怪的尾巴。这些尾巴有：

/?fid=40 有来自百度蜘蛛和海外的请求
/?auth=7df1ovPb1BZBVZ8M7b01PbwdvyREvZuy2W3iq54tnSTVLiHiQXdma0R9BPMnAs8&fid=50 大多来自江苏或阿里
/?v1_v2=fAJi5 主要来自 google 蜘蛛

这些 URL 的来源也让人费解，不过它们也没有什么实质性的影响，暂时观望

Problem 4. 宕机触发时的记录

从这次请求之后，网站就宕掉了，并且直接导致了进程中止（因为宕机后并没有发现假死中的网站进程，进程被退出了）。但是这次请求除了带上了一个尾巴，并没有任何异样，宕机前的访问压力也是跟平时持平，并没有出现并发问题。而唯一能体现不正常的地方就是这个请求执行了 1.6s，有什么东西可以把一个 4ms 的处理过程拉长到 1.6s 并成功返回？我对此只能大胆的猜测：会不会是由于服务器性能在这个时间点突然受到很大的压力，导致短暂抽风，比如受到攻击或者机房瞬间负载过高之类的。因为根据目前的情况来分析，我觉得内存不足和网络阻塞这两个原因基本来说是可以排除的，而 小美搬家 的这个网站部署脚本是我自己写的，偷懒没有写守护进程，所以瞬间崩溃导致的进程中止就足以导致网站持续宕机了。

解决方案当然是在部署脚本里加入一个守护进程，检测到 Web 的进程不存在时就重启 Web。如果是内存不足导致的宕机，那么即使重启作用也不大，但如果是由于 ECS 不稳定导致的，那么以后就应该不用担心了。

以上，便是本次追溯的全部，日志真的是个好东西。