问题：预发环境整体运行3天后存在kafka消息积压和微服务CPU使用率接近100%问题
一、Kafka消息滞后排查 1.1、什么是kafka消息滞后kafka消息滞后程度：指消费者当前落后于生产者的程度。
Kafka 的消息是有留存时间设置的，默认是 1 周（Kafka 默认删除 1 周前的数据）。消费者程序足够慢，慢到它要消费的数据快被 Kafka 删除了。
这可能产生两个后果：
（1）一个是消费者从头消费一遍数据；
（2）另一个是消费者从最新的消息位移处开始消费，之前没来得及消费的消息全部被跳过了，从而造成消息丢失的假象。
1.2、Lag指标监测Log指标直接反映了一个消费者的运行情况。一个正常工作的消费者，它的 Lag 值应该很小，甚至是接近于 0 的，这表示该消费者能够及时地消费生产者生产出来的消息，滞后程度很小。
如果一个消费者 Lag 值很大，通常就表明它无法跟上生产者的速度，最终 Lag 会越来越大，从而拖慢下游消息的处理速度。
Lag 的单位是消息数，监控 Lag 的层级是在分区上的。如果要计算主题级别的，你需要手动汇总所有主题分区的 Lag，将它们累加起来，合并成最终的 Lag 值。
消费进度监控3 种方法：
（1）使用 Kafka 自带的命令行工具 kafka-consumer-groups 脚本。
Kafka 自带的命令行工具 bin/kafka-consumer-groups.sh
$ bin/kafka-consumer-groups.sh --bootstrap-server--describe --group
（2）使用 Kafka Java Consumer API 编程。
略
（3）使用 Kafka 自带的 JMX 监控指标。
Kafka 消费者提供了一个名为 kafka.consumer:type=consumer-fetch-manager-metrics,client-id=“{client-id}”的 JMX 指标，里面有很多属性。例如：
records-lag-max ：最大Lag值，监控到 Lag 越来越大,消费者程序变得越来越慢了
records-lead-min：最小lead值，Lead 越来越小，甚至是快接近于 0 了,消费者端要丢消息了
用于单独监控分区级别的 Lag 和 Lead 值的JMX 名称为：kafka.consumer:type=consumer-fetch-manager-metrics,partition=“{partition}”,topic=“{topic}”,client-id=“{client-id}”
kafka消费组查看lag：如图存在kafka消息积压情况
关键微服务CPU和内存WSS存在吃紧情况：
二、问题修复后进行压力测试相关服务资源情况：
观察环境是否能够平稳运行60分钟及以上。 在配合测试在梯度压测的过程中需要观察如下指标：
1、 实时数据是否能够正常刷新。
2、 在线设备量是否与上数量一致。
3、 实际处理量是否平稳（ 观察kafka的实际消费是否平稳）。
4、 观察实时数据是否能够正常刷新。
5、 历史数据是否能够正常查询， 数据没有丢失
进行阶梯度压测，首先40个并发，每个梯度10个并发，观察 10分钟，查看环境是否运行平稳。逐渐加码80，160，320.....并发；
逐渐增加设备接入量观察设备工况上数情况，对比优化前后的不同设备量的CPU使用率、WSS使用率、kafka消费着Lag指标监测变化等。
