支持百亿请求的微博广告运维技术实践(4)

▲ 图2-12 业务查询

三、海量指标监控平台Oops实践

最后我们看下我们如何应对微博广告海量指标数据下多维的监控需求。前文也说了，监控报警就像我们的眼睛，能够让我们实时的看到我们系统内部的运行情况，因此，每一个服务都应该有一些关键指标通过我们的监控报警系统展示出来，实时反馈系统的健康状态。

如图3-1所示，做一个监控平台很容易，我们将指标、日志等数据进行ETL清洗后写入一个时序数据库中，再通过可视化工具展示出来，对于有问题的指标通过邮件或者微信的方式报警出来。但是在这个过程中，随着我们数据量的增长、我们指标的增长以及查询复杂度的增加，我们可能会遇到监控指标延迟、数据偏差以及系统不稳定等问题。

▲ 图3-1 监控平台的挑战

因此，在设计我们的监控系统时，就不能仅仅基于实现考虑，还需要考虑它的稳定性、实施性、准确性，同时还应尽量把系统做的简单易用。

▲ 图3-2 监控平台的目标

而我们目前的监控平台Oops，也是基于上述原则，经历了多年的迭代和考验。图3-3是我们Oops监控平台当前的整体架构。

▲ 图3-3 Oops监控平台架构

① 数据采集

整个平台分为四个层次，首先是我们的数据采集。我们当前主要通过Filebeat这样一款优秀的开源采集客户端来采集我们的日志。对我们使用而言，Filebeat足够的高效、轻量，使用起来也很灵活易用。

▲ 图3-4 Filebeat架构图

② 指标清洗

数据采集到Kafka后，我们再根据具体的业务需求将指标提取出来。如图3-5所示，当前我们主要通过Flink来解析日志，并写入ClickHouse中。

（编辑：ASP站长网）