本文根据孙燕老师在《2019DAMS中国数据智能管理峰会》现场演讲内容整理而成。
讲师介绍
孙燕,微博广告基础运维负责人,2009年入职新浪,任职10年间参与博客、图片、视频、微博平台监控、微博广告多个产品运维,致力于运维自动化、产品架构优化、服务治理、智能监控及以监控为依托的服务容灾建设。
在上文提到的自动扩缩容体系当中,提到一个叫Oops的系统,这是微博广告运维人员建立的智能监控系统。接下来给大家简单介绍一下。
1、监控面临的挑战
说到监控,不得不说监控遇到的很多问题。
市面上有很多开源的监控软件,比如说常见的Zabbix,在监控数据量少的情况下,不管是基础监控还是业务监控,这些开源软件都是可以直接满足需求的。
但是随着监控指标的增多,加上我们的指标是实时性变化的,数据要求又比较高,这些原生软件不再满足我们需求了。另外,微博广告的业务数据有特殊性,一般运维关注的数据是系统的性能,系统的性能数据有时候来源于业务日志。
但是微博广告的业务日志是收入,很多业务日志是一条都不能丢的,比如说结算的曝光每一条曝光对于广告来说,都是真金白银,对精准性要求比较高,单独通过性能监控的日志收集方法是不能满足需求的,这也是我们面临的挑战。
另外,监控系统一般都会具备告警功能,有告警就会有告警问题,接下来会详细地介绍告警问题。还面临问题定位方面的挑战,在监控越来越完善的基础上,很多开发的操作情况发生了变化,一旦发生问题,第一个反应并不是上服务器看一下系统怎么了,而是翻监控,看看哪些监控指标发生了问题,所以监控系统会越来越多地面向于问题定位这个方向。
2、Oops整体架构面临的挑战
作为监控系统,Oops在架构上并没有什么出奇的地方,所有的监控无非就是四个阶段:从客户端进行数据采集、数据的清洗和计算、数据存储、数据展示。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
3、监控数据流向特点
所有的监控系统都逃不开这四个阶段,只是根据业务的不同进行了定制化的工作。针对广告业务的监控流向,我们把数据分成两类,有一部分精密数据的计算,我们采取的是离线分析的方式,通过采集软件将所有的日志采集到Kafka,通过计算的工具进行拆洗、计算,计算之后落存储,还有另外一个团队开发的针对于这一部分数据的页面展示化,还有一个系统叫hubble,针对精细数据的展现,实现个性化定制的展现。
另外一部分是运维比较关心的数据,今天来了多少流量?流量有多少是正常的?有多少是异常的?平均耗时是多少?针对这一部分,我们采取了实时数据计算的方法。
在数据采集阶段发生了变化,我们并不采集全量日志,而是在客户端做了预处理,进行分类计算。比如说监控数据,就按监控数据的方法计算;告警数据,就按告警数据的计算。而且按照用户读取的需求进行分类存储,保证了高并发数据的实时性。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
4、海量指标监控系统流程
接下来详细介绍实时数据计算。首先从数据采集上讲,上文提到我们不采取全量的采集方式,而是通过Agent对数据进行处理,在数据采集阶段,在数据产生的服务器上,针对不同的需求按不同的时间进行分类聚合,最终向后推送的数据是key-value、计算方法这种模式,推送给proxy。proxy拿到已经被打包的数据进行拆包,然后送给不同的计算结点,再按照key进行计算,打时间戳。
这个数据并不精准,但我们可以接受部分损失,只需要保证数据的趋势是正确的。另外,关于分类计算,不同的需求推送给不同的计算节点。存储也进行了分类,实时性要求比较强的话会直接放到内存,以最精细粒度进行存储。前三个小时的数据是按秒存的,按天计算的数据是按10秒、30秒存的,一些单机数据是按分钟存的。
另外一些历史性的数据需要出报表的,比如说要看前一周的数据,前一个月的数据,按照大数据的方式存到OpenTSDB当中。存储的数据提供一个API,通过API我们进行了分类计算、分类存储,这种分类的需求来源于用户,需要看用户有什么要求,要什么样的数据。
比如,Dashboard的展示数据会直接被放到内存里。另外,上文提到的在线扩缩容数据,会相应获取数据给用户,其他相关的获取需求API也会进行分类获取。
接下来我们计算过的数据还有一部分会存储到Redis通过WatchD作为告警中心的数据,因为告警数据一般都只要求当前数据,不会有人需要查看上个月这台机器的负载有没有告警。
所以Alert节点计算之后的数据直接存在Redis,Redis把这个数据拿出来之后经过告警中心根据告警规则进行清洗,通过各种方式推送到需求方。同时有一个相对个性化的展示叫九宫格。我们的九宫格实际上是一个结合报警功能的监控,它是一个页面,但具备了告警功能。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
接下来看一下监控图,下面三张图是范冰冰宣布分手拿到的流量,我们的反映是非常灵敏的,平均耗时也涨上来了。
第三张图是拿到这些数据之后,自动平台显示应该扩容了。蓝色跟绿色的流量线已经降下来了,大部分量调到云服务器上。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
下图是我们的九宫格,因为时效性比较强,正常来说是以产品为页面,以业务线为格子,每个格子记录的是单机的详细信息。如果在这一组服务器当中单机故障数超过一定的比例,这个格子会变颜色。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
所以在正常的运维工位上都会有这样的大屏幕,运维可以一目了然发现自己所有负责的业务线情况,而不是让一台台机器在这里展现,这样就没有办法看到业务线情况了。九宫格可以让运维更加直观地看到当前的告警情况。
5、告警
告警有很多的问题,我们遇到的问题可以分为以下四个方面:
1)告警数量巨大
运维人员需要关注所有部分,从系统到服务、接口等等,维度很多,一旦有问题,各种策略都会触发报警,报警数量多到一定程度,基本上等于没有报警。
2)重复告警率高
告警策略一般会周期性执行,一直到告警条件不被满足,如果服务一直不恢复,就会重复报下去,另外,同一个故障也可能引发不同层次的告警。
比如,我们有一个业务线叫超粉,会有360台服务器,流量高峰时360台服务器会同时发送告警,这种告警的重复率很高。
3)告警有效性不足
很多时候,网络抖动、拥堵、负载暂时过高或者变更等原因,会触发报警,但这类报警要么不再重现,要么可以自愈。
比如一个硬盘在接近80%的时候开始告警了,你让它告吗?好像得告,但似乎不告也可以。
4)告警模式粗放
无论是否重要、优先级如何,告警都通过邮件、短信、AppPUSH发送到接收人,就像暴风一样袭击着接收人,接收人没有办法从中获取到有效的信息,经常会让真正重要的告警淹没在一大堆普通告警中。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
针对这些问题,我们采取了以下措施:
1)抖动收敛
对于这种大规模服务器的维护,抖动是非常常见的现象。网络抖一抖,整个服务单元就会向你告警。
针对这种抖动,我们增加了一些策略,抖动的时候会前后比较,监测重复性,看看是不是具备告警的意义,通过增加告警策略这种方式来进行收敛。比如说流量突增的时候,需要查看是不是同单元都出现了这个情况。
2)告警的分类和分级
详细定义告警级别,发送优先级、升级策略等,可有效减少粗放模式下告警接收量。比如,一些低优先等级的告警会让它告,处理的级别会低一点。
3)同类合并
同一个原因可能会触发一个服务池里面的所有实例都报警,比如同时无法连接数据库,其实只需要报一次即可。
4)变更忽略
我们的好多变更都是在Kunkka平台上操作的,开发有时候会选中一个通知,现在是变更,告警请忽略。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
以上措施能解决告警问题中80%的问题,现在大家都在朝着更高级的方向发展,我们也简单做了一些探索。在原有告警数据流情况下引入了工具SkyLine,这个工具包含了多种算法,在异常检测环节中,能够通过它内置的算法将我们传入的数据自动去抖动,提供平滑的数据,等你再拿到这个数据时就不需要再检测是不是告警。
这个工具避免了人工操作,通过Skyline将数据进行平滑,提供一份准确的数据,我们只需要通过这份数据,进行规则判断,决定是否需要告警就好了,减少了对数据准确性判断的复杂过程。接着是根因分析部分,随着监控的覆盖面越来越广,监控精确性越来越高。
等故障出现的时候,开发人员就会去翻监控图,去查看大概是哪些原因导致了故障。随着Dashboard越来越多,即便是经验非常丰富的工作人员也很难快速地定位到原因会出现哪个方面、该去去看哪张个监控图。
出现流量突增的情况时,Skyline会通过内部的算法Luminosity寻找相似的情况,查看相同的时间内是否有其他地方出现流量异常,并将根源问题展示在TOPN上,这样就能够快速查看在故障出现的前后哪些业务也出现了流量变化,方便对故障原因进行分析和定位。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
还有一项非常重要的工作——服务治理,这里只进行简单的介绍。
1、为什么需要服务治理
微博广告现阶段所出现的问题主要有:架构越来越复杂,上文提到微博广告的服务器已经达到3000台,所以在这种服务器数量情况下,架构会越来越复杂,稳定性要求也变得非常高;开发的多语言环境对上线发布也造成了挑战;资源使用是否合理性,对运维来说也是一个挑战。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
2、低成本和高可用的平衡
针对这些问题,我们进行了低成本和高可用的平衡,争取用最小的服务器达到最稳定的架构。在保证服务稳定的情况下,将流量进行均分,分到最小服务单元三机房部署为基本规则,保障在一个机房挂掉的情况下,另外2/3的服务器能承载全部的流量。
关于上下游之间调用的平衡,尽量减少跨运营商的调用,微博广告每一毫秒的消耗都会影响到收入。我们的请求时间是1毫秒、1毫秒地优化下来的,这些损耗产生在网络和服务器上,很难通过人力弥补,因此在这方面我们也非常谨慎。
另外,小功能会抽象出功能的共同点,将这些功能服务化,服务则按单元化部署。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
3、服务发现及负载均衡
在服务治理过程中,我们会根据服务的引入服务自动发现,尽量减少服务变更环节的人工干预,提高安全性和实时性,自建负载均衡会有标准的数据输入和数据发布的过程,可以大大提升后期的可扩展性和可用性。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
4、服务治理成绩
经过近半年的服务治理,我们达到了这样的成绩:
架构更加强健,容灾能力提高;
系统、数据、配置标准化;
服务器的合理使用,成本控制。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
其中,我觉得最重要的是系统、数据、配置标准化的过程。
今天好多分享的嘉宾也提到了AIops,这些上层的建设都是依赖于整个业务标准化的过程,中国有句古话,工欲善其事,必先利其器,我们所有的标准化过程就是为下一步人工智能打下坚实的基础,希望我们的工作能够以技术保证微博系统稳定,助力微博广告的收入。