随着搜索管控的统一，对智能运维能力也提出了新的要求，如何用同一套解决方案同时解决各系统的痛点问题做到AIOps能力复用，上篇文章已经介绍过hawkeye优化大师及torch容量评估的实践，本篇文章主要介绍下我们在异常检测，根因分析，冷数据及僵尸应用治理上的实践，各项实践也都取得了预期的效果。
下面分别介绍下以上问题我们的解决方案和进展。
异常检测
背景：
目前搜索系统的监控是基于规则的阈值报警，面对周期性指标，毛刺和稀疏数据等复杂场景难以适用，导致大部分指标报警泛滥，给用户带来很大的困扰，于是我们和kmon监控同学基于tisplus搜索业务平台top报警场景联合达摩院算法尝试增加异常检测进行智能报警治理报警泛滥问题。
解决方案：
（1）管理员在烽火台监控平台给指标配置异常检测算法及参数
（2）kmon-apiserver会定时同步烽火台报警配置，query及算法参数给kmon-batcher
（3）kmon-batcher从kmon-gateway获取指标数据并和（2）中获取的数据一同调用A-pack
（4）A-pack是异常检测算法业务层，负责跟异常检测算法服务IAD交互，并将异常检测结果返回给kmon-batcher
（5）IAD是异常检测算法docker服务，基于被监控指标过去一周的历史数据对当前时刻指标进行异常检测。
（6）kmon-batcher发现a-pack对数据的检测结果为异常调用kmon-action进行生产报警事件并进行报警
（7）烽火台配置样本管理页面进行样本标注，评估算法异常检测效果
效果评估:
异常检测算法针对周期性，稀疏数据，均值变化都做了比较好的识别和处理，抑制大量不必要的报警。
基于规则的阈值变化报警，指标瞬间抖动很容易起变化率超过阈值引起误报，如图1（黄色的点代表规则阈值报警），图2通过算法只有均值变化率大的时候才触发报警，从而避免了图1 大量的误报。
基于周期性的指标波动算法也能很好的识别，红色点代表周期性算法识别出来的异常点。
特别是稀疏数据的波动报警很容易引发误报如图4，算法通过自动识别稀疏数据剔除值为0点，这样在非0的历史数据上进行算法学习避免了大量的无效波动报警如图5
为了准确评估增加异常检测的效果，烽火台上增加样本管理功能，用户可以对异常检测结果进行标注，这些标注的样本一来用于异常检测算法效果优化，二来用于算法迭代版本更新时做回归case。
我们选择了tisplus top报警场景增加异常检测智能报警，并通过人工对2天的异常检测报警结果标注评测，异常检测算法准确率和召回率均在92%，之前规则报警2天的报警量是上万级，增加异常检测后报警量降低到百级别，报警量减少97%。
根因分析
背景：
随着搜索用户的增多，值班同学每天的答疑量巨大，排查问题耗费了很多人力，梳理下来出现的问题种类就那么几种，排查模式也无非看看链路相关的kmon监控指标和查看分析日志。为此，我们基于答疑较大的引擎增量异常场景结合专家经验进行根因分析的诊断，报警发生时直接基于规则给出问题触发原因以及排查问题所需的关联指标及日志信息，从而提升问题排查效率。目前采取是借助指标数据和规则树的方式进行诊断，主要涉及的有增量场景中的增量跌0和端到端延迟上升两种问题的诊断。
解决方案
效果评估
根因分析目前涉及了chatOps和智能报警两个应用场景，chatOps用于解决当线上出现问题用户自主@机器人，便可获取异常问题根因分析诊断结论以及辅助排查的关键metrics指标及日志信息，平均单个问题相对人肉排查方式至少节省10到15分钟排查时间，在智能报警里，一个是报警信息里我们会直接透出异常情况下的相关指标数据及根因分析协助用户接收到报警时能准确知道触发报警的原因，并能直接看到问题定位所需要的辅助信息，系统每次报警触发根因分析，我们都会把诊断结论及排查所需的所有辅助metrics和日志信息抽取作为样本持久化保存起来，目前已积累约4w条样本，这些样本成为机器学习方式解决根因分析分析问题的宝贵资源(目前还在进一步探索中)。
冷数据及僵尸应用治理
背景
随着搜索igraph、dii、be、ha3业务的增多，各平台不同程度的存在冷数据（冷表或僵尸应用），冷数据就是指长期无流量却占据着资源的服务，因此，需要一套统一自动机制管理这些冷数据下线。
解决方案
冷数据治理分为巡检和通知两部分逻辑。巡检通过平台提供的冷数据接口进行巡检识别出冷数据及僵尸应用。通知逻辑主要分为管理员视角和owner视角的。管理员可以看到平台冷数据占的总资源，owner可以看到具体负责的表，反馈功能增加了加白名单和确认下线两个功能。加白名单的服务有30天的有效期，确认下线的则会走自动下线的逻辑。
效果评估
左侧图是管理员视角可以清楚看到平台下的僵尸应用列表及浪费情况，右侧用户视角可以及时发现自己名下僵尸应用及一键下线，整个功能上线以来清理了数以百计的僵尸应用释放不少宝贵机器资源，让搜索平台和用户之间建立起了良性循环。
展望
随着过去我们在异常检测，根因分析，torch容量规划，hawkeye优化大师，僵尸应用治理等各AIOps方向的实践大大降低了成本提高了效率和稳定性，为下一步进行AIOPS平台化建设树立了信心，让搜索各在线服务也都能享受到AIOPS带来的福利。随着搜索云上输出，开放性，易用性是AIOps平台设计首要考虑的两个问题。
我们的初步架构如下：
Kmonitor定位智能运维数据平台，将采集，监控，报警，诊断，处理等基于一身，核心价值是平台使用海量数据结合算法能力让用户更加方便知晓应用的系统状况，可以更快捷的定位问题并解决问题，并且具备自动处理问题的能力。
Kmon-agent 采集端支持丰富的数据源输入如日志，系统指标，容器指标，以及各种用户自定义插件来对接各个系统，持续保持数万个采集实例低消耗稳定采集，计算，过滤，转换。
Gnomon轻量级高可用分布式时序数据库承载每秒上亿数据点写入，时序数据针对性优化高效支持时序数据压缩，聚合，采样，高性能海量时间线自适应索引，内存优先策略保证查询效率。机群高可扩展，数据动态分区，水平扩展，支持动态扩缩容。机群自动控制机制，支持多级数据备份存储保证机群可靠性。
Razor 端到端计算平台，支持海量异构数据源批流一体计算引擎，系统集成Robust-STL异常检测算法，时序异常检测，搜索引擎健康检测自愈，根因分析，弹性调度，容量规划等AIOps解决方案，用户也可以自定义UDF实现自己运维场景上的运维策略。
