LBS-监控系统

1.应用背景

在LBS向外界提供服务的过程中，我们不仅需要实时监控服务运行状态，而且需要在报错时快速定位问题。所以采用适当的方法实时整理埋点数据--记录日志与QPS等信息就显得尤为重要，QPS信息用于监控服务状态，日志信息用于快速定位问题。在流处理场景，数据源源不断地流入系统，大数据框架对数据的处理越快越好、能处理的数据量越大越好，延迟和吞吐是衡量流处理框架最重要的指标。监控系统主要应用于实时场景，所以对低延迟的要求尤为严格，这是选择流数据场景下延迟在毫秒级别的Flink框架最重要的原因。

2.监控系统架构

Kafka是一个高吞吐的分布式消息系统，利用它解耦的特性解除与LBS服务本身的耦合程度，利用它削峰填谷的特性消解流量洪峰、更高效地利用计算资源，利用它支持流式数据处理的特性更方便的与Flink框架整合。

Flink是一个支持在有界和无界数据流上做有状态计算的大数据处理框架，具有低延迟、高吞吐、高准确性的特性。相比Spark Streaming对流数据切分成多个批次（mini-batch），Flink以事件为单位，达到了真正意义上的实时计算，且所需计算资源相对更少。

以下简述本监控系统的上下文：客户端请求LBS服务，服务过程中产生的埋点信息写入Kafka，接着由Flink任务消费Kafka消息，做解析、过滤、转换、整合的处理得到日志数据与QPS数据，其中日志信息写入ES，QPS信息写入OpenTSDB。最后，用户通过自定义查询条件传入LBS后台来监控、回溯LBS服务的健康情况。下图为本监控系统的上下游的数据流图：

3.风险点

问题1：LBS后台监控延迟

问题描述

在2021中秋、国庆的流量高峰时，埋点信息大量增加导致监控延迟；2021.10.08流量和往常一样，远低于国庆时流量，但仍出现长时间（2h以上）延迟。

排错过程

1.排查上游，查看消费Kafka消息是否出现延迟

（1）分析思路

于是查看Kafka本身的监控平台，发现消费滞后量（lag）在严重期达到两千万条以上，lag的含义是消息中间件服务端中所留存的消息与消费掉的消息之间的差值。而Topic的分区数为24、发送消息的TPS为20000，则Lag为20000000持续1s所造成的延迟为 20000000/20000/24 = 44s。而Lag为两千万的实际持续时间远超过1s。

在09.28晚高峰，lag数量又出现了拉升，分析下来“当前时刻在消费二十分钟前的数据”。

（2）采取措施

Flink作业Source端并行度设置原则：假设数据源端是Kafka，作业source处并行度 <= Kafka Topic分区数，过多不起作用。如果Topic数据消费不及时，建议梳理一下看是否要扩容 Kafka Topic的分区数量。

于是扩容Topic的分区数，从24扩容到40。同时将Flink作业source的并行度由24调整为40，与Kafka的Topic的分区数保持一致，且tansforamtion算子的并行度从20调整为240。

（3）效果回收

09.29、09.30国庆高峰外、10.01-10.07均无延迟，国庆高峰出现三十分钟左右延迟，持续到高峰结束。

（4）问题重现

10.08重新出现延迟。

2.排查下游，定位反压节点

（1）分析思路

观察Flink Web UI界面，发现作业出现反压，下图为本作业的反压面板：

反压（backpressure）是实时计算应用开发中，特别是流式计算中，十分常见的问题。反压意味着数据管道中某个节点成为瓶颈，处理速率跟不上上游发送数据的速率，而对上游进行限速。由于实时计算应用通常使用消息队列来进行生产端和消费端的解耦，消费端数据源是 pull-based 的，所以反压通常是从某个节点传导至数据源并降低数据源的摄入速率。

反压并不会直接影响作业的可用性，它表明作业处于亚健康的状态，有潜在的性能瓶颈并可能导致更大的数据处理延迟。

如果处于反压状态，那么有两种可能性：

a.该节点的发送速率跟不上它的产生数据速率，这一般会发生在一条输入多条输出的operator（比如 flatmap）

b.下游的节点接受速率较慢，通过反压机制限制了该节点的发送速率

需要注意的是，反压的根源节点并不一定会在反压面板体现出高反压。如果某个节点是性能瓶颈并不会导致它本身出现高反压，而是导致它的上游出现高反压。总体来看，如果我们找到第一个出现反压的节点，那么反压根源要么就是这个节点，要么是它紧接着的下游节点。

我们以上游一个组件、下游一个组件这种最简单的情况来描述反压过程，这里暂时不讨论具体的反压机制。简单来说，下游节点写入速率受限，向上传导，抑制上游接受数据的速率，同时Flink向下游发送数据的速率相应被抑制。

而本作业有两个下游组件，分别是ES和OpenTSDB。假设其中一个组件的写入性能到达瓶颈后，向上抑制上游接受数据速率和处理数据速率，进而影响到下游另一个组件。也就是说，下游两个组件里任意一个写入压力大，都会影响到另一个组件的写入速度。

查看HelloSearchMonitorElasticsearch集群Grafana监控，发现10.08下午16:00开始aibran-monitor-logs这个索引的写入量比之前高很多，一度达到了2.7TB，时间点也与监控系统延迟时间吻合。相关人员解释说，这个索引的开发同学新加了写入字段导致的数据量飙升，集群负载日常就很高，假如某些索引写入负载很高，会影响同一集群下的其他索引写入性能。

于是定位到ES组件写入性能受限。

（2）采取措施

更换消费者，原来是hello_search_lbs，改为hello_map_lbs；

配置文件中添加配置项，用于控制是否写入某个下游组件，相应地修改代码结构。控制只写入OpenTSDB，联系负载大的索引的开发同学删除了新加字段，10.13观察HelloSearchMonitorElasticsearch集群的负载情况，如果资源允许则开放sink到ES组件。

10.14上午11:30添加sink到ES，延迟状况仍然存在。王新荣扩容两台机器，并把lbs-request-log索引和高负载的索引独立开，将lbs-request-log部署到新节点。

（3）效果回收

10.12下午14:30 OpenTSDB组件恢复正常，监控系统部分恢复正常，持续观察。

10.14下午17:00 ES组件恢复正常，监控系统全部恢复正常，持续观察。

小结

本次排错过程中，对Flink框架不熟悉导致走了很多弯路、花费了许多时间。排错过程不一帆风顺，最困难的地方是定位不到错误原因。一开始以为是消费Kafka延迟，扩容分区数后没有明显改善；以为是idc机房带宽被占满，切换到云上部署没有改善；以为是OpenTSDB写入压力大，修改代码只写入ES也没有改善。下次排错时，先花时间把不熟悉的地方搞清楚，这样反而排错更顺利一些。