2020年全球运维大会-全球最大呼叫平台监控实践课件

全球最大呼叫平台监控实践之路

全球最大呼叫平台监控实践之路1目录背景-全国集中维护、全球最大1出路-选择开源2转型-几个问题3蜕变-AIOPS在监控报警方面的尝试4

目录背景-全国集中维护、全球最大1出路-选择开源2转型-几个2中移在线公司移动全网集中服务提供者移动全网业务后台集中处理者移动全网渠道运营集中支撑者201431省呼叫业务完成划转奠定全网集中化运营基础2016实现盈利业务发展和改革创新初见成效全集团首批入选国资委国企改革“双百行动”三家公司之一2018201710月注册成立全集团集中化、专业化运营试验田发展历程

中移在线公司移动全网集中服务提供者移动全网业务后台集中处理3传统呼叫中心传统呼叫中心是基于PBX、专用硬件排队机、硬件语音板卡等专用设备组成的客服系统。软硬一体，不够灵活建设成本高、周期长、维护升级困难无法满足多渠道多媒体互联网相关增值业务的融合无法实现多客服中心坐席跨网协同无法快速响应业务需求缺点排队机CTIIVR应用PSTN/PLMNPBX坐席坐席

传统呼叫中心传统呼叫中心是基于PBX、专用硬件排队机、硬件语4新形态呼叫中心语音坐席视频坐席互联网坐席热线互联网新形态下的呼叫中心质量管控大数据平台支持客户全渠道交互智能质检智能导航智能应答转人工智能知识库坐席助手语音客服视频客服在线客服智能IVR智能运营运营管理呼叫平台统一排队统一路由统一监控纯软件：全媒体CTI、IVR、互联网接入网关、软交换、中继网关、媒体加速服务、用户终端富媒体：支持传统语音、文本、图片、视频、短语音、微信、微博智能化：与人工智能（AI）、大数据技术结合，应用于IVR、机器人应答、质检、外呼等集中化：接续、CRM、分析、质检、话务监控等集中化特征

新形态呼叫中心语音坐席视频坐席互联网坐席热线互联网新形5在线公司:

全球最大呼叫中心河南江苏北京我们面临的运维挑战多难高用户多,

IT规模接近一线互联网企业9亿用户,

超1亿微信粉丝，月服务超亿次，微博矩阵粉丝3038万（居行业首位），10086APP超五千万用户量20000+服务器50000+Tomcat业务变化快，运维环境复杂支撑全国营销活动，总部/分公司/省公司多级协同日均上线

17

次，日处理

206

例工单技术新：微服务/云计算/容器

…要求高，提供电信级服务99.99%

的可靠性15秒接通要求7*24

小时保障

在线公司:全球最大呼叫中心河南江苏北京我们面临的运维挑战多6转变运维思路，适应新的时代挑战为了支持业务快速上线和高效运维。在线公司监控系统需具备敏捷、集中、自动、智能的关键能力。自动敏捷之前能力建设智能现在监控能力周粒度提供监控能力分钟级提供按专业划分的“烟囱式监控”混合集中化监控手工添加基于策略的自动化闭环依赖专家经验基于AI和大数据的自动识别集中

转变运维思路，适应新的时代挑战为了支持业务快速上线和高效运维7目录1234背景-全国集中维护、全球最大出路-选择开源转型-几个问题蜕变-AIOPS在监控报警方面的尝试

目录1234背景-全国集中维护、全球最大出路-选择开源转型-8统一监控平台：开源工具+二次开发，自主核心可控监控管理Grafana统一门户ITSM运维平台自动化平台CMDB统一告警平台统一事件分析告警告警接口性能看板告警事件管理短信邮件工单信息故障定位或修复场景业务看板根因分析业务建模业务模型和配置数据被管环境Java

App.NET

AppPHP,Python,

NodeJS应用系统客服系统监控（I2000）应用性能监控（APM）告警信息场景执行调用性能看板业务看板业务数据PrometheusmetricElasticSearch数据库数据库监控（Prometheus）基础架构监控（Zabbix）CTI/UAP系统服务器、网络、存储、虚拟化环境等告警看板Kafka实时融合监控：引入业界开源工具，进行二次开发与封装，形成核心自主可控、稳定高效、海量秒级的监控能力。跨域/跨厂商/跨层的IT/CT实时融合监控。有丰富的管理对象。多样灵活的数据展现形式，可以灵活配置，适应不同场景，快速定制。监控数据

统一监控平台：开源工具+二次开发，自主核心可控监控管理Gra9统一监控平台：集中建设、统一管控、边缘节点标准化为了更快速的建立监控能力、更全面的管控系统质量，在线服务公司统一监控平台采用了总部集中建设、统一管控，分公司标准化接入的建设模式。全网集中：总部负责监控能力建设、边缘节点的标准化，所有监控数据的上收、分析、展现与通知。分公司提供资源，遵照标准化、封装后的监控模板进行监控资源的维护与管理。

统一监控平台：集中建设、统一管控、边缘节点标准化为了更快速的10一些小总结：半年时间2万200

万90

万30

万主机监控项触发器报警84400+5451.3KProxyDashBoard用户数动作

一些小总结：半年时间2万200万90万30万主机监控11一些小总结：广泛、丰富、多样、灵活

一些小总结：广泛、丰富、多样、灵活12网络设备类型与厂家存活/丢包/时延CPU/内存占用率snmp状态温度端口状态出/入口带宽利用率出/入口丢、错包接口类型设备状态 网卡状态 设备信息端口描述软件版本系统名称光功率光模块接收功率网络协议光模块发送 BGP对等体功率 连接状态ospf邻居状态vrrp虚拟路由状态网络监控指标SNMP一些小总结：广泛、丰富、多样、灵活

网络设备类型与厂家存活/丢包/时延CPU/内存占用率sn13一些小总结：广泛、丰富、多样、灵活看板可灵活制定，分钟级完成配置。图表多样化展现：折线图、柱状图、饼图、区域图、拓扑图等。

一些小总结：广泛、丰富、多样、灵活看板可灵活制定，分钟级完成14主机参数内核参数TCP协议栈参数信号量/IO（Zabbix启动失败不释放信号集）数据库CPU/内存/IO连接（最大连接数、超时时长）数据一致性强烈建议采用数据库SSD硬盘WEBNginx参数Php参数php.ini：max_input_vars（影响模板应用大批量主机失败）Zabbix视具体需求配置启动模块和进程数禁用自动发现，采用脚本调用api实现禁用housekeeper，启用数据库表分区禁用server直连agent配置参数优化defines.inc.php：QUEUE_DETAIL_ITEM_COUNT（定义监控项队列检索限制，影响消息队列积压显示）一些小总结：zabbix系统优化

主机参数数据库WEBZabbix一些小总结：zabbix系统15一些小总结：zabbix系统优化二、Preprocessing

manager

负荷长期为100%三、Zabbix

server主机反复重启，却无法启动成功问题现象与影响一、大量消息队列积压（超过20万），且呈现雪崩效应问题定位与解决方案一、zabbix官网对于pre-process耗尽的说明：二、解决方案：1、在zabbix

server所在主机再单独部署一个proxy节点。2、将之前由zabbix

server直接监控的所有proxy所在主机的agent节点，全部转到新增proxy管理。3、降低server的pollers、java

pollers、pingers、trappers等进程数配置。4、增加zabbix

server的自监控项配置项及告警（

Pre-process进程占用率及zabbix_server.log的异常关键字告警）。

一些小总结：zabbix系统优化二、Preprocessin16Zabbix配置的同步机制Zabbix的配置表比较多，大容量局点关联查询sql耗时很长如数据库控制sql执行时间的max_execution_time配置不合理，会导致无法将相应配置表数据同步到zabbix

server以及proxy的cache，从而导致出现大量监控项无法正常采集及消息队列积压现象。以下为zabbix_server.log相应日志：数据库sql执行超时配置建议根据现网的数据库IO处理性能以及局点规模合理配置数据库超时相关参数，将max_execution_time设置为超过目前zabbix

server同步配置sql执行时长的2倍以上，并定期检查zabbix_server.log日志的相应执行时长，或者增加自监控告警。一些小总结：zabbix系统优化

Zabbix配置的同步机制Zabbix的配置表比较多，大容量17目录1234背景-全国集中维护、全球最大出路-选择开源转型-几个问题蜕变-AIOPS在监控告警方面的尝试

目录1234背景-全国集中维护、全球最大出路-选择开源转型-18问题一：200w监控指标，业务出了问题仍然不知道治理范围应用系统管理业务质量管理客户体验管理能力扩展基础设施管理基础设施性能管理(PM)基础设施故障管理(FM)用户问题管理用户感知管理业务问题管理业务质量管理以业务质量和客户体验为核心，以可管控、可视化、可度量为目标。全网集中建设、集中管控、边缘节点标准化接入。软件监控+硬件监控一网打尽，运维数据统一、融合、流动，建立多层次度量体系。以用户体验出发，建立端到端全链路监控，告警+投诉预警+客服联动形成完整闭环管理。运维保障应用性能管理(PM)应用故障管理(FM)流程及自动化管理

问题一：200w监控指标，业务出了问题仍然不知道治理范围应19业务及应用质量可感知，是监控的核心ServerOSDBJVMMQWEB面向基础架构的监控只能发现约30%的问题从用户体验出发面向应用的监控能发现约70%的问题最终用户体验应用程序基础架构梳理业务系统核心功能模块梳理功能模块的核心监控指标评审监控指标的提取方式及有效性监控看板制作在强化基础设置监控的基础上，补充应用性能监控和业务质量监控能力，保障业务的稳定性和客户感知。应用性能监控 业务质量监控参考Google

SRE五项黄金指标1：速率：请求速率，请每秒请求数量。2：错误：

错误率，即每秒错误数量。3：延迟：

响应时间，包括队列/

等待时间，以毫秒为单位。4：饱和度：即过载程度，指标与资源利用率相关，也可通过队列深度进行直接衡量。5：利用率：

资源或系统的繁忙程度，通常表示为

0%

至

100%。应用性能监控将前台页面与后端服务以及用户网络环境真正串联，做到端到端全链路、代码级监控。用户体验评分

前端交互体验 网络切片 应用调用拓扑

代码定位追踪

业务及应用质量可感知，是监控的核心ServerOSDBJ20问题二：海量的日志是否有利用价值？对于亚健康状态，异常日志比系统故障更早出现。由于海量日志存储在海量网元中，不同厂商日志标准不统一且可读性差，往往很难鉴别真正触发异常的日志。挑战海量日志保存在海量网元中，缺乏统一视图不同厂商设备的日志缺乏统一标准，可读性差XXXX@%#&(*(

￥%……—*XXXX@#$%&*(%#@#$%CXXXX@!#$*^#$!@%$*(*(^XXXXERROR*&^%$#$*()*^日志统一采集，统一呈现，异厂商设备日志统一查询针对异常日志进行统计，实时推送异常日志告警，提升亚健康网络问题定位效率①跨厂商设备日志统一查询②异常日志统计③异常日志分析与告警推送统一日志分析Syslog网络设备(

Huawei,

HP,

IBM,…)Logstash一体化客服系统精准扶贫实名制 语音管控…价值Cloud

OS

问题二：海量的日志是否有利用价值？挑战海量日志保存在海量网21问题三：一个业务监控需要添加2480万个监控项？监控内容接口平台类型（

4）：接入接口，接入渠道，转接接口，转接渠道系统编码（31）：为各省分公司的编码监控项类型(8）：调用总数，成功率，平均耗时，失败率，失败数，大于1s比率，大于3s比率，大于5s比率监控项名称（500+）：从业务数据库实时查询监控项名称错误码（50+）：业务指标的错误码类型 （4*31*8*500*50=2480万）监控项类型大：千万级监控项组合，zabbix方案暂无法实现（包括监控配置和展示）图形展示筛选条件要求可配置，动态关联：zabbix解决方案暂无法实现（个性化tag无法关联查询）。难点说明解决方案利用prometheus灵活的自定义babel功能实现数据采集和动态图形展示

问题三：一个业务监控需要添加2480万个监控项？监控内容接22监控平台架构的改进与优化管控资源对象运维数据分析平台上层运维场景应用CMDB数据库企业资源数据监控底层能力平台PrometheusAPMHadoop离线数据分析运维数据分析内部用户物理设备云平台 网络一体化客服业务监控客服设备监控。。。容量管理自动化扩缩容。。。故障决策系统自动化切换。。。Zabbix外部客户日志 容器云

业务监控

数据库 应用 中间件日志平台规则数据机器学习数据Flink实时数据处理运维数据分析

监控平台架构的改进与优化管控资源对象运维数据分析平台上层23大型互联网公司基础资源多，业务广，线上变更频繁，监控配置任务量大监控添加不是一蹴而就，需要反复调整，重复工作量大开源工具使用门槛高，大多没有好用的web界面，需要培训才能灵活使用中移在线公司业务/工作人员遍布全国各省，基础资源达到上万级别，业务变更频繁，统一管理难度系数高痛点应对方案12监控能力标准化、流程化、模块化二次开发、

3自动化配置界面化数据展示界面化问题四：加不完的监控需求？

大型互联网公司基础资源多，业务广，线上变更频繁，监控配置任24中移在线监控的历程（摸着石头过河）1需求分析与功能验证23全网推广性能调优典型问题与4软件bug处理规范化制定与整改5运维界面化与自动化欲速则不达没有规范化的交付，质量无法保证返工意味着效率降低3倍以上12需求分析与功能验证标准与规范制定3性能调优典型问题与软件bug处理4批量推广5运维界面化与自动化建议流程（标准先行，质量与效率并重）模板、主机群组、主机名，主机显示名、动作名称、展板内容等等需求交付/变更流程，问题处理流程，例行会议与周报一点感悟

中移在线监控的历程（摸着石头过河）1需求分析与功能验证225现在的数字2.4

万主机99

万触发器1.3K动作614

万监控项198

万报警Proxy92800+ 975DashBoard 用户数

现在的数字2.4万99万1.3K614万198万报警26目录1234背景-全国集中维护、全球最大出路-选择开源转型-几个问题蜕变-AIOPS在监控告警方面的尝试

目录1234背景-全国集中维护、全球最大出路-选择开源转型-27当前的主要矛盾是：海量的告警和有限的专家告警要“少而精”，不要重复和误报监控要“多而全”，一个问题都不能放过！614万+

监控指标，99万+

报警阈值，

198万+

告警/天，

2000+

短信/每人每天运维主管工程师小明VS.

当前的主要矛盾是：海量的告警和有限的专家告警要“少而精”，28经过分析，阈值正确设定是平衡“多而全”和“少而精”的关键手段之一告警正常告警误报漏报缺少压缩&关联阈值不合理：80%监控能力不足：10%人员配置失误：10%无法设定阈值：70%无监控：30%

经过分析，阈值正确设定是平衡“多而全”和“少而精”的关键手段29阈值设定从依靠专家经验向智能动态设定演进专家依靠经验设定规则阈值通过大数据分析设定固定阈值通过智能分析动态设定智能动态阈值

阈值设定从依靠专家经验向智能动态设定演进专家依靠经验设定通30基于结构化的时序数据，通过AI预测拟合曲线，进行异常检测历史数据分析历史数据读取和清洗数据抽取ETL断点修复数据间隔调整自相关性分析毛刺检测统计异常检测，用于过滤毛刺型异常Moving

Average移动平均滤波(ARIMA)Exponential

Smoothing指数平滑滤波

(Holt-Winters)N*sigma统计检测指标预测LSTM（长短期记忆）预测算法孤立森林（IsolationForest）日同比（Day

overDaymethod）箱线图（Box-whisker

plot）异常判定途径一：N-sigma方差途径二：专家标记

基于结构化的时序数据，通过AI预测拟合曲线，进行异常检测历史31智能化运维并不是我们想象的那样遥不可及告警覆盖率提升到95%告警配置人力下降60%告警准确率提升到80%数据算法计算海量数据源（性能指标、日志、告警）可以迭代预测、迭代标注……TensorFlow等成熟算法库针对不同场景，可选择不同算法，如LSTM用于趋势预测、ARIMA用于回归过滤异常轻量化虚拟机部署，4C32G即可起步

智能化运维并不是我们想象的那样遥不可及告警覆盖率提升到9532未来让智能化在更多运维领域落地开花智能故障发现日志异常检测、告警压缩&关联、告警规则生成、容量管理、性能管理等深度广度

未来让智能化在更多运维领域落地开花智能故障发现日志异常检测33系统架构师、运维开发、应用运维、数据库运维、大数据运维、数据分析、容器云开发、云计算开发、JAVA开发享受互联网般技术挑战国企稳定待遇郑州、北京、上海、深圳研发中心，31省会城市与客户交互产生的海量数据，包括语音、文本、图像等数据公司年轻、人员年轻、扁平化管理

系统架构师、运维开发、应用运维、数据库运维、大数据运维、数据34谢谢

谢谢35全球最大呼叫平台监控实践之路

全球最大呼叫平台监控实践之路36目录背景-全国集中维护、全球最大1出路-选择开源2转型-几个问题3蜕变-AIOPS在监控报警方面的尝试4

目录背景-全国集中维护、全球最大1出路-选择开源2转型-几个37中移在线公司移动全网集中服务提供者移动全网业务后台集中处理者移动全网渠道运营集中支撑者201431省呼叫业务完成划转奠定全网集中化运营基础2016实现盈利业务发展和改革创新初见成效全集团首批入选国资委国企改革“双百行动”三家公司之一2018201710月注册成立全集团集中化、专业化运营试验田发展历程

中移在线公司移动全网集中服务提供者移动全网业务后台集中处理38传统呼叫中心传统呼叫中心是基于PBX、专用硬件排队机、硬件语音板卡等专用设备组成的客服系统。软硬一体，不够灵活建设成本高、周期长、维护升级困难无法满足多渠道多媒体互联网相关增值业务的融合无法实现多客服中心坐席跨网协同无法快速响应业务需求缺点排队机CTIIVR应用PSTN/PLMNPBX坐席坐席

传统呼叫中心传统呼叫中心是基于PBX、专用硬件排队机、硬件语39新形态呼叫中心语音坐席视频坐席互联网坐席热线互联网新形态下的呼叫中心质量管控大数据平台支持客户全渠道交互智能质检智能导航智能应答转人工智能知识库坐席助手语音客服视频客服在线客服智能IVR智能运营运营管理呼叫平台统一排队统一路由统一监控纯软件：全媒体CTI、IVR、互联网接入网关、软交换、中继网关、媒体加速服务、用户终端富媒体：支持传统语音、文本、图片、视频、短语音、微信、微博智能化：与人工智能（AI）、大数据技术结合，应用于IVR、机器人应答、质检、外呼等集中化：接续、CRM、分析、质检、话务监控等集中化特征

新形态呼叫中心语音坐席视频坐席互联网坐席热线互联网新形40在线公司:

全球最大呼叫中心河南江苏北京我们面临的运维挑战多难高用户多,

IT规模接近一线互联网企业9亿用户,

超1亿微信粉丝，月服务超亿次，微博矩阵粉丝3038万（居行业首位），10086APP超五千万用户量20000+服务器50000+Tomcat业务变化快，运维环境复杂支撑全国营销活动，总部/分公司/省公司多级协同日均上线

17

次，日处理

206

例工单技术新：微服务/云计算/容器

…要求高，提供电信级服务99.99%

的可靠性15秒接通要求7*24

小时保障

在线公司:全球最大呼叫中心河南江苏北京我们面临的运维挑战多41转变运维思路，适应新的时代挑战为了支持业务快速上线和高效运维。在线公司监控系统需具备敏捷、集中、自动、智能的关键能力。自动敏捷之前能力建设智能现在监控能力周粒度提供监控能力分钟级提供按专业划分的“烟囱式监控”混合集中化监控手工添加基于策略的自动化闭环依赖专家经验基于AI和大数据的自动识别集中

转变运维思路，适应新的时代挑战为了支持业务快速上线和高效运维42目录1234背景-全国集中维护、全球最大出路-选择开源转型-几个问题蜕变-AIOPS在监控报警方面的尝试

目录1234背景-全国集中维护、全球最大出路-选择开源转型-43统一监控平台：开源工具+二次开发，自主核心可控监控管理Grafana统一门户ITSM运维平台自动化平台CMDB统一告警平台统一事件分析告警告警接口性能看板告警事件管理短信邮件工单信息故障定位或修复场景业务看板根因分析业务建模业务模型和配置数据被管环境Java

App.NET

AppPHP,Python,

NodeJS应用系统客服系统监控（I2000）应用性能监控（APM）告警信息场景执行调用性能看板业务看板业务数据PrometheusmetricElasticSearch数据库数据库监控（Prometheus）基础架构监控（Zabbix）CTI/UAP系统服务器、网络、存储、虚拟化环境等告警看板Kafka实时融合监控：引入业界开源工具，进行二次开发与封装，形成核心自主可控、稳定高效、海量秒级的监控能力。跨域/跨厂商/跨层的IT/CT实时融合监控。有丰富的管理对象。多样灵活的数据展现形式，可以灵活配置，适应不同场景，快速定制。监控数据

统一监控平台：开源工具+二次开发，自主核心可控监控管理Gra44统一监控平台：集中建设、统一管控、边缘节点标准化为了更快速的建立监控能力、更全面的管控系统质量，在线服务公司统一监控平台采用了总部集中建设、统一管控，分公司标准化接入的建设模式。全网集中：总部负责监控能力建设、边缘节点的标准化，所有监控数据的上收、分析、展现与通知。分公司提供资源，遵照标准化、封装后的监控模板进行监控资源的维护与管理。

统一监控平台：集中建设、统一管控、边缘节点标准化为了更快速的45一些小总结：半年时间2万200

万90

万30

万主机监控项触发器报警84400+5451.3KProxyDashBoard用户数动作

一些小总结：半年时间2万200万90万30万主机监控46一些小总结：广泛、丰富、多样、灵活

一些小总结：广泛、丰富、多样、灵活47网络设备类型与厂家存活/丢包/时延CPU/内存占用率snmp状态温度端口状态出/入口带宽利用率出/入口丢、错包接口类型设备状态 网卡状态 设备信息端口描述软件版本系统名称光功率光模块接收功率网络协议光模块发送 BGP对等体功率 连接状态ospf邻居状态vrrp虚拟路由状态网络监控指标SNMP一些小总结：广泛、丰富、多样、灵活

网络设备类型与厂家存活/丢包/时延CPU/内存占用率sn48一些小总结：广泛、丰富、多样、灵活看板可灵活制定，分钟级完成配置。图表多样化展现：折线图、柱状图、饼图、区域图、拓扑图等。

一些小总结：广泛、丰富、多样、灵活看板可灵活制定，分钟级完成49主机参数内核参数TCP协议栈参数信号量/IO（Zabbix启动失败不释放信号集）数据库CPU/内存/IO连接（最大连接数、超时时长）数据一致性强烈建议采用数据库SSD硬盘WEBNginx参数Php参数php.ini：max_input_vars（影响模板应用大批量主机失败）Zabbix视具体需求配置启动模块和进程数禁用自动发现，采用脚本调用api实现禁用housekeeper，启用数据库表分区禁用server直连agent配置参数优化defines.inc.php：QUEUE_DETAIL_ITEM_COUNT（定义监控项队列检索限制，影响消息队列积压显示）一些小总结：zabbix系统优化

主机参数数据库WEBZabbix一些小总结：zabbix系统50一些小总结：zabbix系统优化二、Preprocessing

manager

负荷长期为100%三、Zabbix

server主机反复重启，却无法启动成功问题现象与影响一、大量消息队列积压（超过20万），且呈现雪崩效应问题定位与解决方案一、zabbix官网对于pre-process耗尽的说明：二、解决方案：1、在zabbix

server所在主机再单独部署一个proxy节点。2、将之前由zabbix

server直接监控的所有proxy所在主机的agent节点，全部转到新增proxy管理。3、降低server的pollers、java

pollers、pingers、trappers等进程数配置。4、增加zabbix

server的自监控项配置项及告警（

Pre-process进程占用率及zabbix_server.log的异常关键字告警）。

一些小总结：zabbix系统优化二、Preprocessin51Zabbix配置的同步机制Zabbix的配置表比较多，大容量局点关联查询sql耗时很长如数据库控制sql执行时间的max_execution_time配置不合理，会导致无法将相应配置表数据同步到zabbix

server以及proxy的cache，从而导致出现大量监控项无法正常采集及消息队列积压现象。以下为zabbix_server.log相应日志：数据库sql执行超时配置建议根据现网的数据库IO处理性能以及局点规模合理配置数据库超时相关参数，将max_execution_time设置为超过目前zabbix

server同步配置sql执行时长的2倍以上，并定期检查zabbix_server.log日志的相应执行时长，或者增加自监控告警。一些小总结：zabbix系统优化

Zabbix配置的同步机制Zabbix的配置表比较多，大容量52目录1234背景-全国集中维护、全球最大出路-选择开源转型-几个问题蜕变-AIOPS在监控告警方面的尝试

目录1234背景-全国集中维护、全球最大出路-选择开源转型-53问题一：200w监控指标，业务出了问题仍然不知道治理范围应用系统管理业务质量管理客户体验管理能力扩展基础设施管理基础设施性能管理(PM)基础设施故障管理(FM)用户问题管理用户感知管理业务问题管理业务质量管理以业务质量和客户体验为核心，以可管控、可视化、可度量为目标。全网集中建设、集中管控、边缘节点标准化接入。软件监控+硬件监控一网打尽，运维数据统一、融合、流动，建立多层次度量体系。以用户体验出发，建立端到端全链路监控，告警+投诉预警+客服联动形成完整闭环管理。运维保障应用性能管理(PM)应用故障管理(FM)流程及自动化管理

问题一：200w监控指标，业务出了问题仍然不知道治理范围应54业务及应用质量可感知，是监控的核心ServerOSDBJVMMQWEB面向基础架构的监控只能发现约30%的问题从用户体验出发面向应用的监控能发现约70%的问题最终用户体验应用程序基础架构梳理业务系统核心功能模块梳理功能模块的核心监控指标评审监控指标的提取方式及有效性监控看板制作在强化基础设置监控的基础上，补充应用性能监控和业务质量监控能力，保障业务的稳定性和客户感知。应用性能监控 业务质量监控参考Google

SRE五项黄金指标1：速率：请求速率，请每秒请求数量。2：错误：

错误率，即每秒错误数量。3：延迟：

响应时间，包括队列/

等待时间，以毫秒为单位。4：饱和度：即过载程度，指标与资源利用率相关，也可通过队列深度进行直接衡量。5：利用率：

资源或系统的繁忙程度，通常表示为

0%

至

100%。应用性能监控将前台页面与后端服务以及用户网络环境真正串联，做到端到端全链路、代码级监控。用户体验评分

前端交互体验 网络切片 应用调用拓扑

代码定位追踪

业务及应用质量可感知，是监控的核心ServerOSDBJ55问题二：海量的日志是否有利用价值？对于亚健康状态，异常日志比系统故障更早出现。由于海量日志存储在海量网元中，不同厂商日志标准不统一且可读性差，往往很难鉴别真正触发异常的日志。挑战海量日志保存在海量网元中，缺乏统一视图不同厂商设备的日志缺乏统一标准，可读性差XXXX@%#&(*(

￥%……—*XXXX@#$%&*(%#@#$%CXXXX@!#$*^#$!@%$*(*(^XXXXERROR*&^%$#$*()*^日志统一采集，统一呈现，异厂商设备日志统一查询针对异常日志进行统计，实时推送异常日志告警，提升亚健康网络问题定位效率①跨厂商设备日志统一查询②异常日志统计③异常日志分析与告警推送统一日志分析Syslog网络设备(

Huawei,

HP,

IBM,…)Logstash一体化客服系统精准扶贫实名制 语音管控…价值Cloud

OS

问题二：海量的日志是否有利用价值？挑战海量日志保存在海量网56问题三：一个业务监控需要添加2480万个监控项？监控内容接口平台类型（

4）：接入接口，接入渠道，转接接口，转接渠道系统编码（31）：为各省分公司的编码监控项类型(8）：调用总数，成功率，平均耗时，失败率，失败数，大于1s比率，大于3s比率，大于5s比率监控项名称（500+）：从业务数据库实时查询监控项名称错误码（50+）：业务指标的错误码类型 （4*31*8*500*50=2480万）监控项类型大：千万级监控项组合，zabbix方案暂无法实现（包括监控配置和展示）图形展示筛选条件要求可配置，动态关联：zabbix解决方案暂无法实现（个性化tag无法关联查询）。难点说明解决方案利用prometheus灵活的自定义babel功能实现数据采集和动态图形展示

问题三：一个业务监控需要添加2480万个监控项？监控内容接57监控平台架构的改进与优化管控资源对象运维数据分析平台上层运维场景应用CMDB数据库企业资源数据监控底层能力平台PrometheusAPMHadoop离线数据分析运维数据分析内部用户物理设备云平台 网络一体化客服业务监控客服设备监控。。。容量管理自动化扩缩容。。。故障决策系统自动化切换。。。Zabbix外部客户日志 容器云

业务监控

数据库 应用 中间件日志平台规则数据机器学习数据Flink实时数据处理运维数据分析

监控平台架构的改进与优化管控资源对象运维数据分析平台上层58大型互联网公司基础资源多，业务广，线上变更频繁，监控配置任务量大监控添加不是一蹴而就，需要反复调整，重复工作量大开源工具使用门槛高，大多没有好用的web界面，需要培训才能灵活使用中移在线公司业务/工作人员遍布全国各省，基础资源达到上万级别，业务变更频繁，统一管理难度系数高痛点应对方案12监控能力标准化、流程化、模块化二次开发、

3自动化配置界面化数据展示界面化问题四：加不完的监控需求？

大型互联网公司基础资源多，业务广，线上变更频繁，监控配置任59中移在线监控的历程（摸着石头过河）1需求分析与功能验证23全网推广性能调优典型问题与4软件bug处理规范化制定与整改5运维界面化与自动化欲速则不达没有规范化的交付，质量无法保证返工意味着效率降低3倍以上12需求分析与功能验证标准与规范制定3性能调优典型问题与软件bug处理4批量推广