不知道平常值，就看不出激增

从日志中抽取一个数字时，要判断它是否是坏值，只有知道平时值才能判断。

概念图: 制定基准线 · 1. 测量整个规模。 · 2. 看状态代码分布。 · 4xx是客户端发送错误的，5xx是服务器坏了

“有103个错误”不是信息。如果平时是5个，那就很严重，如果平时是120个，反而是好事。光是现在响应时间是200毫秒，就不能知道是否好不好。如果平时是40毫秒，那就很严重，如果是220毫秒，那就没什么大不了的。

所以日志分析的第一步不是找原因，而是制定基准线。而且在陌生的客户公司中，基准线不存在于文档中，所以必须在同一日志中制定。除了事故视图以外的其余部分就是平时值。

第一次打开访问日志时的顺序是这样的。

**1. 测量整个规模。**有多少行，涵盖哪些区域。如果在6小时的日志中寻找昨天下午的事件，那么该日志一开始就没有答案。

2. 看状态代码分布。 200有几个，4xx有几个，5xx有几个。在这里一定要区分4xx和5xx。4xx是客户端发送错误的，5xx是服务器坏了，所以两个数字一起移动还是单独移动，就是原因的方向。如果部署后只有4xx增加，说明API合同变更了，如果只有5xx增加，说明内部坏了。

3. 以时间轴切割。 5xx 按分钟数来计算。如果均匀分布的话是慢性问题，如果集中在一个点的话是事件。这种区分会完全改变对策。如果集中的话，可以问问那个时间点发生了什么，调查就可以结束了。

**4.按路径切割。**错误是否集中在特定端点，是否扩散到整个系统。集中的话是该功能的问题，扩散的话是共同依赖性（数据库、认证、网络）的问题。

5. 减去基准线。 除事故区间以外的其余错误数。只有这个数字才能写出“平时33起事故，1分钟内就发生了70起”这样的句子，而这个句子将成为报告的第一行。

在这里补充一个实务感。不要被平均值所迷惑。

虽然响应时间平均为1380毫秒，但这并不意味着用户平均等待了1.4秒。在340个案例中，240个案例为260毫秒以下，70个案例超过3秒，但平均值仍然是那个值。平均值描述了不存在的用户。

而且这种失真只在单一方向上工作。平均值几乎无法检测到尾巴变差的情况。即使100个慢请求从3秒提高到6秒，整个平均值也只上升了30毫秒左右，即使如此，也不会超过任何通知阈值。

因此，当客户说“有时会停顿几秒钟”时，仪表板的平均值正常的情况并不矛盾。两者都是忍耐，只是在看不同的东西。

调查过程中，可能会遇到日志本身不可信的情况。如果不了解这一点，继续调查的话，会花几个小时寻找没有答案的答案，所以有必要先确认一些事情。

丢失。如果日志聚集在缓冲区后发送的结构，程序强制终止时最后几秒钟就会全部消失。但是故障的决定性时刻正是那些几秒钟。“临死前没有日志”并不意味着没有线索，而是强有力的异常终止线索。因为如果是正常终止的话，就会留下结束日志。

**截断。**收集器限制一行长度的情况很常见。长堆栈轨迹或JSON正文在中间断开，后面连着的行被视为单独的项目。解析方面会显示为格式错误的行，然后安静地被丢弃。增加错误数量但实际出现数量较少的原因之一就是这个。

**视觉。**当合并多个设备的日志时，如果时钟不一致，因果关系就会被颠倒。如果结果看起来比原因先记录，就应该怀疑时钟，不能提出奇怪的假设。而且如果时区混在一起，就会产生九小时的错觉。将日志的视觉保持为UTC，只有在显示时才进行转换是消除这个问题的唯一方法。

**样本。**流量大的服务有时会不留下全部日志，只记录一部分。这时“该用户的请求不在日志中”并不意味着没有请求。如果在不知道样本比例的情况下统计数量，那么这个数字毫无意义。

整理的话，在打开日志之前先确认四个方面。**覆盖哪个部分，到哪里完整，时钟是否正确，全部还是部分。**这些确认所需的几分钟，可以避免寻找没有答案的几小时。而且，如果确认结果日志没有答案，那么将它直接写在报告上比写下猜测更有价值。因为下次应该留下什么更多，就在那个句子中。

在1269行的网络访问日志中，找出错误总量和事故时间和原因路径，最后单独计算平时值，将飙升幅度转换为数字。