本文分享微信运维监控系统的具体设计实践。分享之前，我们先看看下图中微信后台系统的现状。面对庞大的呼叫量和复杂的呼叫链路，单靠人力难以维护。只能依靠完善的监控、稳定快速的运维监控系统。我们的运维监控系统主要有三大功能：故障报警故障分析定位自动化策略我们今天的分享话题主要有以下三个部分：监控数据采集轻量级微信数据监控开发流程海量监控分析数据存储设计思路监控数据collection轻量级先看常见的数据采集流程，一般是从日志中采集，然后在本地进行汇总打包，然后发送到全局服务器进行汇总。但对于微信来说，200w/min的调用产生2000亿/min的监控数据上报，这是一个比较保守的估计。早期我们使用自定义文本类型的日志上报，但是由于业务和后台服务较多，日志格式增长非常快，难以持续维护，对CPU的压力很大，网络、存储、统计，难以保证监控系统本身的稳定性。为了实现稳定的分钟级甚至秒级数据监控，我们进行了一系列改造。对于我们内部的监控数据处理分为两步：数据分类定制化处理策略我们对数据进行分类，我们内部有三类数据：实时故障监控分析。非实时数据统计，如业务报表等。单用户异常分析，如用户上报故障时，应单独分析该用户的故障。下面简单介绍一下非实时数据统计和单用户异常分析，然后重点介绍实时监控数据的处理。非实时数据对于非实时数据，我们有一个配置管理页面。用户在上报时，会先申请logid+自定义数据字段。Reporting没有采用写日志文件的方式，而是采用共享内存队列和批量打包的方式来降低磁盘IO和日志服务器调用的压力。现在普遍的做法是使用分布式统计来进行统计。单用户异常分析对于单用户异常分析，我们关注的是异常，所以上报路径和刚才的非实时路径类似。使用固定格式：logid+固定数据字段（服务器IP+返回码等）。上报的数据量远大于刚才的非实时日志，所以我们采用抽样的方式上报。数据除了存储在Tdw的分布式存储中，还会转发到另一个缓存中做查询缓存。实时监控数据实时监控数据是分享的重点部分，这部分数据也是2000亿/分钟日志报表的绝大部分。为了实现多方位的监控，我们的实时监控数据也有多种类型，它们的格式、来源、统计方法都各不相同。为了实现快速稳定的数据监控，我们对数据进行分类，然后有针对性地对各类数据进行简化，统一数据格式，然后对简化后的数据采用最佳的数据处理策略。对于我们的数据，我们认为有以下几种：后台数据监控，用于微信后台服务的监控数据。终端数据监控，除了后台，我们还需要关注终端的具体表现，异常监控和网络异常。对于外部监控服务，我们现在有商家、小程序等外部开发者提供的服务。我们和外部服务开发者都需要知道这个服务和我们微信之间存在什么样的异常，所以我们也提供外部监控服务。后台数据监控对于我们的后台数据监控，我们认为可以按照级别分为四类，每类都有不同的格式和上报方式：硬件级别的监控，比如服务器负载，CPU，内存，IO，网络流量等.进程运行状态，如消耗的内存、CPU、IO等模块之间的调用链，模块与机器之间的调用信息，是故障定位的关键数据之一。业务指标，业务整体层面的数据监控。将不同类型的数据简化为以下格式，以方便数据处理。最下面两层使用IP+Key的格式。后来容器出现后，就使用了ContainerID、IP、Key的格式。模块调用信息提取被调用模块的整体信息，与业务指标共享ID和Key的数据格式。让我们关注IDKey数据。这个IDKey数据是前期的重点监控数据，但是它的上报量却占到数据上报的90%以上。刚才说了，用文本数据很难做到稳定快速的上报。因此，我们定制了一个非常简单快速的汇报方式，可以直接在记忆中快速总结。具体上报方案见下图。每台机器都申请了两块共享内存。之所以有两块是为了方便定期收集数据（每6秒一次）。每块内存的格式为：uint32_t[MAX_ID][MAX_KEY]。我们内部只允许三种上报方式：累加、设置新值、设置***值这三种方式都是在操作一个uint32_t，性能消耗很小，还有一个很大的好处，就是在实时汇总内存，每次从内存中提取的记录数平均只有1000条左右，大大降低了秒级统计的难度。后台数据中另外一个重要的数据就是调用关系数据，它对故障分析定位有非常重要的作用。具体格式如上，可以定位故障点（机器、过程、接口）和受影响面。它的上报量是比IDKey小的第二大数据，而且每次后台调用都会产生一条数据，所以用log的方式处理还是有难度的。我们在服务中使用另一种接近IDKey的共享内存统计方法。比如一个服务有N个worker，每个worker会分配两块小的共享内存用于上报，然后采集线程将数据打包发送给外界。.这个上报是在框架层做的，服务开发者不需要手动添加上报代码（99%的微信都是用自研的服务框架）。介绍完终端数据监控的后台数据，我们再来说说终端监控数据。我们重点关注手机端微信APP的一些具体表现和异常，调用微信后台耗时异常，网络异常。移动端产生的日志数据非常庞大。如果全量上报，对终端和后台的压力会很大，所以我们没有全量上报。我们针对不同的数据和终端版本有不同的采样配置，后台会定时向终端下发采样策略。终端上报数据采样时，不会实时发送。而是记录在暂存器中，过一段时间再打包发送，尽量减少对终端的影响。外部监测服务下面简单介绍一下我们最新的外部监测服务。本方案参考了部分云监控方案。用户可以自行配置维度信息和配置监控规则。现在我们的商户管理界面和小程序开发者工具的页面已经开发了这个功能，但是自定义报表还没有开放，只提供一些后台采集的固定数据项。微信数据监控的开发过程上面已经介绍了数据的上报方式，接下来介绍我们是如何监控数据的。异常检测对于一般的异常检测，可能会用到三种方法：阈值，即使在早上和晚上，也有很大的区别，这个阈值本身是不可分割的，所以这个只适用于我们的小部分场景。同比，问题是我们每天同一时间的数据都不一样。周一到周六会有比较大的差异，只有降低灵敏度才能保证准确性。在环比方面，在我们的数据中，相邻数据的变化并不平滑，尤其是量级较小的时候，只能通过降低灵敏度来保证精度。所以这三种常见的数据处理方式都不是很适合我们的场景，我们之前对算法进行了改进。我们使用的第一个改进算法是均方误差，就是在过去一个月的每一天同时计算数据的平均值和均方误差，使用多天的数据来适应数据的抖动.该算法适用范围广，但对于波动比较大的曲线，灵敏度会比较低，容易遗漏。我们改进的第二个算法是多项式拟合预测，它适用于平滑的曲线，有点像改进的环比。但是，如果出现异常时数据稳定增长或下降，没有突然变化，此时会判断为正常，就会出现漏报。因此，上述两种算法虽然与以往的算法相比有了很大的改进，但也存在一些缺陷。我们目前正在尝试其他算法，或者组合使用多种算法。监控配置除了算法本身，我们在监控项的配置上也有问题，因为我们有很多服务。因此，可能超过30万的监控项需要手动配置。每条配置观察曲线选择不同的算法和不同的灵敏度，经过一段时间后，数据发生变化，需要重新调整。所以这个操作是不可持续的。目前我们正在尝试自动配置监控项，比如使用历史数据、历史异常样本、提取特征、分类数据，然后自动套用最新的监控参数。我们正在努力取得一些成果，但还不完美，仍在改进中。海量监控分析下的数据存储设计思路分享了上面如何采集和监控数据，最后介绍了数据是如何存储的。对我们来说，数据存储同样重要。前面说了，我们每一分钟都需要获取一个月的数据进行监控。比如我们的故障分析，如果某个模块出现异常，需要读取所有的机器调用信息，CPU，内存，网络，各种进程信息等等，如果机器数量特别多，读取的数据量一次会超过50w*2天。因此，我们对监控数据存储的读写性能要求非常高。首先，对写入性能的基本要求是总存储量可能每分钟2亿以上，单机至少需要500w/min才能存储这个数据量。数据读取性能需要能够支持每分钟50w×22天的监控读取。从数据结构上来说，我们的各种数据是多维度的。比如调用关系有很多维度，我们也要支持基于client、svr、module、host等不同维度的部分匹配查询。我们不能只支持简单的A键值查询。注意，我们的多维密钥分为两部分：主密钥和子密钥。我们稍后会介绍为什么要这样做。以前我们监控数据存储改造的时候参考了一些其他的开源方案，但是当时没有找到完全满足性能和数据结构需求的现成方案，所以我们自己开发了时序服务器.首先，对于数据的写入，如果每分钟一条记录，那么数据量就太大了，所以我们会先把数据缓存一段时间，一段时间后批量合并成每天一条记录的时间。这也是一种常用的提高写入性能的方法。我们的数据缓存时间是一小时。我们自研的key-value存储的关键点就是key的实现。首先，密钥会常驻内存。另外，由于数据量大，不可能单机支持，所以我们采用多机集群，使用hash(main_key)写入和查询数据。部分匹配查询采用改进的二分查找法实现预匹配查询。这样实现的查询性能非常高，可以超过100w/s，加上查询结果缓存性能更高。但是它也存在一些问题，比如hash(main_key)数据不平衡，每天一条记录，key占用内存太大。针对以上问题，我们进行了第二次改进。第二种改进方法是将Key-Value拆分为key-id-value，通过id分发服务控制value数据的均衡。key-id每7天重新分配一次以减少内存使用。存储的另一个主要问题是灾难恢复。服务器由于被监控，对自身的容灾能力要求也很高。一般来说，实现高容灾和数据强一致性比较难，但是微信后台开源了自研的phxpaxos协议框架，使用该框架可以轻松实现数据容灾。另外phxpaxos框架的multi-master特性可以提升并发读性能。2008年加入腾讯的陈小鹏，2012年调入微信运维开发团队，负责运维监控系统改造。目前微信运维监控系统的主要设计者和开发者。
