日志中心现有架构下的优化方案记录

一、优化方向：

有五个方向：flink、elasticsearch、kafka、主机、数据过滤和代码；

• Flink：

完整优化方案可以查看：大数据—— Flink 的优化_Vicky_Tang的博客-CSDN博客_flink优化。

以下是我们实际在用的优化方法归纳。

Job：

这一方向一般由管理侧（如paas）进行优化，例如：

（1）把JobManager的jvm上限从1G提升到3G。在22年9月中旬的优化中，对运行稳定性效果的提升明显，峰值jvm占用比从98.6%降低到45%，压测不再出现job因内存问题卡掉的情况；

（2）采用hdfs进行数据存储。生产环境已经采用，对照组是测试环境的独立集群，负载能力和容错能力远远超过测试环境的集群，且可能动态调整性能使用，例如slot的使用量；

（3）对log4j的日志做滚动处理。目的是缩减flink日志对大小，减少日志对磁盘的影响，便于日志的查询和检出。百度有较多的例子，目前应用在测试环境独立集群，在生产环境则由yarn进行管理和优化；

（4）增加多个集群，分离不同jar的job。分离jar到不同集群中，一个jar对应一个集群，一个集群对应一组job。这是一种冗余模式，避免一个job异常导致其他job挂起。同时，由于软件和系统机制的制约，一套flink集群并不能真正分配到足量的cpu和内存资源，多一套集群也可以进一步使用剩余系统资源。目前apm-job和小并发度日志中心job在一套1Gjvm集群，两个大并发度写入es的日志中心job在另一套3Gjvm集群。

Task：

这一方向一般由应用侧（如csd）进行优化，例如：

1. 合理增减并发度：在Submit页面中，对job执行语句（启动脚本）里对parallellism进行控制，上游读入kafka数据的job减少并发度到5，中游进行格式分配和预处理的job减少并发度到5，下游写数据到es里的job增加并发度到80。目前可以承受每分钟100万条日志数量写入而背压仅有100万，平均每分钟不到50万的日志数量写入的情况下，平均背压不足20万条；
2. 检查点时限延长：数据量越大，则检查点备份时间越长；检查点越多，存储的文件就越多。为了避免本可以备份完成的checkpoint因为时间不足而重启，应延长checkpoint的最大耗时限制，目前是90s，未出现checkpoint异常；数量也较为合适，没有出现较大的checkpoint磁盘占用；
3. 启动脚本优化：可以把jar上传到含有flink客户端的主机上，以命令行而不是界面submit提交。执行的命令行中对-yjm MEM（JobManager 内存）、-yn NUM（ TaskManager 个数）、-ys NUM（TaskManager Slot）和-ytm MEM（TaskManager 内存）直接指定，根据现场的实际资源配额进行配置。优势是动态调优，不需要重启flink或yarn集群。珠江数码现场因为参数限制现在未启用。

• ElasticSearch：

包含了elasticsearch.yml、jvm.options和索引属性。

Elasticsearch.yml

优化空间较小，一般就是要集群，多配置几台主机几个节点，增强负载能力和容量。

Jvm.options

主要优化的阵地，包含的优化配置内容，按照优先级排序如下：最大和最小使用内存、垃圾回收器和垃圾回收器日志。

1. 最大和最小使用内存：内存不够，再好的代码也玩不转。当前es集群主机内存为64G，按照官网所说，理论最大es内存应为32G，但是实际配置40G后发现也是可以用的。

-Xms40g

-Xmx40g

1. 垃圾回收器：垃圾回收器不要再使用默认的了。## GC configuration下的三行都得屏蔽了，换成下面的配置语句。采用新的GC处理器后，效率飞速提升，直接指标就是kafka消费者的lag从一亿降低到二十万！大部分的es写入瓶颈其实都在这里，小数量级写入可能看不出来，但是大批量数据真的非换不可。

-XX:+UseG1GC

# full gc效率更高

-XX:+ExplicitGCInvokesConcurrent

-XX:+UseGCOverheadLimit

# 启动并发GC周期时的堆内存占用百分比.

-XX:InitiatingHeapOccupancyPercent=40

# 指定STW工作线程的数量

-XX:ParallelGCThreads=20

# 标记线程的数量

-XX:ConcGCThreads=8

# G1为分配担保预留的空间比例 默认10%

-XX:G1ReservePercent=15

# 表示每次GC最大的停顿毫秒数，默认200，减少该值会增加系统load。

-XX:MaxGCPauseMillis=100

1. 垃圾回收器日志：现场使用了JDK8，所以我们要对8下的配置进行优化，主要就是限制gc的滚动日志量，减少对磁盘的影响，但不能忽略日志，以免缺失异常分析。

## JDK 8 GC logging

8:-XX:+PrintGCDetails

8:-XX:+PrintGCDateStamps

8:-XX:+PrintTenuringDistribution

8:-XX:+PrintGCApplicationStoppedTime

8:-Xloggc:logs/gc.log

8:-XX:+UseGCLogFileRotation

8:-XX:NumberOfGCLogFiles=32

8:-XX:GCLogFileSize=64m

（4）配置内存熔断机制：现场对内存熔断的限制是98%，但效果不明显，暂不推荐。

索引属性

1. 减少shards数量：比较好理解，shards越多，查询越卡，写入受影响，重启也非常慢。一般通过减少索引生成数量实现，现场的shards上限是每个节点20000个。超过上限，就会无法生成新索引。
2. 减少索引数量：原理同上，效果也是显而易见的，修改索引的生成策略由小时变成天之后，每天减少了23个索引，shards的数量下降了。以前可能半个月就要删除索引，释放出shards的空间，现在运行两个月shards都不会满。
3. 减少备份数量：默认是1，日志不需要长期存储和查阅，设置为0也是可以的。
4. 适当增加字段上限：调用链日志的出入参往往会有大量的字段，根据实际情况提升字段上线对查询可能有帮助，建议以5000为宜。

• Kafka:

1. 适当增加分片数量：目前现场是2分片，是kafka本身的最低配置要求，足以满足使用。
2. 适当增加备份数量：目前现场是1备份，是kafka本身的最低配置要求，足以满足使用。
3. 数据存留时间：现场原先保留7天，现在只保留4天，理论上保留24个小时足够了。如果主机资源富裕，那么这个配置不优化也不要紧。

log.retention.hours=96

1. 消息相关配置：解释就不贴出来了，按照需要修改，现场用默认的问题不大。

log.segment.bytes=1073741824

queued.max.requests=20000

message.max.bytes=20971520

replica.fetch.max.bytes=20971520

socket.send.buffer.bytes=10485760

socket.receive.buffer.bytes=10485760

socket.request.max.bytes=104857600

num.network.threads=49

• 主机:

中间件flink、redis、kafka和mysql均在同一套三台主机上，CPU总数100C，256G内存，2T的磁盘。

ElasticSearch在24-26的一天三台主机上，64G内存，30T的磁盘。

优化方向应当是给flink、redis和kafka分离出至少三台同配置主机，并保证100C能够只服务于中间件。

• 数据过滤：

Log4j配置文件：

业务侧将日志级别限制为error，仅查看error日志则日志数量会较少，压力大大减轻。

日志格式配置：

日志格式配置中，包含过滤方法，要业务侧给出过滤规则，屏蔽一些不需要的日志，减少日志的同时，提升日志可用性和命中率。

• 代码：

配置文件：

1. 时间窗口设置：目前的时间窗口设置为60s，也就是1分钟为一次flink批量任务的执行周期，对于写入的压力较小，背压问题较轻。各个现场可以根据实际情况，进行适应性调整；
2. ES索引生成策略：目的是将小时索引减少为日索引。

 flink的job启动语句中加入：-isDayStore true

1. Kafka索引生产策略：增加同类topic，减小一个通道的压力，提升消费效率。

topic.splitcount = {"logfmt-019":2,"logbad":3}

代码内部：

1. 批量提交写入：使用bulk提交日志到es，每个时间窗口提交一批bulk，已使用，效果较好；
2. 程序分离：把一个job处理一个分析事件，拆分出多个环节由多个job处理。读原始日志一个job、预处理格式化一个job、调用链预处理一个job、处理并写入一个job。有效减轻job的压力，可以在不同环节针对其数据流量的不同，采取不同的减压手段。