最近在团队中给大家做了一个分享,泛泛地聊了一些有关「监控」的话题。 其实做分享对分享者的作用往往大于参与者。 这是一次将自己知识的梳理的过程,于是我将这次分享整理成这篇文章。

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。


原文链接: https://blog.alswl.com/2017/06/monitoring-introducing/
欢迎关注我的微信公众号:窥豹

3a1ff193cee606bd1e2ea554a16353ee

Comments

comments powered by Disqus