海量存储第二弹 - 立体化监控

作者介绍：裴泽良，2010年加入架构平台部，一直从事运营系统相关的建设工作，历经了腾讯海量存储及CDN服务的运营体系从入门到初级再到较为完善的各个阶段，目前专注于提升腾讯云上业务的运营质量，以及建设新一代高效与安全的自动化运维体系。

关于EP级存储运营体系相关的核心内容，已在《海量存储第一弹 - 自动化运维》中做了详尽的介绍，本文主要讲海量设备、海量业务服务场景下的质量监控。

深入海量业务特性的监控

一、我们业务对监控的诉求

图1存储系统层级结构

架平主要服务了公司内部的胖子业务，主要提供了其中的海量存储、海量CDN相关的服务，这些服务最终都体现在业务多、机器数量多、区域及运营商分布广泛（国内海外都有）、使用了多家外部CDN厂商等这些特点上面。

各种类型的海量存储服务（key-value、文件型、热数据、冷数据等应用场景）后面都对应了复杂的软件架构，最终都体现在软件模块多、调用层级深、且大多以后台模块的形式运行等特点上面。

我们对业务监控的需求，从业务视角来看，表现为能够实时掌握到每个业务在各个区域、运营商、各个软件模块等的运行状态数据，且当有任何一个点出现异常时，都能够及时有效的告警出来，从系统设计视角来说，表现为要能够把复杂的业务调用场景进行抽象化，要有足够的性能以便能够实时处理海量的监控数据，且要让人工在这整个过程中并不需要做太多参与，提升系统可持续运行能力。

二、开源监控产品能否应对

图2形形色色的开源监控产品

目前市面上已有不少开源的监控产品，譬如Nagios、Zabbix、Open-Falcon等，这些开源的监控系统功能不少，能否满足我们的需求呢？

开源的监控产品本身提供的功能更聚焦于系统自身的特性监控，譬如主机是否存活、网卡流量等，而像业务特性，譬如业务请求失败数、延时等特性数据就需要单独开发插件，且当生产机位于全球各地、跨越不同运营商的时候，开源的监控在代理、上报接入点自动选优等功能上也不足以应对需求。这些还只是功能需求性的短板，当系统每分钟需要处理上十亿级别的数据量时，这些开源监控产品的性能、可扩展性等不满足的话会对业务的运营质量带来严重的影响。

三、我们业务监控的体系建设

图3监控需解决问题的形象描述

关于单台机器自身相关的各种特性的监控，譬如CPU、网卡、硬盘故障、单机不可用等，这部分与业务监控相关性不大，统一采用公司的TMP系统做监控，这里面就不再描述。

如上图，可以把我们的监控系统描述为对大量原始数据的实时处理，把数据从单台机器的低层次维度实时合并汇聚为符合业务、用户需要的高层次维度的数据，并在此数据基础上做展示、告警、业务质量分析、实时故障分析等。

譬如微信朋友圈图片上传与下载业务，假设总共有1000个节点组成，按用户访问量分布在电信、联通、移动、CAP机房，以及分布在上海、深圳、天津、中国香港等地，则每台机器单独上报各自的上传、下载的请求数、失败数、延时等多个指标的数据，人需要查看的常常是朋友圈图片上传总请求数是多少、失败率是多少，监控系统要做的就是实时对这些原始数据做汇聚合并成用户需要的样式。

图4业务监控模型的建立

如何建立业务的监控模型呢？这里的业务指的是一个业务的某方面功能，譬如微信朋友圈图片上传下载、微信C2C聊天图片上传下载、微信双人语音通话等。

如上图，我们可以先把业务分解为由多个不同的软件组成，每个软件需监控的内容分解为“多维度+多指标”，指标是指延时、请求数、失败数等这类，也即一个业务需监控的内容就可以由“多软件+多维度+多指标”来描述，譬如微信朋友圈图片上传下载这个业务，要监控的内容为“下载模块，图片类型为webp的下载每分钟请求数是多少，失败数是多少，总延时是多少”等，业务上报数据的格式也就是这种结构化的描述方式，也即“soft_id=xx|维度1=xx|维度2=xx|维度3=xx|指标1=value1”。

采用了上述模型之后，后续业务模块增加新的功能，可以直接上报新的维度、指标，不需要人工重新配置监控系统，监控系统会自动识别上报的内容并应用到系统上面，大大降低人工的参与度。当然如果系统监测到业务模块同一时间上报了过多的维度、指标，则会自动禁用新的上报，并通知人工处理，以免业务模块有BUG导致误上报。

采用了上述模型之后，告警配置就可以采用更加人性化的规则化来描述，譬如用户可以配置“微信朋友圈图片上传+所有运营商+所有地区+失败率持续达到xx就电话通知到负责人”，这样随着业务的发展以后再增加新的运营商或新的地区，业务模块是自动上报，告警都也是自动应用上去，不需要人的持续性维护，降低漏告的可能性。

用户需要关注的、需要加告警的数据常常都是高维度的数据，而不是单台机器上报的某个细粒度的数据，低维度的单机数据如何做到每分钟高效率的汇聚为高维度的复合数据呢？这里面涉及到我们的实时计算模型。

图5维度x指标与特性id的对应关系

如上图，我们会把业务上报的“维度x指标”最细粒度的所有组合一一对应到系统内部维护的一个称之为特性id的唯一数据上面，譬如“xx业务+下载软件+深圳+移动+小图+流量”ó10254，我们把10254称之为简单特性。多台机器可以同时上报同一个简单特性，我们把位于具体某台机器上面上报的该简单特性称之为单机特性，譬如“10254+ip1”就是一个单机特性。多个简单特性按某种关系的复合计算称之为复合特性，譬如业务就分布在深圳与天津，深圳与天津的流量每一个都可认为是简单特性，这两个简单特性的求和就是复合特性-总流量，当然了计算方式还可能为求平均、求最大值、求商等，视不同场景决定。

图6特性id的实时计算模型

在把“维度x指标”转化为特性id之后，低维度的数据到高维度的数据的结构其实就相当于一颗树，业务上报的低维度数据就是树的叶子结点，用户需要的高维度数据就是这颗树中间或顶层结点，问题就转化为这颗树的叶子结点的值已知、向上汇聚的计算规划已知，需要每分钟高效率的计算出中间及顶层结点的值，这可以通过如上图的实时计算方法来解决，即每分钟从树的底层开始向上计算出每个结点的值并保存。

图7即时计算模型

实时计算只能把单机数据实时高效的汇聚为简单数据或提前定义好结构的复合数据，实际上不可能提前把“维度x指标”的所有组合都加到上面的这颗树里面做实时计算，因为这种组合数会太多，且大多数的组合在大部分时间都不会有用户查看，但用户的行为却是不固定的，很有可能某一时刻用户就想查看到某种没有提前定义好的组合数据，这种情况下可以使用如上图的即时计算方法来解决，即时查询出所有简单特性，根据计算规则把简单特性的值立即计算出用户需要的数据。

图8业务全路径布控

在业务监控方面，我们对业务的全路径进行布控，监控点部署在用户访问路径的各个层，以保证任何一个层的异常都能及时有效的发现，通过高效的监控系统，以及全路径的布控，我们目前的异常主动发现率已可达到99%。

四、移动化

在当今移动化时代，监控必然也要提供移动端的支持，目前我们通过腾讯内部的企业号来实现移动端的能力。告警的发送分析处理、业务质量视图曲线的查看等功能都已经下放到移动端，甚至春节等特别节假日我们也会提供专项的移动端支持。

文章来源公众号：腾讯架构师（TencentArchitecture）