实时监控系统介绍

在大型系统的维护中，实时监控对于开发人员了解系统情况，排查系统问题至关重要。本文不会介绍这类实时监控的实现原理（有兴趣的可以去找相关开源软件，如OpenTSDB），只是从一个开发人员的角度阐述如何理解并正确使用这类监控系统。注：如果你有过使用这类监控系统的经历，可能会更清楚我要说明的问题。

一、从两个有意思的问题开始

之所以写这篇文章，是因为最近遇到了两个系统问题，都是看监控与实际数据表现不符，觉得还挺有意思，特记录下。

- 系统被限流，但查看监控发现流量根本没有达到限流的阈值。

- 查看监控发现系统流量很高，但实际上却没有这么高的流量。

以上两个问题经查看服务器日志发现，确实都是监控系统曲线有问题。如何配置出正确的监控就是我们要解决的问题。

二、概念解释

为了方便理解，简单介绍下一下本文所说的一些概念，先看下监控系统是如何工作的。如果你没接触过，那么建议你停下来想一下，你自己构建这样的系统会怎么做。

1）提供一个客户端或接口，用户（开发人员）可以put关心的系统实时数据。例如我想监控服务器集群的每秒请求数（QPS），可以在每个请求到来时进行记录，并且定时上报。假设每10s上报一次这10s请求数的和。当然你可以多维度的记录，比如这台服务器的IP，请求来源等等。

2）系统会将你上报的数据全部存储起来，然后需要你通过各种不同的聚合方式去配置面板。

3）面板配置好后，你可以根据不同维度去查看你想要的数据了，比如查看某一个IP的QPS，某个业务方对某一个IP的QPS等，这也就对应了一条曲线。

根据以上的步骤，我们可以对应下系统概念。

- metric：监控项。metric是监控系统的核心，是我们关心的系统指标，比如cpu使用率，服务器QPS（每秒请求数），服务RT（响应时间）等。对应1中的QPS。

- tag：对应不同的维度，每个metric下有多个tag，可以理解成一个map，对应1中 IP:xxx，请求来源:xxx。一条我们观察的曲线就是由一组确定的tag决定的，比如IP: 10.40.22.138，consumer: test，就可以确定test对该IP的请求数曲线。

- timeslice：时间片，对应于1中的10s。是上报数据的时间单元。

- 上报数据聚合类型：对应于1中的求和。可以上报10s的和也可以是平均值，最大值，最小值等等。

- 理解2中的聚合方式，最重要的是理解两个维度的聚合方式：

    - 针对单条曲线：将某时间范围内的数据点按某种方式聚合成一个数据点，比如10s-sum，将10s内收集的所有数据点，加和求一个数据点。

    - 针对多条曲线：一个metric下可能有多条曲线，比如上例中我想看所有IP，所有请求来源的QPS，那就要把所有的曲线以某种方式合并起来。比如将所有单曲线按时间点合并加和。

三、问题原因

理解了以上的概念，大概也就能猜到第一个问题的原因。首先限流的时间粒度是1s，例如QPS大于100会被限流。然后监控面板上对应的曲线，数据的上报时间粒度是10s上报一次求和，最后监控面板配置时又是10s聚合一次求平均值。这样的配置会导致峰值被平滑的削弱，看不出瞬时的峰值。解决方法是缩小上报数据粒度，多曲线聚合采用加和方式计算。

第二个问题其实是因为在针对多条曲线聚合时，由于某些点没有数据，监控系统会认为这是不合理的，并采用某种特别的算法计算一个值插入到该点弥补。这样就导致了曲线的虚高了。我们可以采用不补值的方式聚合，没有就计算为0就解决了。