3000台服务器不宕机，微博广告系统全景运维大法

微博现在日活达到了 2 亿，微博广告是微博最重要且稳定的收入来源，没有之一，所以微博广告系统的稳定性是我们广告运维所有工作中的重中之重。

这样的自动化运维平台基本上满足了运维的日常操作需求，在 Kunkka 平台中还有自动扩缩容的功能，我们针对这个功能进行延伸。

在自动扩所容的基础上，根据时间段，流量进行动态判断，自动决策的扩所容够功能。

弹性计算

为什么需要弹性计算

首先简单介绍一下弹性计算的架构，弹性计算依托于 Kunkka 自动化运维平台，以及 Oops 监控平台，在业务压测的情况下获取业务指标监控，将数据送到容量决策系统，做出是否扩缩容的决定。

在云服务商方面，我们常用阿里云、华为云跟一部分自建的私有云。DCP 混合平台是我们微博另外一个团队做了几年的平台，它能够对接云服务，快速生成

现在拿到了一个非常重要的容量值及消耗比来进行容量评估，用于描述当前的容量消耗情况。

拿到这个消耗比之后是不是就可以扩容了?还是可以缩容了?此处还需要一个评估标准，是 30% 就扩?还是 50% 再扩?

我们基于历史数据给予分析，制定了三条水位线，包括安全线、警戒线和致命线，拿当前消耗值与水位线进行对比，在不同阶段采取不同的措施。

比如，现在的消耗度远远低于安全线，说明现在服务器部署有冗余，我们可以进行逐步的缩容。

如果说现在已经高于致命线，则需要扩容，让这个值更加接近安全线，保证系统的稳定性。

⑤在线容量评估体系

前面进行的数据采集、计算，以及动作的串联，都是为了完成最后一个目标，服务扩容成功。

真正的服务器扩容到线上之后，怎么样才能保证服务是健康可用的呢?我们还有另外一套辅助系统叫扩容演练。在实时演练过程中，要注意以下几点：

部署效率：我们通过扩容演练来寻找整个扩容过程中的瓶颈，比如，我们下发是通过 DCP 对接云服务商来完成扩容的。

在真正的线上扩容过程中，DCP 有时要同时承载几千台节点的扩容并发。DCP 的效率是否能够满足?在扩容演练过程中需要确认这一点。

带宽限制：微博和云服务商之间确实是拉了专线，但是微博和云服务商不只是微博广告的一个业务，还有很多其他大户。

而且一般在流量增加的时候他们的扩容也是非常猛烈的，所以带宽是否可用，也是我们在日常演练过程中非常注意的现象。

依赖服务：这方面有很多案例，在这里简单分享一下，2015 年春节，自动扩缩容的流程才刚刚开始，春节当天晚上我们扩容完几千个节点后，忽然发现负载均衡加不上去。

说到监控，不得不说监控遇到的很多问题。市面上有很多开源的监控软件，比如说常见的 Zabbix，在监控数据量少的情况下，不管是基础监控还是业务监控，这些开源软件都是可以直接满足需求的。

但是随着监控指标的增多，加上我们的指标是实时性变化的，数据要求又比较高，这些原生软件不再满足我们需求了。

另外，微博广告的业务数据有特殊性，一般运维关注的数据是系统的性能，系统的性能数据有时候来源于业务日志。

但是微博广告的业务日志是收入，很多业务日志是一条都不能丢的，比如说结算的曝光。

每一条曝光对于广告来说，都是真金白银，对精准性要求比较高，单独通过性能监控的日志收集方法是不能满足需求的，这也是我们面临的挑战。

另外，监控系统一般都会具备告警功能，有告警就会有告警问题，接下来会详细地介绍告警问题。

还面临定位方面的挑战，在监控越来越完善的基础上，很多开发的操作情况发生了变化。

一旦发生问题，第一个反应并不是上服务器看一下系统怎么了，而是翻监控，看看哪些监控指标发生了问题，所以监控系统会越来越多地面向于问题定位这个方向。

Oops 整体架构面临的挑战

作为监控系统，Oops 在架构上并没有什么出奇的地方，所有的监控无非就是四个阶段：

• 从客户端进行数据采集
• 数据的清洗和计算
• 数据存储
• 数据展示

监控数据流向特点

所有的监控系统都逃不开这四个阶段，只是根据业务的不同进行了定制化的工作。

针对广告业务的监控流向，我们把数据分成两类，有一部分精密数据的计算，我们采取的是离线分析的方式，通过采集软件将所有的日志采集到 Kafka，通过计算的工具进行拆洗、计算，计算之后落存储。

还有另外一个团队开发的针对于这一部分数据的页面展示化，还有一个系统叫 Hubble，针对精细数据的展现，实现个性化定制的展现。

另外一部分是运维比较关心的数据，今天来了多少流量?流量有多少是正常的?有多少是异常的?平均耗时是多少?针对这一部分，我们采取了实时数据计算的方法。

在数据采集阶段发生了变化，我们并不采集全量日志，而是在客户端做了预处理，进行分类计算。

比如说监控数据，就按监控数据的方法计算;告警数据，就按告警数据的计算。而且按照用户读取的需求进行分类存储，保证了高并发数据的实时性。

海量指标监控系统流程

接下来详细介绍实时数据计算。

首先从数据采集上讲，上文提到我们不采取全量的采集方式，而是通过 Agent 对数据进行处理。

在数据采集阶段，在数据产生的服务器上，针对不同的需求按不同的时间进行分类聚合，最终向后推送的数据是 key-value、计算方法这种模式，推送给 Proxy。

Proxy 拿到已经被打包的数据进行拆包，然后送给不同的计算结点，再按照 Key 进行计算，打时间戳。

这个数据并不精准，但我们可以接受部分损失，只需要保证数据的趋势是正确的。

另外，关于分类计算，不同的需求推送给不同的计算节点。存储也进行了分类，实时性要求比较强的话会直接放到内存，以最精细粒度进行存储。

前三个小时的数据是按秒存的，按天计算的数据是按 10 秒、30 秒存的，一些单机数据是按分钟存的。

另外一些历史性的数据需要出报表的，比如说要看前一周的数据，前一个月的数据，按照大数据的方式存到 OpenTSDB 当中。

存储的数据提供一个 API，通过 API 我们进行了分类计算、分类存储，这种分类的需求来源于用户，需要看用户有什么要求，要什么样的数据。

比如，Dashboard 的展示数据会直接被放到内存里。另外，上文提到的在线扩缩容数据，会相应获取数据给用户，其他相关的获取需求 API 也会进行分类获取。

接下来我们计算过的数据还有一部分会存储到 Redis 通过 WatchD 作为告警中心的数据，因为告警数据一般都只要求当前数据，不会有人需要查看上个月这台机器的负载有没有告警。

所以 Alert 节点计算之后的数据直接存在 Redis，Redis 把这个数据拿出来之后经过告警中心根据告警规则进行清洗，通过各种方式推送到需求方。

同时有一个相对个性化的展示叫九宫格。我们的九宫格实际上是一个结合报警功能的监控，它是一个页面，但具备了告警功能。

接下来看一下监控图，下面三张图是范冰冰宣布分手拿到的流量，我们的反映是非常灵敏的，平均耗时也涨上来了。

第三张图是拿到这些数据之后，自动平台显示应该扩容了。蓝色跟绿色的流量线已经降下来了，大部分量调到

下图是我们的九宫格，因为时效性比较强，正常来说是以产品为页面，以业务线为格子，每个格子记录的是单机的详细信息。

如果在这一组服务器当中单机故障数超过一定的比例，这个格子会变颜色。

所以在正常的运维工位上都会有这样的大屏幕，运维可以一目了然发现自己所有负责的业务线情况，而不是让一台台机器在这里展现，这样就没有办法看到业务线情况了。九宫格可以让运维更加直观地看到当前的告警情况。

告警

告警有很多的问题，我们遇到的问题可以分为以下四个方面：

①告警数量巨大

运维人员需要关注所有部分，从系统到服务、接口等等，维度很多，一旦有问题，各种策略都会触发报警，报警数量多到一定程度，基本上等于没有报警。

②重复告警率高

告警策略一般会周期性执行，一直到告警条件不被满足，如果服务一直不恢复，就会重复报下去，另外，同一个故障也可能引发不同层次的告警。

比如，我们有一个业务线叫超粉，会有 360 台服务器，流量高峰时 360 台服务器会同时发送告警，这种告警的重复率很高。

③告警有效性不足

很多时候，网络抖动、拥堵、负载暂时过高或者变更等原因，会触发报警，但这类报警要么不再重现，要么可以自愈。

比如一个硬盘在接近 80% 的时候开始告警了，你让它告吗?好像得告，但似乎不告也可以。

④告警模式粗放

无论是否重要、优先级如何，告警都通过邮件、短信、App PUSH 发送到接收人，就像暴风一样袭击着接收人，接收人没有办法从中获取到有效的信息，经常会让真正重要的告警淹没在一大堆普通告警中。

针对这些问题，我们采取了以下措施：

①抖动收敛

对于这种大规模服务器的维护，抖动是非常常见的现象。网络抖一抖，整个服务单元就会向你告警。

针对这种抖动，我们增加了一些策略，抖动的时候会前后比较，监测重复性，看看是不是具备告警的意义，通过增加告警策略这种方式来进行收敛。

比如说流量突增的时候，需要查看是不是同单元都出现了这个情况。

②告警的分类和分级

详细定义告警级别，发送优先级、升级策略等，可有效减少粗放模式下告警接收量。比如，一些低优先等级的告警会让它告，处理的级别会低一点。

③同类合并

同一个原因可能会触发一个服务池里面的所有实例都报警，比如同时无法连接数据库，其实只需要报一次即可。

④变更忽略

我们的好多变更都是在 Kunkka 平台上操作的，开发有时候会选中一个通知，现在是变更，告警请忽略。

以上措施能解决告警问题中 80% 的问题，现在大家都在朝着更高级的方向发展，我们也简单做了一些探索。

在原有告警数据流情况下引入了工具 SkyLine，这个工具包含了多种算法，在异常检测环节中，能够通过它内置的算法将我们传入的数据自动去抖动，提供平滑的数据，等你再拿到这个数据时就不需要再检测是不是告警。

这个工具避免了人工操作，通过 Skyline 将数据进行平滑，提供一份准确的数据，我们只需要通过这份数据，进行规则判断，决定是否需要告警就好了，减少了对数据准确性判断的复杂过程。

接着是根因分析部分，随着监控的覆盖面越来越广，监控精确性越来越高。

等故障出现的时候，开发人员就会去翻监控图，去查看大概是哪些原因导致了故障。

随着 Dashboard 越来越多，即便是经验非常丰富的工作人员也很难快速地定位到原因会出现哪个方面、该去看哪张监控图。

出现流量突增的情况时，Skyline 会通过内部的算法 Luminosity 寻找相似的情况，查看相同的时间内是否有其他地方出现流量异常，并将根源问题展示在 TOPN 上。

这样就能够快速查看在故障出现的前后哪些

本文标题：3000台服务器不宕机，微博广告系统全景运维大法
网页网址：https://www.cdcxhl.com/news40/97690.html

成都网站建设公司_创新互联，为您提供网站营销、手机网站建设、响应式网站、网站排名、企业网站制作、网站导航

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联