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

这里主要想说下我们在做报警的一些想法。比如我们经常遇到的一个问题就是报警邮件狂轰滥炸，每天能收到成百上千的报警邮件，这样很容易让系统中一些重要的报警信息石沉大海。对此，我们主要以下三个方面来考虑：

质疑需求的合理性

报警聚合

追踪溯源

首先，在业务方提出报警需求的时候，我们就需要学会质疑他们的需求，因为并不是每个需求都是合理的，其实很多开发他们并不懂报警，也不知道如果去监控自己的服务。这时候就是发挥我们运维人员的价值了。我们可以在充分了解服务架构属性的前提下提出我们的意见，和开发人员共同确定每个服务需要报警的关键指标。

其次，我们可以对报警做预聚合。现在我们的服务大都都是多机部署的，一个服务有可能部署到成百上千台机器上。有时候因为人为失误或者上线策略等原因，可能导致该服务集体下线，这时就会有成百上千来自不同主机的相同报警信息发送过来。

对于这种场景，我们可以通过报警聚合的方式，将一段时间内相同的报警合并成一条信息，放在一封邮件里面发送给开发人员，从而避免邮件轰炸的情况发生。关于报警聚合，像Prometheus这样的报警系统自身已经支持，所以也不会有太多的开发量。

最后，再高层次，我们就可以通过一些策略、算法去关联我们的报警。很多时候，一条服务链路上的某个环节出现问题可能导致整条链路上的多个服务都触发了报警，这个时候，我们就可以通过服务与服务之间的相关性，上下游关系，通过一些依赖、算法等措施去屏蔽关联的报警点，只对问题的根因进行报警，从而减少报警触发的数量。

图2-9是我们运维团队17年优化报警期间，报警数量的走势。

▲ 图2-9 有效的报警

4、全链路Trace系统

除了添加报警以外，在服务上线后，我们还会经常需要跟踪我们整个服务链路处理请求的性能指标需求。这时就需要有一套全链路的Trace系统来方便我们实时监控我们系统链路，及时排查问题，定位问题。

在全链路Trace系统中，最重要的就是Traceid，它需要贯穿整个链路，我们再通过Traceid来关联所有的日志，从而跟踪一条请求在整个系统链路上的指标行为。图2-10是我们约定的用于全链路Trace的日志格式信息。

▲ 图2-10 日志格式与解析

有了日志后，我们就可以基于这些日志进行分析关联，就像上面说的，Traceid是我们整个系统的核心，我们通过Traceid来关联所有的日志。如图2-11所示，所有的日志会写入Kafka中，并通过Flink进行实时的日志解析处理，写入ClickHouse中。有了这些关键指标数据后，我们就可以在此基础上去做我们想做的事，比如形成服务拓扑进行请求跟踪、日志的检索以及指标的统计分析等。

▲ 图2-11 数据收集与处理

在所有的数据收集解析完成后，业务方就可以根据一些维度，比如UID，来跟踪用户的在整个广告系统中请求处理情况，如图2-12所示。随后再将查询的数据以Traceid维度进行关联展示给用户。

（编辑：ASP站长网）