21【在线日志分析】之记录一个flume-ng的tail -f参数所诱发的血案
一.现象： flume收集-->flume聚合-->kafka-->spark streaming+spark sql-->influxdb-->grafana1.所有进程都是 后台运行的;2.运行进程，当时整套流程都是ok的;3.但是，过一段时间，发现grafana的图表没有数据展示了!!!二.排查:1.检查 spark streaming+spark sql的计算的log,发现一直打印“No cdh role logs in this time interval” ;那么可以推断没有日志过来。2.检查kafka集群是否正常？通过kafka manager的web查看topic，可以看到集群正常，但是 发现Metrics这个的Bytes in /sec这一行都是0，表明flume聚合节点 没有数据输出到kafka集群。 3.难道我的flume收集节点的进程有异常？？？ a.检查flume进程还在 和 后台运行的 nohup.out日志 没有发现异常； b.难道监控的那个日志，不存在吗？ 然后 ll 命令查看一下，发现存在的哇。 c.检查我的flume参数文件配置,初步检查没有发现异常,手工执行 这个命令"tail -f /var/log/hadoop-hdfs/hadoop-cmf-hdfs1-NAMENODE-hadoop-01.log.out" 是能够实时输出显示的 点击(此处)折叠或打开 [hdfs@hadoop-01 conf]$ cat nn1_exec_memory_avro.properties # Name the components on this agent a1.sources = r1 a1.sinks = k1 a1.channels = c1 # Describe/configure the custom exec source a1.sources.r1.type = com.onlinelog.analysis.AdvancedExecSource a1.sources.r1.command = tail -f /var/log/hadoop-hdfs/hadoop-cmf-hdfs1-NAMENODE-hadoop-01.log.out a1.sources.r1.batchSize = 200 a1.sources.r1.hostname = hadoop-01 a1.sources.r1.servicename = namenode # Describe the sink a1.sinks.k1.type = avro a1.sinks.k1.hostname = 172.16.101.54 a1.sinks.k1.port = 4545 a1.sinks.k1.batch-size = 200 # Use a channel which buffers events in memory a1.channels.c1.type = memory a1.channels.c1.keep-alive = 60 a1.channels.c1.capacity = 1000000 a1.channels.c1.transactionCapacity = 600 # Bind the source and sink to the channel a1.sources.r1.channels = c1 a1.sinks.k1.channel = c1 4.google+baidu ............ 5.实在没办法，打开官网 https://flume.apache.org/FlumeUserGuide.html#exec-source 发现这么一句话： Just use unix command tail -F /full/path/to/your/file . Parameter -F is better in this case than -f as it will also follow file rotation. 然后我发现用的是tail -F（是大写），而我们运维，dba人员习惯用tail -f ,于是我去查看命令帮助发现这两者的差别。 $ tail --help -f, --follow[={name|descriptor}] output appended data as the file grows; -f, --follow, and --follow=descriptor are equivalent -F same as --follow=name --retry 而我们的log日志，是每达到200M，是要重新重命名的，比如加上序号1.，然后重新创建这个日志。所以在tail 一个log文件的时候, 文件滚动之后这个tail -f命令,就失效了.-F 是--follow=name --retry的缩写, --follow=name是按照文件名跟踪文件, 可以定期去重新打开文件检查文件是否被其它程序删除并重新建立. --retry这个参数, 保证文件重新建立后,可以继续被跟踪.三.解决方法: 于是，我果断将所有的 -f改为-F, 重启flume进程(当然好像可以不用重启的，因为flume会每隔一段时间会读取配置文件来动态生效，不过我还是选择手动重启，立即生效)， 监控一周，运行正常。
