作者简介
林晨曦，携程酒店研发部资深测试开发工程师，主要从事测试框架和平台的研发，现在负责监控系统与性能平台，热衷于研究技术提升测试工作效率。
一、前言
携程酒店业务量巨大，产生海量的埋点数据，以应用为单位接入公共日志平台；常规监控系统无法精确定位业务问题，测试人员花费大量时间查询与判断异常数据，低效且反应滞后。
为此我们根据测试痛点设计了一系列面向具体业务指标的监控，并在此基础上搭建了系统级的监控平台。本文将介绍酒店的智能监控系统，并详细阐述其中核心部分：针对酒店Clog和ES埋点数据的智能实时监控。
二、酒店监控系统
1、监控现状
酒店业务众多，关系链复杂，目前应用数量已经超过2000个，即使经过一系列线下测试，在上线以后还是要如履薄冰，业务人员要时刻关注各项指标，对波动及时查明原因，防止线上故障。
公共方面已有Sitemon，Hickwall等监控报表系统，我们结合了业务需求，在测试工作中构建了为测试工作服务的一些监控系统：
Smart：智能监控平台，基于主动健康监测和日志收集的智能保障系统
Mdata：性能埋点平台，针对具体业务指标在ES&Dashboard里埋点数据进行条件聚合用于性能预警与数据展示
Artemis：API自动化监控平台，通过自动化运行收集数据进行监控，并对ES埋点涉及多个不同数据Index的业务指标进行逻辑处理的ES监控
2、监控工作简介为什么要设计自己的监控系统？海量数据带来了一系列挑战：
数据量大：
通过CAT系统采集到每天埋点数据
-2000+亿条日志
-100+T业务日志通过CAT进入ES
维度多：
如此海量数据，在数据大盘里即使已有过滤条件搜索仍如同大海捞针，以下为监控难点：
-
日志平台记录大量零散数据，查询不便
-
不能配置细粒度规则，用户难以定制符合业务需求预警
-
无法判断是否遗留问题
-
没有分析模块，不能跟踪用户分析行为
-
业务人员只关注生产环境，测试环境日志信息未起到先验效果
我们希望监控实现目标：
-
监控为业务服务，以具体业务需求为切入点，持续集成，快速交付
-
构建可扩展监控体系，避免为业务调整增加大量项目复杂度
-
监控尽量实时，提供信息量全面
-
覆盖面广，自动部署，减少人工值守时间
-
集中式管理，方便配置
在搭建监控系统过程中，我们主要是通过两种方式：
-
主动检测式监控: 通过自动化手段模拟用户行为进行采点分析，统计Badcase
-
埋点收集方式: 与开发配合，在代码里埋点关键数据，通过数据采集处理进行监控
监控系统以应用为维度，方便业务人员明确排查范围
埋点数据采集监控占了很大监控比重，数据真实性高，也方便做实时预警，处理埋点数据过程中采用了对已有Clog&ES&Dashboard埋点平台做二次挖据方式。
之所以不直接通过Kafka消费原始数据，因为Clog&ES&Dashboard已有可以配置条件的索引过滤掉用户无需关心数据，尽管数据落地有延迟，但是与需要过滤数据的量级相比，这种不利因素可以接受。以下介绍重点针对Clog与ES埋点监控内容。
3、监控效果酒店监控平台目前已经配置了30多种主动式自动化监控，并有以下系统级监控：
-
Clog监控
-
ES&Dashboard规则监控
-
机器状态监控
-
Job监控
-
Badsql监控
-
ART报表监控
-
DB数据库一致性监控
-
CAT服务响应时间监控
监控获得收益：
-
覆盖所有酒店核心应用
-
系统灵敏度高，出现问题立即暴露，及时解决
-
发现需要分析问题>60000，平台自动创建CP4 Bug>4000
三、Clog监控的前世今生
我们从Clog系统能获取到的信息：
-
日志信息: AppID、服务器、标题、来源、信息、错误类型、CatId
-
日志级别: DEBUG、INFO、WARN、ERROR、FATAL
-
日志类型: APP、URL、WEB_SERVICE、SQL、MEMCACHED
-
借助CAT获取详细信息
Clog监控系统根据日志信息指标配置成规则，采用了两种监控方式：
1.0监控：应用级日志监控, 用户配置应用信息，设置阈值与过滤项，扫描应用日志根据历史比对发现新错误信息，超过阈值的错误量，需要关注错误内容预警到关注用户。
1.0规则配制图
2.0监控：重要Issue部门级智能监控,用户配置错误类型，设置需要关注应用信息，扫描所有关注应用里匹配该错误类型信息并预警到关注用户，生成缺陷到CP4。
2.0规则配置图
监控初期1.0的预警对象是错误量和新问题，从1.0到2.0的扩展是一次从问题收集到智能筛选的过程，如空指针引用、内存问题都是开发需要重点关注并解决的缺陷，这些处理也是可以明确为程序问题并直接开Bug的，从而减少了用户分析时间，而且部门级监控可以拉取所有酒店应用信息无需单独配置。
监控原理：
-
用户在系统中配置监控规则
-
主服务器根据用户配置自动生成执行任务，并调度分布式执行机执行，执行机分生产与测试环境，可收集不同环境数据
执行机配置管理图
-
执行机上数据监视器通过配置规则批处理运行任务，该过程包括数据采集、算法过滤、历史比对、系统扫描，异常数据传至邮件服务器预警并推送到CP4，目前日运行任务数>30万，最小时间粒度可至20秒
1.0预警邮件
2.0预警邮件
-
监控缺陷数据处理环节，生成质量闭环报告，数据直接推送给质量平台，长期追踪解决结果。
Clog监控系统架构图
指标监控->全链路监控：
为帮助业务人员分析问题，需要提供尽可能详细的信息，让用户从多维角度快速定位问题来源，预警信息集成了以下信息：
-
CAT系统获取应用上下游调用关系与波动程度
-
NOC系统获取到配置修改信息
-
发布系统获取最新发布状态
-
SLB系统获取机器状态信息
Clog监控还提供了一些辅助功能：
-
集成TTS电话系统，重要预警可电话到负责人
-
集成Trace功能，有性能问题机器会被自动拉出集群采集Trace用于性能分析
对用户而言，使用Clog监控需要处理的内容：
-
配置规则
-
处理预警邮件，在平台及时完成分析
-
查看个人未解决问题
-
推动开发解决未完成Bug
四、从Mdata到Artemis：深度挖掘ES
ES数据量巨大，但是它自带的聚合功能可以大大减少数据量，用户关注的其实还是符合特征的数值指标。
根据特征聚合ES数据，我们设计了早期Mdata平台的ES监控，用户直接配置Json到规则，后台Job定时执行抓取数据源数据。平台有以下特征：
-
配置简单，用户只需复制ES里的Json内容
-
形式多样，可以配置百分比与数值形式
-
监控采用系统默认与用户配置两种，系统默认采用环比增量预警方式
-
数据采集时间<10分钟
-
半小时与按天预警同时设置
-
集成系统发布信息与用户历史分析内容
-
性能问题直接创建缺陷到CP4关联到性能负责人
-
存储时间长，系统保留超过半年数据，可以查看长期趋势与历史分析内容
大量使用后的业务痛点：
-
预警邮件多，对于波动较大指标很难界定
-
性能问题成因复杂，定位困难
-
预警阈值不好控制，业务变更造成前后不一致内容多，宽严两难
在进一步分析与调整中，采用了区别对待的处理方案，对于核心应用关键指标更多采用上下限阈值处理，并且预警时间达到<10分钟。一般指标预警规则也更严格，达到连续增长趋势才会触发报警。
业务的发展带来很多难以界定的指标，数据埋点往往不能用单一规则来处理，需要对ES数据做更深的挖掘，在原来单指标监控基础上我们发展出了Artemis ES自定义指标监控，监控内容有以下扩展：
-
对抓取ES数据做了逻辑处理，包括对不同Index的数据进行聚合，项目复杂度有所增加，更多应用于数量有限的关键业务指标
-
配置规则多样化，提供了更多阈值检查
-
维度更接近业务内容，用户有更多筛选方式
-
实时度高，抓取数据时间<2分钟
目前对ES数据的挖掘还有很多系统，公共Sitemon，Hickwall上也能配置ES规则与报警，我们的主动式自动化监控也有一些是对更细的包括未聚合具体埋点内容的分析，数据挖掘还有很多内容可以探索。
五、尾声
监控的目标是为了提高系统预警准确率与实时性，从而提高测试效率，减少人工值守时间。而监控全面化带来了一系列新的问题，目前公共Sitemon上已有超过10000个监控指标，大量告警需要更好的降噪处理。
从方法角度看，只有指标越细覆盖越广才能达到更高精度，而这需要大量逻辑处理提高了系统复杂度。现在流行的机器学习是个可以突破的方向，通过模型处理数据来提高报警精度，这也是监控下一步的工作目标，让预警更快更准，监控更智能化，在这个过程中需要更多思维突破与创新，让质量真正闭环。
【推荐阅读】
