微博广告系统全景运维大法( 四 ) _微博

之前做过演练，但不会拿几千台云服务器进行扩容，可能几十台确保功能可用就可以了，到时候要让负载均衡的同事通过配置文件增加下 Memeber 就可以。
如果上千台的服务器没有办法增加到负载均衡设备，那个时候大家手忙脚乱，最后通过手动的方式扩容节点。
大家知道春晚的流量高峰很短，但那天确实给了我们当头一棒。接下来我们在扩容演练过程中，不仅会对负载均衡进行确认，还会对我们依赖的服务进行确认。
比如每次发生热点事件时，大家会说微博又崩了，评论又崩了，热搜出不来了。
其实应对峰值流量是件很头大的事情，我把事情解决了，兄弟部门没有解决，兄弟部门解决了，姐妹部门又出现了问题。
安全限制：618 大促时，京东的同学分享了在扩容的时候新增的服务器 IP 与 VIP 发生了冲突，而微博主要的体现就是数据库会对很多业务的请求设置白名单，可是云服务器扩容之后 IP 是随机的。
另外，新浪对于通行证有很多 IP 限制，所以我们通过扩容演练体系不断发现各个环节中的问题，加以解决，保证在扩容动作进行时能够顺利地完成，保证扩容出来的云主机真正安全上线服务。
有了这个系统的加持，截止到现在自动扩容服务都处于比较稳定的状态。
智能监控
在上文提到的自动扩缩容体系当中，提到一个叫 Oops 的系统，这是微博广告运维人员建立的智能监控系统，接下来给大家简单介绍一下。
监控面临的挑战

文章插图
说到监控，不得不说监控遇到的很多问题。市面上有很多开源的监控软件，比如说常见的 Zabbix ，在监控数据量少的情况下，不管是基础监控还是业务监控，这些开源软件都是可以直接满足需求的。
但是随着监控指标的增多，加上我们的指标是实时性变化的，数据要求又比较高，这些原生软件不再满足我们需求了。
另外，微博广告的业务数据有特殊性，一般运维关注的数据是系统的性能，系统的性能数据有时候来源于业务日志。
但是微博广告的业务日志是收入，很多业务日志是一条都不能丢的，比如说结算的曝光。
每一条曝光对于广告来说，都是真金白银，对精准性要求比较高，单独通过性能监控的日志收集方法是不能满足需求的，这也是我们面临的挑战。
另外，监控系统一般都会具备告警功能，有告警就会有告警问题，接下来会详细地介绍告警问题。
还面临定位方面的挑战，在监控越来越完善的基础上，很多开发的操作情况发生了变化。
一旦发生问题，第一个反应并不是上服务器看一下系统怎么了，而是翻监控，看看哪些监控指标发生了问题，所以监控系统会越来越多地面向于问题定位这个方向。
Oops 整体架构面临的挑战

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

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

监控数据流向特点

文章插图
所有的监控系统都逃不开这四个阶段，只是根据业务的不同进行了定制化的工作。
针对广告业务的监控流向，我们把数据分成两类，有一部分精密数据的计算，我们采取的是离线分析的方式，通过采集软件将所有的日志采集到 Kafka ，通过计算的工具进行拆洗、计算，计算之后落存储。
还有另外一个团队开发的针对于这一部分数据的页面展示化，还有一个系统叫 Hubble ，针对精细数据的展现，实现个性化定制的展现。