《云上大型赛事保障白皮书》——第四章 监控告警与应急预案——4.1 云上大型赛事监控告警——4.1.1 监控告警基本概念

本文涉及的产品
云监控,每月短信1000条
日志服务 SLS,月写入数据量 50GB 1个月
简介: 《云上大型赛事保障白皮书》——第四章 监控告警与应急预案——4.1 云上大型赛事监控告警——4.1.1 监控告警基本概念

第四章 监控告警与应急预案


上一章,我们全面介绍了压测调优和技术演练。但是,任何的压测调优、技术演练等风险治理手段都不能完全消除风险,那么我们就需要有对应的手段来感知风险、提示风险,并作出对应的风险处理。本章,我们将讨论如何通过监控告警体系来实现对各系统实时的运转情况和风险的感知与处理,以及对应的应急预案。


4.1 云上大型赛事监控告警


4.1.1 监控告警基本概念


4.1.1.1 监控告警系统CTPS模型原则


对于云上大型赛事活动来说,建设一个相对优秀的监控告警系统是有章法可依的,下面是整理抽象的适用于建设一般监控告警系统的CTPS模型。

全面(Comprehensive),监控覆盖要全面,从系统监控、应用监控、云平台监控、云产品监控到业务监控缺一不可。对于云上系统来讲,因为有物理网和云网络、IaaS和PaaS的区分,因此天然是有分层的概念的,底层为云平台,中层为云产品,上层为业务应用,一个全面的监控告警系统,应至少包含这三层。

实时(Timely),告警实时性要高,一般来说从监控触发告警到工程师接收告警,整个流程时间消耗是秒级的。得益于阿里云成熟的云平台故障管理体系,及标准化商业化的监控产品'云监控',我们总是可以在云平台层和云产品层面,做到实时的告警,即时发现即时告警。而在应用层的监控则见仁见智,其告警的实时性则取决于监控系统的设计。

准确(Precise),告警信息要准确,要有足够高的信噪比。

智能(Smart),告警信息要智能,告警可以给到工程师更多的有效信息,可以自动化完成一些根因分析甚至运维操作。


4.1.1.2 云上大型赛事监控告警系统设计


4.1.1.2.1 分层监控

云上大型赛事虽然东西向的结构比较复杂,但是其纵向的层次结构是比较清晰的。最底层为云平台物理层,这里是云产品的底座,包括IDC机房、机房中的计算和存储集群、物理网络网络设备(传统的接入、汇聚、核心三层)、云产品底层物理设备(如XGW、CGW等)、及其他平台层设备等。云产品则是运行在云平台物理层之上的标准化IaaS\PaaS\SaaS产品,是我们售卖的商品,也是我们给客户提供的资源。再往上则是客户的应用层,基于我们的标准化云产品构建具体的业务。

因此,云上大型赛事的监控告警系统天然就适配分层的设计理念,对整个系统每一层分别进行监控和告警,相互之间不必有强关联,可以解耦式设计各层的监控告警体系,再最终有机的整合到一起。

对于云平台物理层的监控,我们关注的是物理设备的运转情况,例如机房电压、网络设备资源利用率、底层设备故障情况等等,这个层面是很难感知到应用业务层的运转情况的,比如计算集群中某一台宿主机宕机,其实一般情况下我们并不清楚这个问题会造成最上层应用受到什么影响,这就需要通过云产品层和详细系统架构图做一个连接,以在告警出来时我们能第一时间掌握业务受损情况。

对于云产品层的监控,通常是采用各厂商的商业化云监控产品对各标准云产品进行监控和告警。阿里云云监控(CloudMonitor)是一项针对阿里云资源和互联网应用进行监控的服务,已经是我们非常成熟的产品,也积累了丰富详细的监控方案,并仍然在不停迭代发展中。阿里云所有的标准化云产品的底层监控数据都已经接入云监控,底层全部打通,并且云监控开放了大量的监控告警能力给客户,可以说,任何一个部署在阿里云上的大型系统,其云产品层的监控基本肯定是需要由云监控(CloudMonitor)来做主导。

对于应用业务层的监控,大部分情况下需要云厂商和赛事方共建,这有时候取决于客户侧的IT技术水平,或者阿里云的TAM\SRE团队多大程度上介入到客户的业务中。常见的监控指标有应用层的接口可用率、接口时延、流量等,这些指标是最直观反应应用运转情况的指标。阿里云有一些商业化产品具有应用层监控的能力,例如云监控的站点监控,或者ARMS业务监控,通过应用探针集成到客户具体业务功能中收集数据,可以提供业务层的洞察。


4.1.1.2.2 监控数据生命周期管理

监控数据的全生命周期包括数据生产、数据采集与存储、数据消费三部分,下面分别简单介绍在大型赛事场景下针对监控数据的管理。

大型赛事场景下,由于系统架构天然分层的存在,监控数据会产生在不同的数据源,这些数据源多种多样,可能来自于物理层的设备日志,也可能来自于产品运行时埋点日志,也可能来自于应用探针探测,这些都是监控数据的原始metadata。这些原始数据是层系统运转时产生的生产实时运转情况,但通常是无业务含义的数据流。

不同数据源的原始数据有不同的采集与存储方式,注意数据采集这里有一个不可能三角,即:采集速率、准确性、成本无法同时达到最优,如果所有的原始数据都采集存储,那么准确性能达到最高,但成本会比较高,如果要降成本,可以根据情况增大采样间隔,但这势必会影响到数据的准确性,所以数据采集这里总是会有一个平衡与取舍。数据存储方面,对于阿里云云平台物理层或者云产品层来讲,常见的监控数据存储方式是由产品侧数据源通过接口调用把采集到的数据投递到云产品内部账号的日志服务(SLS)的一个logstore中,阿里云日志服务是我们的一款标准化商业化产品,一站式提供数据采集、加工、查询与分析、可视化、告警、消费与投递等功能,已成为阿里云各层云产品存储生产日志的缺省值。对于应用业务监控,可以使用标准的日志服务,也可以自建日志存储库。

监控数据的数据消费,其实就是告警与处理。阿里云云监控提供了完善的告警功能,可以自定义阈值告警规则和事件告警规则,并实时推送至邮件、短信、电话、Webhook等多种渠道,云上的日志服务+云监控告警功能,已成为大型赛事监控告警系统的事实标准。

相关实践学习
基于云监控实现的监控系统
通过阿里云云监控功能给非阿里云主机安装监控插件,从而实现对非阿里云主机的各项指标进行监控和管理,在配置报警规则和报警人的情况下,能对特定的场景做出报警反应通知到报警人的手机上。
相关文章
|
弹性计算 监控 关系型数据库
《云上大型赛事保障白皮书》——第四章 监控告警与应急预案——4.1 云上大型赛事监控告警——4.1.2 北京冬奥监控告警体系介绍(3)
《云上大型赛事保障白皮书》——第四章 监控告警与应急预案——4.1 云上大型赛事监控告警——4.1.2 北京冬奥监控告警体系介绍(3)
|
监控 安全 API
《云上大型赛事保障白皮书》——第四章 监控告警与应急预案——4.1 云上大型赛事监控告警——4.1.2 北京冬奥监控告警体系介绍(2)
《云上大型赛事保障白皮书》——第四章 监控告警与应急预案——4.1 云上大型赛事监控告警——4.1.2 北京冬奥监控告警体系介绍(2)
176 0
|
缓存 Prometheus 监控
《云上大型赛事保障白皮书》——第四章 监控告警与应急预案——4.1 云上大型赛事监控告警——4.1.2 北京冬奥监控告警体系介绍(1)
《云上大型赛事保障白皮书》——第四章 监控告警与应急预案——4.1 云上大型赛事监控告警——4.1.2 北京冬奥监控告警体系介绍(1)
146 0
|
弹性计算 容灾 关系型数据库
《云上大型赛事保障白皮书》——第三章 压测调优与技术演练——3.2 云上大型赛事技术演练——3.2.2 容灾演练及冬奥实践(下)
《云上大型赛事保障白皮书》——第三章 压测调优与技术演练——3.2 云上大型赛事技术演练——3.2.2 容灾演练及冬奥实践(下)
|
存储 弹性计算 容灾
《云上大型赛事保障白皮书》——第三章 压测调优与技术演练——3.2 云上大型赛事技术演练——3.2.2 容灾演练及冬奥实践(上)
《云上大型赛事保障白皮书》——第三章 压测调优与技术演练——3.2 云上大型赛事技术演练——3.2.2 容灾演练及冬奥实践(上)
132 0
|
弹性计算 运维 监控
《云上大型赛事保障白皮书》——第三章 压测调优与技术演练——3.2 云上大型赛事技术演练——3.2.4 故障演练及冬奥实践
《云上大型赛事保障白皮书》——第三章 压测调优与技术演练——3.2 云上大型赛事技术演练——3.2.4 故障演练及冬奥实践
103 0
|
云安全 弹性计算 监控
《云上大型赛事保障白皮书》——第六章 云产品稳定性治理与风险管控——6.2 北京冬奥稳定性治理实践——6.2.5 冬奥重保--赛时每日巡检
《云上大型赛事保障白皮书》——第六章 云产品稳定性治理与风险管控——6.2 北京冬奥稳定性治理实践——6.2.5 冬奥重保--赛时每日巡检
106 0
《云上大型赛事保障白皮书》——第六章 云产品稳定性治理与风险管控——6.3 稳定性巡检总结
《云上大型赛事保障白皮书》——第六章 云产品稳定性治理与风险管控——6.3 稳定性巡检总结
《云上大型赛事保障白皮书》——第六章 云产品稳定性治理与风险管控——6.2 北京冬奥稳定性治理实践——6.2.6 冬奥重保—变更管控
《云上大型赛事保障白皮书》——第六章 云产品稳定性治理与风险管控——6.2 北京冬奥稳定性治理实践——6.2.6 冬奥重保—变更管控
《云上大型赛事保障白皮书》——第六章 云产品稳定性治理与风险管控——6.2 北京冬奥稳定性治理实践——6.2.3 冬奥重保--风险巡检(3)
《云上大型赛事保障白皮书》——第六章 云产品稳定性治理与风险管控——6.2 北京冬奥稳定性治理实践——6.2.3 冬奥重保--风险巡检(3)