给系统加上眼睛：服务端监控要怎么做？

在一个项目的生命周期里，运行维护占据着很大的比重，在重要性上，它几乎与项目研发并 驾齐驱。而在系统运维过程中，能够及时地发现问题并解决问题，是每一个团队的本职工 作。所以，我们的系统在搭建之初，运维团队肯定完成了对于机器 CPU、内存、磁 盘、网络等基础监控，期望能在出现问题时，及时地发现并且处理。本以为万事大吉，却没想到系统在运行过程中，频频得到用户的投诉，原因是：

• 使用的数据库主从延迟变长，导致业务功能上出现了问题；
• 接口的响应时间变长，用户反馈核心页面出现空白页；
• 系统中出现大量错误，影响了用户的正常使用；

这些问题，本应该及时发现并处理的。但现实是，我们只能被动地在问题被用户反馈后，手忙脚乱地修复。这时，我呢吧才意识到，要想快速地发现和定位业务系统中出现的问题，必须搭建一套完善的服务端监控体系。正所谓“道路千万条，监控第一条，监控不到位，领导两行泪”。不过，在搭建的过程中，团队又陷入了困境：

• 首先，监控的指标要如何选择呢？
• 采集这些指标可以有哪些方法和途径呢？
• 指标采集到之后又要如何处理和展示呢？

这些问题，一环扣一环，关乎着系统的稳定性和可用性，而现在，我们就解决这些问题，搭建一套服务端监控体系。

监控指标如何选择

我们在搭建监控系统时，所面临的第一个问题就是，选择什么样的监控指标，也就是监控什么。有些同学在给一个新的系统，设定监控指标的时候，会比较迷茫，不知道从哪方面入手。其实，有一些成熟的理论和套路，可以直接拿来使用。比如，谷歌针对分布式系统监 控的经验总结，四个黄金信号(Four Golden Signals)。它指的是，在服务层面一般需要监控四个指标，分别是延迟，通信量、错误和饱和度。

• 延迟指的是请求的响应时间。比如，接口的响应时间、访问数据库和缓存的响应时间。
• 通信量可以理解为吞吐量，也就是单位时间内，请求量的大小。比如，访问第三方服务的请求量，访问消息队列的请求量。
• 错误表示当前系统发生的错误数量。这里需要注意的是， 我们需要监控的错误既有显示的，比如在监控 Web 服务时，出现 4 * * 和 5 * * 的响应码;也有隐示的，比如，Web 服务虽然返回的响应码是 200，但是却发生了一些和业务相关的错误(出现了数组越界 的异常或者空指针异常等)，这些都是错误的范畴。
• 饱和度指的是服务或者资源到达上限的程度(也可以说是服务或者资源的利用率)，比 如说 CPU 的使用率，内存使用率，磁盘使用率，缓存数据库的连接数等等。

这四个黄金信号提供了通用的监控指标，除此之外，还可以借鉴 RED 指标体系。这个体系，是四个黄金信号中衍生出来的，其中，R 代表请求量(Request rate)，E 代表错误 (Error)，D 代表响应时间(Duration)，少了饱和度的指标。我们可以把它当作一种简化版的通用监控指标体系。

当然，一些组件或者服务还有独特的指标，这些指标也是需要你特殊关注的。比如，的数据库主从延迟数据、消息队列的堆积情况、缓存的命中率等等。我们高并发系统中常见组件的监控指标，整理成了一张表格，其中没有包含诸如 CPU、内存、网络、磁盘等基础监控指标，只是业务上监控指标，主要方便你在实际工作中参考使用。

选择好了监控指标之后，接下来要考虑的，是如何从组件或者服务中，采集到这些指标，也就是指标数据采集的问题。

如何采集数据指标

说到监控指标的采集，我们一般会依据采集数据源的不同，选用不同的采集方式，总结起来，大概有以下几种类型：

• 首先，Agent 是一种比较常见的，采集数据指标的方式。

  我们通过在数据源的服务器上，部署自研或者开源的 Agent，来收集收据，发送给监控系统，实现数据的采集。在采集数据源上的信息时，Agent 会依据数据源上，提供的一些接口获取数据。

• 另一种很重要的数据获取方式，是在代码中埋点

  这个方式与 Agent 的不同之处在于，Agent 主要收集的是组件服务端的信息，而埋点则是 从客户端的角度，来描述所使用的组件，和服务的性能和可用性。

• 最后，日志也是你监控数据的重要来源之一

  你所熟知的 Nginx 的访问日志和应用程序的log，都是重要的监控日志。可以通过开源的日志采集工具，将这些日志中的数据发送给监控服务器。目前，常用的日志采集工具有很多，比 如，Apache Flume、Fluentd和Filebeat，可以选择一种熟悉的使用。比如在我的项目中，我会倾向于使用 Filebeat 来收集监控日志数据。

监控数据的处理和存储

在采集到监控数据之后，就可以对它们进行处理和存储了，在此之前，我们一般会先用消息队列来承接数据，主要的作用是削峰填谷，防止写入过多的监控数据，让监控服务产生影响。

与此同时，我们一般会部署两个队列处理程序，来消费消息队列中的数据。

一个处理程序接收到数据后，把数据写入到 Elasticsearch，然后通过 Kibana 展示数据， 这份数据主要是用来做原始数据的查询；

• 另一个处理程序是一些流式处理的中间件，比如，Spark、Storm。它们从消息队列里，接 收数据后会做一些处理，这些处理包括；
• • 解析数据格式，尤其是日志格式。从里面提取诸如请求量、响应时间、请求 URL 等数据；
• • 对数据做一些聚合运算。 比如，针对 Nginx 访问日志，可以计算同一个 URL 一段时间之内的请求量、响应时间分位值、非 200 请求量的大小等等。
• • 将数据存储在时间序列数据库中。这类数据库的特点是，可以对带有时间标签的数据，做 更有效的存储，而我们的监控数据恰恰带有时间标签，并且按照时间递增，非常适合存储在 时间序列数据库中。目前业界比较常用的时序数据库有 InfluxDB、OpenTSDB、Graphite，选择的方式有多种，可以选择一种熟悉的来使用。
• • 最后， 就可以通过 Grafana 来连接时序数据库，将监控数据绘制成报表，呈现给开发和运维的同学了。

至此，我们也完成了我们系统的服务端监控系统搭建的全过程。这里再多说一点，我们从不同的数据源中采集了很多的指标，最终在监控系统中一般会形成以下几个报表，我们实际的工作中可以参考借鉴：

1. 访问趋势报表。这类报表接入的是 Web 服务器，和应用服务器的访问日志，展示了服务整体的访问量、响应时间情况、错误数量、带宽等信息。它主要反映的是，服务的整体运行情况，帮助我们来发现问题。
2. . 性能报表。 这类报表对接的是资源和依赖服务的埋点数据，展示了被埋点资源的访问量和响应时间情况。它反映了资源的整体运行情况，当我们从访问趋势报表发现问题后，可以先从性能报表中，找到究竟是哪一个资源或者服务出现了问题。
3. . 资源报表。 这类报表主要对接的是，使用 Agent 采集的，资源的运行情况数据。当我们从性能报表中，发现某一个资源出现了问题，那么就可以进一步从这个报表中，发现资源究竟出现了什么问题，是连接数异常增高，还是缓存命中率下降。这样可以进一步帮助我们分析问题 的根源，找到解决问题的方案。

总结

我们了解了，服务端监控搭建的过程，在这里，我们需要了解以下几个重点：

1. 耗时、请求量和错误数是三种最通用的监控指标，不同的组件还有一些特殊的监控指 标，在搭建自己的监控系统的时候可以直接使用；
2. Agent、埋点和日志是三种最常见的数据采集方式；
3. 访问趋势报表用来展示服务的整体运行情况，性能报表用来分析资源或者依赖的服务是 否出现问题，资源报表用来追查资源问题的根本原因。这三个报表共同构成了我们的服务端监控体系。

总之，监控系统是你发现问题，排查问题的重要工具，我们应该重视它，并且投入足够的精力来不断地完善它。只有这样，才能不断地提高对系统运维的掌控力，降低故障发生的风险。