当咱们在聊监控，咱们在聊什么？

最近在团队中给你们作了一个分享，泛泛地聊了一些有关「监控」的话题。
其实作分享对分享者的做用每每大于参与者。
这是一次将本身知识的梳理的过程，因而我将此次分享整理成这篇文章。

201706/stock-exchange.png

目的 🎯

咱们先来聊聊，什么是「监控」，以及咱们指望经过「监控」完成哪些目的？

传统意义上的监控，是指：

经过一些手段和工具，关注运行中的硬件、软件、用户体验的关键数据，将其暴露出来。
当关键数据出现异常时候发出警告，进行人工或者自动的响应。

咱们平时看到的最多见的监控系统，好比 Zabbix，提供了丰富的模板，
能够监控服务器的 Load / CPU Usage / Alive 这些常规指标。
并在出现问题时候，对其进行报警通知。
随后运维工程师们会上线进行应急操做，case by case 的处理故障。

我将上面的使用目的概括为：

• 故障发生时提供数据报警
• 提供历史数据以供分析

故事到这里彷佛能够结束了，可监控真的是这么简单的么？
固然没，随着时代的进步，用户对服务提出了更为严苛的要求，
同时咱们也有能力进一步控制平均故障修复时间
（MTBF），
上述描述的作法已经不能知足咱们了。

如今让咱们切换一下视角，从传统的 OPS 的视角切换到 SRE
（Site Reliability Engineering）的视角。
当咱们在关注网站总体的可用性时，咱们会发现：
故障警报处理固然很重要，可是咱们根本上想减小甚至避免 MTBF。
咱们有两种手段：
一种是去除单点故障，让问题天然发生，可是不对线上形成影响；
另外一种是在问题出现的早期就发现并进行及时修复。
前者是高可用范畴，后者就是咱们今天关注的「监控」了。

监控的目的是要将灾难消灭在襁褓里；在灾难即将出现或者发生问题时，
给你们展现直接的缘由。

那为了达成这两个目标，咱们须要回到问题的本质，从新思考两个问题：

1. 监控哪些对象？
2. 如何识别故障？

对象 🐘🐘

咱们说的监控对象，通常指的都是某个资源，
资源即持有某种其余方须要的某些属性的载体，包括硬件、软件。
除了资源这种类型，还有一种常见的监控对象是「体验」，即终端用户的访问感觉，
这块内容咱们暂时略去。

让咱们来先看一下常见的资源：

• 硬件
  • 服务器
  • 网络设备
• 软件
  • Application
  • Infrastructure

这个分类是粗粒度的描述，为了落地地描述监控对象对象的健康情况，
咱们还要进一步细化。以「服务器」为例，咱们能够将其监控的内容细化为如下监控项：

• CPU
• Memory
• Network interface
• Storage devices
• Controllers

如何评估这些监控项的健康情况？咱们使用
SLI（Service Level Indicator）。
好比可用性就是一个最容易理解的 SLI。
这里我将资源归为两类，面向用户提供服务的资源和面向存储的资源，
如下是针对这两类资源的常见 SLI：

• User-facing Service
  • Availability
  • Latency
  • Throughput
• Storage System
  • Latency
  • Throughput
  • durability

基于 SLI 创建的数字关键指标，称之为
Service Level Objective。
SLO 每每是一组数字范围，好比 CPU 负载的 SLO 能够设置为 0.0-6.0（针对 8 核 CPU）。
不一样的资源、不一样的业务场景，会有不同的 SLO 设计。

看到这里，咱们已经聊了要监控哪些指标，那么接下来咱们聊聊如何用量化的思想，
帮助指标更易于识别、分析和决策。

量化的思想 🔬

刚开始担任线上救火队成员时候，当有个系统出现问题时候，我常常听到这样的描述：
网站挂了、页面打不开了，CPU 出问题了，内存爆了，线程池炸了等等。
这样的表述虽然没错，但带来的可用价值太少，信息熵过低。
这样的说辞多了，就给人产生一种不靠谱，不科学的感受。

那怎样才能成为科学的描述？
古希腊哲学家在思考宇宙的时候，提出了一种心智能力，
从而打开了科学的窗子，这就是 Reasonable，中文名叫理智，这成为了天然科学的基石。
使用 Reasonable 探讨意味着探讨要深刻问题的本质，不停留在表象，挖掘出真正有价值的内容。

可是光有 Reasonable 还不够，B站粉丝建了一个微博，天天会检查
今天B站炸了吗，
他只能告诉咱们炸没炸，不能给工程师带来实际的用处。
在科学的发展历史上，咱们能够发如今亚里士多德的著做里没有任何数据公式。
他对现象只有描述，只是定性分析，经过描述性状来阐述定理。
这个定性的研究方式到了伽利略那里才出现了突破。
这里咱们能够引入第二个关键词是 Quantifier，量化。
伽利略率先使用定量分析的方法，并将其运用到动力学和天文学，从而开创了近代科学。

若是咱们以定量的方式来描述网站挂没挂，就会变成：网站的响应耗时在 30s，基本没法使用。
描述线程池出问题，就会变成：active 线程数量是 200，已经到达 maxCount 数量，没法进行分配。
你看，经过这样的描述，咱们一会儿就能发现问题出在哪里。

USE 💡

如今咱们已经了解了「监控哪些对象？」，以及尝试用「量化」这个法宝来「识别故障」。
那有没有一些最佳实践帮助你们高效的识别故障呢？这里我推荐 Brend Gregg 大神的 USE 方法。
Brend Gregg 是 Netflix 的首席 SRE，著有 Systems Performance Book，
目前已经出版中文版 性能之巅:洞悉系统、企业与云计算。

USE 分别是三个单词的首字母缩写：

• Utilization：使用率，CPU running percent，硬盘的 IO
• Saturation：饱和度，通常偏存储型资源，内存使用，硬盘使用
• Error：错误数

咱们能够为每一个资源找到各自的 USE 度量指标，具体的 Check List 清单能够参考
USE Method: Rosetta Stone of Performance Checklists。

这里举个例子，前段时间在设计 MySQL HA 方案时候，同时关注了 MySQL 的监控方案，
那么针对 MySQL，咱们要作哪些监控呢？下面是使用 USE 方法设计出来的 SLI：

• Business
  • Questions：语句计总，Throughput
  • Slow_queries：慢查询计总，Error
  • Com_select：查询语句计总，Throughput
  • Com_insert：插入语句计总，Throughput
  • Com_update：更新语句计总，Throughput
• Threads & Connections
  • Threads_connected：当前链接数，Utilization
  • Threads_running：当前使用中链接数，Utilization
  • Aborted_connects：尝试链接失败数，Error
  • Connection_errors_max_connections：因为链接数超标从而失败的链接数，Error
• Buffer
  • Innodb_buffer_pool_pages_total：内存使用页数，Utilization
  • Innodb_buffer_pool_read_requests：读请求数计总，Utilization

完 🏁

若是你对我上面描述的还意犹未尽，建议你能够看 Effective Monitoring and Alerting。
虽然本书没有中文版，可是关于监控、报警的原理解析很到位，值得一看。
另外还有一本 SRE: Google运维解密，
里面有很多篇幅在讲「SLA」，也是和监控、报警息息相关的。

此次讲了一些概念性的内容，指望对你们有帮助，下一次我再分享一篇文章，聊聊 Metrics。

---

原文连接: blog.alswl.com/2017/06/mon…
欢迎关注个人微信公众号：窥豹

3a1ff193cee606bd1e2ea554a16353ee