Flume优化和进程监控

Flume优化和进程监控。

1.Flume优化

调整Flume进程的内存大小，建议设置1G-2G，太小的话会导致频繁GC。因为Flume进程也是基于Java的，所以就涉及到进程的内存设置，一般建议启动的单个Flume进程(或者说单个Agent)内存设置为1G~2G，内存太小的话会频繁GC，影响Agent的执行效率。

那具体设置多少合适呢？这个需求需要根据Agent读取的数据量的大小和速度有关系，所以需要具体情况具体分析，当Flume的Agent启动之后，对应就会启动一个进程，我们可以通过jstat -gcutil PID 1000来看看这个进程GC的信息，每一秒钟刷新一次，如果GC次数增长过快，说明内存不够用。

使用jps查看目前启动flume进程。

[root@master flume]# jps
3397 Jps
3261 Application

执行jstat -gcutil 3261 1000

[root@master ~]# jstat -gcutil 3261 1000
S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   
100.00   0.00  17.54  42.80  96.46  92.38      8    0.029     0    0.000    0.029
100.00   0.00  17.54  42.80  96.46  92.38      8    0.029     0    0.000    0.029
100.00   0.00  17.54  42.80  96.46  92.38      8    0.029     0    0.000    0.029
100.00   0.00  17.54  42.80  96.46  92.38      8    0.029     0    0.000    0.029
100.00   0.00  17.54  42.80  96.46  92.38      8    0.029     0    0.000    0.029
100.00   0.00  17.54  42.80  96.46  92.38      8    0.029     0    0.000    0.029
100.00   0.00  17.54  42.80  96.46  92.38      8    0.029     0    0.000    0.029
100.00   0.00  17.54  42.80  96.46  92.38      8    0.029     0    0.000    0.029

在这里主要看YGC YGCT FGC FGCT GCT

YGC：表示新生代堆内存GC的次数，如果每隔几十秒产生一次，也还可以接受，如果每秒都会发生一次YGC，那说明需要增加内存了。
YGCT：表示新生代堆内存GC消耗的总时间。
FGC：FULL GC发生的次数，注意，如果发生FUCC GC，则Flume进程会进入暂停状态，FUCC GC执行完以后。
Flume才会继续工作，所以FUCC GC是非常影响效率的，这个指标的值越低越好，没有更好。
GCT：所有类型的GC消耗的总时间。

如果需要调整Flume进程内存的话，需要调整flume-env.sh脚本中的JAVA_OPTS参数把export JAVA_OPTS参数前面的#号去掉才会生效。

export JAVA_OPTS="-Xms1024m -Xmx1024m -Dcom.sun.management.jmxremote"

建议这里的Xms和Xmx设置为一样大，避免进行内存交换，内存交换也比较消耗性能。

在一台服务器启动多个agent的时候，建议修改配置区分日志文件。

因为在conf目录下有log4j.properties，在这里面指定了日志文件的名称和位置，所有使用conf目录下面配置启动的Agent产生的日志都会记录到同一个日志文件中，如果我们在一台机器上启动了10几个Agent，后期发现某一个Agent挂了，想要查看日志分析问题，这个时候就疯了，因为所有Agent产生的日志都混到一块了，压根都没法分析日志了。

所以建议拷贝多个conf目录，然后修改对应conf目录中log4j.properties日志的文件名称(可以保证多个agent的日志分别存储)，并且把日志级别调整为warn(减少垃圾日志的产生)，默认info级别会记录很多日志信息。这样在启动Agent的时候分别通过–conf参数指定不同的conf目录，后期分析日志就方便了，每一个Agent都有一个单独的日志文件。

以master机器为例：复制conf-failover目录，以后启动sink的failover任务的时候使用这个目录，修改 log4j.properties中的日志记录级别和日志文件名称，日志文件目录可以不用修改，统一使用logs目录即可。

[root@master flume]# cp -r conf/ conf-failover
[root@master flume]# cd conf-failover/
[root@master flume]# vim log4j.properties 
.....
flume.root.logger=WARN,LOGFILE
flume.log.dir=./logs
flume.log.file=flume-failover.log
.....

再启动Agent。

[root@master flume]# nohup bin/flume-ng agent --name a1 --conf conf-failover --conf-file conf-failover/failover.conf &

这样就会在flume的logs目录中产生flume-failover.log文件，并且文件中只记录WARN和ERROR级别的日志，这样后期排查日志就很清晰了。

2.Flume进程监控

Flume的Agent服务是一个独立的进程，假设我们使用source->channel->sink实现了一个数据采集落盘的功能，如果这个采集进程被误操作干掉了，这个时候我们是发现不了的，什么时候会发现呢？可能第二天，产品经理找到你了，说昨天的这个指标值有点偏低啊，你来看下怎么回事，然后你就一顿操作猛如虎，结果发现原始数据少了一半多，那是因为Flume的采集程序在昨天下午的时候被误操作干掉了。

所以针对这些存在单点故障的进程，我们都需要添加监控告警机制，最起码出问题能及时知道，再好一点的呢，可以尝试自动修复重启。那针对Flume中的Agent我们就来实现一个监控功能，并且尝试自动重启。

大致思路是这样的：

首先需要有一个配置文件，配置文件中指定你现在需要监控哪些Agent。
有一个脚本负责读取配置文件中的内容，定时挨个检查Agent对应的进程还在不在，如果发现对应的进程不在，则记录错误信息，然后告警(发短信或者发邮件) 并尝试重启。

我们以监控第一小节的example的Agent为例，创建一个文件monlist.conf 文件中的第一列指定一个Agent的唯一标识，后期需要根据这个标识过滤对应的Flume进程，所以一定要保证至少在一台机器上是唯一的，等号后面是一个启动Flume进程的脚本，这个脚本和Agent的唯一标识是一一对应的，后期如果根据Agent标识没有找到对应的进程，那么就需要根据这个脚本启动进程。

在$FLUME_HOME/conf/下新建monlist.conf

example=startExample.sh

在$FLUME_HOME/bin/下新建startExample.sh和monlist.sh

startExample.sh

#!/bin/bash
flume_path=/usr/local/flume
nohup ${flume_path}/bin/flume-ng agent --name a1 --conf ${flume_path}/conf/ --conf-file ${flume_path}/conf/example.conf  &

monlist.sh

#!/bin/bash

flume_path=/usr/local/flume
monlist=`cat ${flume_path}/conf/monlist.conf`
echo "start check"
for item in ${monlist}
do
    # 设置字段分隔符
    OLD_IFS=$IFS
    IFS="="
    # 把一行内容转成多列[数组]
    arr=($item)
    # 获取等号左边的内容
    name=${arr[0]}
    # 获取等号右边的内容
    script=${arr[1]}

    echo "time is:"`date +"%Y-%m-%d %H:%M:%S"`" check "$name
    if [ `jps -m|grep $name | wc -l` -eq 0 ]
    then
        # 发短信或者邮件告警
        echo `date +"%Y-%m-%d %H:%M:%S"`$name "is none"
        sh -x ./${script}
    fi
done

执行monlist.sh。

[root@master bin]# ./monlist.sh
start check
time is:2023-10-03 13:54:15 check example
2023-10-03 13:54:15example is none
+ flume_path=/usr/local/flume
[root@master bin]# + nohup /usr/local/flume/bin/flume-ng agent --name a1 --conf /usr/local/flume/conf/ --conf-file /usr/local/flume/conf/example.conf
nohup: 把输出追加到"nohup.out"

使用jps和ps观察example Agent已经启动。

[root@master bin]# jps
15236 Jps
12677 Application

[root@master bin]# ps -ef | grep example
root     12677     1  0 13:54 pts/0    00:00:01 /usr/local/jdk/jdk1.8.0_271/bin/java -Xms1024m -Xmx1024m -Dcom.sun.management.jmxremote -cp /usr/local/flume/conf:/usr/local/flume/lib/*:/usr/local/hadoop3.1/etc/hadoop:/usr/local/hadoop3.1/share/hadoop/common/lib/*:/usr/local/hadoop3.1/share/hadoop/common/*:/usr/local/hadoop3.1/share/hadoop/hdfs:/usr/local/hadoop3.1/share/hadoop/hdfs/lib/*:/usr/local/hadoop3.1/share/hadoop/hdfs/*:/usr/local/hadoop3.1/share/hadoop/mapreduce/lib/*:/usr/local/hadoop3.1/share/hadoop/mapreduce/*:/usr/local/hadoop3.1/share/hadoop/yarn:/usr/local/hadoop3.1/share/hadoop/yarn/lib/*:/usr/local/hadoop3.1/share/hadoop/yarn/*:/usr/local/hive/lib/* -Djava.library.path=:/usr/local/hadoop3.1/lib/native org.apache.flume.node.Application --name a1 --conf-file /usr/local/flume/conf/example.conf
root     16252  1441  0 13:57 pts/0    00:00:00 grep --color=auto example

注意：这个需要定时执行，所以可以使用crontab定时调度。

* * * * *  root /usr/local/flume/bin/monlist.sh