前言 | 什么是 SRE 黄金指标？

2018-04-17 Steve Mushero
作者简介Steve Mushero：云络科技创始人，上海云敞网络科技有限公司全球技术顾问。Steve Mushero 具有 25 年以上的 IT 运维经验，曾任职土豆网第一任 CTO，OaaS 开创者以及多项专利持有人。
前言站点可靠性工程 （Site Reliability Engineering，简称 SRE）及其相关概念最近可谓炙手可热，部分原因在于极具知名度的谷歌 SRE 书及其它文章开始积极讨论“黄金指标”因素，通过监控这些，你将能够确保系统在扩展时保持快速且可靠的运作效果。
每个人似乎都对这些指标的重要意义表示认同，但我们该如何对其加以实际监控？业界关于这方面的讨论目前还非常少。
这些指标在监控方面要比传统的 CPU 或内存占用量等指标困难得多，这主要是因为每种服务及资源都拥有不同的指标、定义以及特定的所需工具。
微服务、容器以及无服务器模式的出现则令上述指标的监控变得更具挑战 ; 而需要强调的是，对其加以监控确实物有所值——特别是考虑到传统监控机制中存在的大量噪声以及对日益复杂的分布式系统进行有效排查的实际需求。
本系列文章将探讨多种常见服务当中的黄金指标与实践方法。本系列文章将探讨多种常见服务当中的与实践方法。首先，我们将简要聊聊指标本身，而后介绍如何在监控系统中对其进行追踪。
最后，我们还整理出一份对各类指标加以监控的针对性指南，具体涵盖负载均衡器、Web 与应用服务器、数据库与缓存服务器以及通用 Linux 等等。这份清单及其具体信息可能随时间推移而有所改变，我们将不断关注反馈意见并使用更好的分析数据，力求给出更为合理的细节指导。
什么是黄金指标?在这方面，你可以参考以下三种常见的清单或方法：
来自谷歌 SRE 书: 延迟、流量、错误以及饱和度；
USE 方法(来自 Brendan Gregg): 利用率、饱和度与错误；
RED 方法(来自 Tom Wilkie): 速率、错误与持续时间。
可以看到，三者之间存在一定交集。正如 Baron Schwartz 在其《利用 USE 与 RED 方法实现监控与观察》一文中所提到，每种方法都拥有不同的关注重点。他认为，USE 方法主要着眼于资源内部，RED 方法则关注请求、实际工作以及外部视角（即来自服务消费方的视角）。各种方法既彼此相关，亦相辅相成，共同面向每一项服务实现自身效果所消耗的具体资源。
在本文当中，我们将关注重点放在由五种指标组成的简单超集身上：
速率：请求速率，请每秒请求数量。
错误： — 错误率，即每秒错误数量。
延迟：— 响应时间，包括队列 / 等待时间，以毫秒为单位。
饱和度：—即过载程度，这项指标与资源利用率相关，但也可通过队列深度（或者并发水平）等方式进行直接衡量。从队列深度的角度来理解，当系统逐渐趋于饱和时，队列深度将由零变为非零。饱和度指标通常体现为计数器形式。
利用率： — 资源或系统的繁忙程度。通常表示为 0% 至 100%，这项指标对预测而言非常重要（同样重要的还有饱和度指标）。请注意，这里我们并没有使用“利用率法则”的定义，即速率 x 服务时间 / 工作程序，而是选择了大家更为熟悉的直接衡量指标。
在上述指标当中，饱和度与利用率往往最难以衡量，且充满假设、提示与计算复杂性——因此最好将其视为近似值。然而，二者往往又在解决当前及未来的问题当中最具坐，因此我们必须学会接受它们。
上述全部指标皆可通过多种方式进行拆分及 / 或合并。举例来说，HTTP 可被拆分为 4xx 及 5xx 错误，正如我们可以按 URL 对延迟或速率进行拆分一样。
除此之外，还有其它更为复杂的计算方法。举例来说，错误的延迟一般要比成功请求更低，因此如果可以，大家不妨将错误情况从延迟指标当中排除出去（但通常来计不太可行）。
虽然以上拆分或合并工作非常重要但其超出了本文的讨论范畴。在本文中，我们将着重于更基础的数据本身，而不会探讨更多与指标标准、事件乃至高基数分析相关的复杂议题。
现在我们已经掌握了指标，接下来要如何加以处理？事实上，如果大家对以下内容已经比较熟悉，可以直接跳到后文中的实际数据收集指南部分。不过这部分讨论仍然合乎逻辑，即一旦掌握了这些指标，接下来该如何加以处理？
之所以将其称为“黄金”指标，最重要的原因之一在于其直接衡量的事物会对系统的最终用户及工作生产环节产生影响——换言之，其是在直接衡量最关键的对象。
这意味着从理论上讲，这些指标要比其它直接衡量结果（例如 CPU、内存、网络以及复制延迟等等）更重要也更实用。需要强调的是，很多朋友像我们一样需要随时在每台服务器上监测超过 200 个项目，因此指标筛选就成了重中之重。
我们的黄金指标判断标准遵循以下几项考量：
警报：当问题出现时，及时向我们上报。
故障排查：帮助我们发现并解决问题。
调整与容量规划：帮助我们让运行状态更加顺畅。
我们的关注重点在于警报，如何针对上述黄金指标发布警报，以及如何将其与我们的指标联系起来。
从传统角度讲，警报机制利用静态阈值对我们的 Nagios、Zabbix 以及 DataDog 等系统进行监控。虽然其确有成效，但在设定方面难度较大，且往往会产生大量噪声——相信大家已经在实际工作当中对此有所体会。
不过为了遵循经验与最佳实践指导，我们仍有使用静态阈值的必要。毕竟这些标准能够帮助我们快速了解问题所在，或者至少是与正常状况不符的迹象（例如 CPU 占用率达到 95%，等待时间超过 10 秒，队列增大，或者每秒错误率提升等等）。
如果大家使用静态警报，请不要忘记设置下限警报，例如每秒近零请求或延迟等，这些通常都意味着问题的存在（包括凌晨 3 点这类低流量时段）。
使用平均值还是百分位？这些警报通常使用平均值，但大家也可以使用中位值来计算，因为中位值通常不会受到过大 / 过小偏离值的影响。
此外，平均值也存在其它一些问题——正如 Optimizely 在其博文中所提到。再有，只要你的衡量窗口较短（例如 1 到 5 分钟），那么平均值与中位值都易于理解、易于获取且具备理想的实用性水平。
但作为一种更好的解决办法，大家不妨试试百分位数。举例来说，大家可以对位于第 95 百分位上的延迟值进行追踪，这将更好地衡量用户的实际体验。如果第 95 百分位延迟较为理想，则可认定绝大多数用户都具备良好的使用体验。
然而，百分位计算也更为复杂。正如 Vivid Cortex 曾在一篇博文中指出：百分位的起效方式可能与我们的想法有所不同。比如说，我们的系统在衡量时段内（例如 1 或 5 分钟）会对平均值进行百分位求取。尽管如此，百分位取值对警报机制而言仍然非常重要，因此只要可以请尽量加以追踪（大家可能会震惊于自己的百分位衡量结果是那么糟糕）。
属于异常状况，抑或仅为正常波动？在理想情况下，大家也可以在新的黄金指标之上使用现代异常检测机制。
异常检测非常适用于捕捉非峰值期间或引发低指标值的问题。此外，异常检测还能够提供更为密集的警报提醒，从而降低问题发现难度（但不要介入太早，否则大家可能遭遇误报困境）。
不过异常检测的实际使用也颇具挑战，这是因为鲜有内部监控解决方案能够实现异常检测（ Zabbix 就不行）。另外，这种方法还很年轻，仍在不断演进，且难以调优（特别是对于黄金指标当中的“季节性”与趋势性层面）。关于这类问题，你不妨咨询你的产品供应商。
幸运的是，Datadog 以及 SignalFX 等新一代 SaaS/ 云监控解决方案能够实现上述目标，而 Prometheus 以及 InfluxDB 等内部系统也拥有这样的检测能力。
无论你选择怎样的异常检测工具，Baron Schwartz 编写的《利用异常检测进行监控》一书绝对能够帮助你更好地理解各类选项、算法与挑战。
能否直观查看？除了警报之外，大家还应对这些指标进行可视化处理。Weave Works 就拥有一套包含两个图形列的良好格式，Splunk 则提供出色的视图。界面左侧为请求与错误率堆叠图，右侧则为延迟图。大家亦可向其中额外添加饱和度 / 利用率混合图。
你也可以使用标记 / 事件来进一步充实指标，例如部署、事件自动规模伸缩以及重启等等。在理想情况与，你可以在 Netsil 等系统架构图上显示全部指标。
修复工作作为警报部分的最后一项注意事项，我们发现 SRE 黄金指标警报的响应工作往往更具挑战，因为这类指标体现的是极少能够从警报中直接观察到的底层问题迹象。
这往往意味着工程师必须拥有更多系统专业知识，且更擅长深层解析问题，从而在任意服务或资源当中将其发现。
工程师必须把所有线索连接起来，并对警报信息进行全面挖掘——即使其单纯体现为高 CPU 占用率或低内存余量。然而，黄金指标的抽象程度通常更高，且往往会一次性出现大量此类指标——具体来讲，来自某一低级别服务的单一高延迟问题，亦可能导致系统层面的大范围延迟及错误警报。
黄金指标能够帮助我们解决一大核心问题，即如何利用来自少数服务的有用数据外加一项前端问题，共同判断出造成警报的真正根源。立足各项服务收集指标有助于确定可能性最高的潜在原因（特别是在拥有依赖关系信息的情况下），从而帮助我们确定关注方向。
好了，到这里我们就完成了指标处理方面的说明。相信大家已经感受到，指标的发现、监控与警报是一项既有挑战，又相当有趣的过程。
接下来，我们将进一步了解如何从常用服务当中获取数据。
从各项服务中获取数据以下是各类流行服务的附录部分，我们后续还将进一步充实这部分内容。同样的，也欢迎大家为我们提供相关反馈意见。
请注意，以实用方式获取这些数据同样充满细节与挑战，因此请大家原谅我们在文章中纳入大量注释与注意事项——这是为了更为全面地阐述我们的权衡过程。
还要注意的是，在某些情况下，大家需要自行处理部分额外工作——例如根据计数指标进行增量计算 （大多数系统会自动执行此类操作）。
在接下来的内容中，我们将分章节解析各服务清单：
负载均衡器：AWS ALB/ELB、HAProxy
Web 服务器：Apache 与 Nginx
应用服务器：PHP、FPM、Java、Ruby、Node、Go 以及 Python
数据库服务器：MySQL 与 AWS RDS
Linux 服务器：充当底层资源
这是一篇篇幅可观且内容复杂的文章，因此如果你对此抱有不同看法或实践心得，欢迎提供反馈及其它建议。我们将根据你的观点修改内容，因此请持续关注我们的更新，看看其中是否囊括你希望看到的新资讯。
 写留言
精选留言(1)

怪盗キッド

2018-06-23

我利用ASM开发了一个可以监控Java方法执行时间的工具MyPerf4J：https://github.com/ThinkpadNC5/MyPerf4J，MyPerf4J可以统计出RPS、TP90、TP99、TP999、StdDev、Min、Max等性能指标。



 1