Web 服务器黄金指标

2018-04-17 Steve Mushero
如果没有了 Web 服务器，恐怕整个网络都将不复存在……
目前，底层 Web 服务器拥有两项基本功能：提供 HTML、JS、CSS 以及图像等简单的静态内容，并将动态请求传递给 PHP、Java、PERL、C 以及 COBOL 等应用后端。
因此 Web 服务器前端承载着我们的各项关键性服务，包括动态 Web 内容、API 乃至数据库等专业服务。
所以，从 Web 服务器中提取高质量信号就成为一种必需。
遗憾的是，目前这类数据的测量与报告能力仍然非常有限，且合并能力也存在问题（至少无法免费实现）。因此，我们只剩下以下三种选项：
使用高度受限的内置状态报告 / 页面。
收集并合并 Web 服务器的 HTTP 日志以获取这些重要数据。
尽可能使用上游负载均衡器每服务器指标。
最后一个选项是使用负载均衡器的每后端服务器指标，这通常也是最理想的解决办法。我们已经在前文的负载均衡器部分探讨过这项操作的具体执行方式。
然而，并不是所有系统都具备正确的负载均衡器类型，而且相当一部分监控系统也并不支持获取这类后端数据——举例来说，这项工作在 Zabbix 当中就很难实现，而且其很难从某一主机（负载均衡器）当中获取另一主机（ Web 服务器）的数据。餐卡，AWS ELB/ALB 提供的数据也相当有限。
因此，我们必须必须寄希望于 Web 服务器状态页与 HTTP 日志，下面将介绍一些难以实施但却物有所值的实现方法。
收集 Web 服务器指标的准备工作要获取日志与状态信息，我们首先需要完成以下准备工作：
启用状态监控你需要启用状态监控。对于 Apache 与 Nginx，最佳实践在于为其分配另一端口（例如端口 81）或者将其锁定于你的本地网络以及监控系统等处，从而确保恶意人士无法访问。
Apache: 启用 mod_status，包括 ExtendedStatus。详见 DataDog 的良好 Apache 指南。
Nginx: 启用 stub_status_module。详见 DataDog 的良好 Nginx 指南。
启用日志记录我们需要日志记录，这意味着大家首先需要进行配置，将其存放在理想位置，且最好能够利用 vhost 进行隔离。
我们还需要在日志当中纳入响应时间指标，遗憾的是标准或者默认格式当中并不包括此项指标。因此你需要编辑 Web 配置以实现此项目标：
Apache: 我们需要在日志定义当中添加 “%D” 字段（通常位于末尾），其将以毫秒为单位记录响应时间（在 Apache V1.x 版本中需要使用 %T，但其将以秒为单位）。
具体操作与下面要介绍的 Nginx $request_time 基本相同。需要注意的是，其并不支持使用更接近于 Nginx Supstream_time 的 mod-log-firstbyte 模块，但它测量的才是真正的后端响应时间。具体请参阅 Apache Log 说明文档。
Nginx: 我们需要为后端响应时间添加 "\$upstream_response_time" 字段，通常位于日志行末尾。利用此“后端时间”将可避免系统向低速客户端发送大量响应。
Nginx 同样支持在日志定义当中添加 “\$request_time” 字段。此时间截至面向客户端的最后一个字节发送完成，因此能够捕捉到大量响应与 / 或低速客户端。 这可能会带来更为准确的用户体验反应（并不总能），但如果你的大多数问题出现在系统而非客户端处，这种方法可能引发更多噪声。具体请参阅 Nginx Log 说明文档。
请注意，许多人还会将 X-Forwarded-For 标头添加到日志当中。如果存在这一或者其它字段，你可能需要调整解析工具以获取正确的字段。
处理日志以获取指标如下所示，最重要的各项 Web 服务器信号（特别是延迟）只能通过日志获取，但日志信息往往难于读取、解析以及汇总。不过我们似乎别无选择。
目前市面上存在大量用于读取 HTTP 日志的工具。虽然其中大部分主要关注网站数据、用户流量以及 URL 分析等，但我们也可以借此获取黄金信号——因此，我们首先需要整理出一组理想工具，从而以可靠方式读取、解析并汇总日志信息，且保证相关结果能够在监控系统中加以使用。
在这方面，大家可能已经拥有自己最熟悉的工具选项，例如人气日盛的 ELK 堆栈就能实现一部分功能（包括 Splunk、Sumologic、Logs 等等）。除此之外，大多数 SaaS 监控工具（例如 DataDog）也能够通过其探针或受支持的其它第三方工具提取此类指标。
但 Zabbix 等较为传统的监控系统在这方面往往表现不佳，因为其并不擅长读取日志或充当处理工具。再有，我们所关注的也并不是日志条目本身。相反，我们需要对日志当中的延迟及错误率等指标按时间序列进行汇总，这与多数其它“日志记录”目标完全不同。
因此，如果你的监控系统本身支持 Web 服务器日志指标，且设置工作也已准备就绪，那么请继续阅读。如果不能支持，但你已经为系统配备了第三方或开源工具且完成对应的设置工具，同样请继续阅读。
如果你还没有自己的监控系统，也没有使用任何第三方 / 开源工具，那么很遗憾，我们还找不到任何能够开箱即用 的解决方案——特别是在要求在 1 或 5 分钟周期内获取实用数据的前提之下。
事实上，日志解析与合并的难度远超你的想象，而且目前没有多少工具能够在服务器上执行此类操作以提供基于探针的监控功能。就目前来看，只有 GoAccess 工具能够实现一部分功能，并输出可以直接解析的 CSV 数据格式。虽然也有不少出色的 awk 以及 PERL 脚本可供选择，但它们几乎不支持时间窗口或者日志回滚。
总而言之，你需要寻找一种系统、工具或者服务以从 Web 日志当中提取指标。
将我们的信号映射至 Web 服务器，则得到以下具体指标：
请求率：每秒请求数量，你可以选择比较困难的实现方法，即通过读取访问日志并计算其中行数以获取总体请求数量，并对每秒请求数量进行加和。或者，你也可以使用更简单的服务器状态信息，具体方式如下： 
Apache: 使用 Total Accesses，此计数器用于统计进程生命周期内的总体请求数量。进行增量处理即可得出每秒请求数量。千万不要使用“Requests per Second”，因为其计算的是整个服务器生命周期内的每秒请求数量，因此并无实际意义。 
Nginx: 使用 Requests，此计数器用于统计总体请求数量。进行增量处理即可得出每秒请求数量。
错误率：这一指标必须来自日志，且你的工具应在日志中对每秒 5xx 错误数量进行计数以获取错误率结果。你也可以对 4xx 错误进行计数，但其中可能包含大量噪声，且通常与真正影响到用户的错误无关。大家真正需要关注的只有 5xx 错误，其会直接影响用户且在理论上永远不应出现。
延迟：这项指标应源自日志，你的工具应有能力合并你添加至日志当中的请求或响应时间信息（如上文所述）。一般来讲，我们需要获取整个采样周期（例如 1 或 5 分钟）内的响应时间平均值（中位值更好）。
正如前文所述，你需要配合正确的工具才能实现这些目标，而目前市面上也提供多种实用的脚本或工具选项。你通常需要将日志发送至 ELK 类服务（例如 ELK、Sumo 以及 Logs 等）、监控系统（DataDog 等）或者 New Relic、App Dynamics 或 DynaTrace 等 APM 系统当中。
饱和度：这项指标的获取颇具挑战，具体取决于你的 Web 服务器类型：
Nginx: Nginx 服务器自身几乎不可能出现饱和问题，只要你的工作程序与最大连接数量设置得够高（默认为 1 x 1K，但一般会设置得更高，我们使用的为 4 x 2048K）。
Apache: 大多数用户运行的是预 fork 模式，因此每连接会配备一个 Apache 进程，其实际限制在 500 左右。因此如果后端速度缓慢，Apache 本身很容易出现饱和。所以：
BusyWorkers 对最小配置 MaxRequestWorkers/MaxClients/ServerLimit。当 Busy = Max 时，此服务器即达饱和且无法接受新的连接（新连接将被添加至队列当中）。
你也可以在日志当中对 HTTP 503 错误进行计数，其通常发生在后端应用服务器过载的情况下。不过在理想情况下，你应该可以直接从应用服务器处获取此项指标。
对于大多数 Apache 系统而言，最重要的是对内存资源进行衡量，这是因为其是导致 Apache 系统发生崩溃的常见“元凶”——特别是在运行 modPHP 或者其它基于 mod 的应用服务器时，内存不足往往经常出现。
利用率：对于 Nginx 来说，利用率一般不必关注，但 Apache 的利用率则存在与饱和度一样的问题（BusyWorkers 对最小配置 MaxRequestWorkers/MaxClients/ServerLimit）。
我们期待着有人能够编写一套 Apache 模块或者 Nginx Lua/C 模块，用以通过等同于负载均衡器的方式报告这些信号。这项工作看起来并不困难，而且技术社区一定会对这样的成果交口称赞。
总体来讲，在 Web 服务器上对这些信号进行实际监控绝非易事，但大家应当找到解决的途径，最好是能够通过上游负载远程顺实现，或者使用前文提到过的方法。
作者简介Steve Mushero：云络科技创始人，上海云敞网络科技有限公司全球技术顾问。Steve Mushero 具有 25 年以上的 IT 运维经验，曾任职土豆网第一任 CTO，OaaS 开创者以及多项专利持有人。
 写留言
精选留言

由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
