21【線上日誌分析】之記錄一個flume-ng的tail -f引數所誘發的血案

hackeruncle發表於2017-02-21
AI

一.現象：

flume收集-->flume聚合-->kafka-->spark streaming+spark sql-->influxdb-->grafana
1.所有程式都是 後臺執行的;
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"  是能夠實時輸出顯示的

點選(此處)摺疊或開啟

  1. [hdfs@hadoop-01 conf]$ cat nn1_exec_memory_avro.properties
  2. # Name the components on this agent
  3. a1.sources = r1
  4. a1.sinks = k1
  5. a1.channels = c1
  7. # Describe/configure the custom exec source
  8. a1.sources.r1.type = com.onlinelog.analysis.AdvancedExecSource
  9. a1.sources.r1.command = tail -f /var/log/hadoop-hdfs/hadoop-cmf-hdfs1-NAMENODE-hadoop-01.log.out
  10. a1.sources.r1.batchSize = 200
  11. a1.sources.r1.hostname = hadoop-01
  12. a1.sources.r1.servicename = namenode
  16. # Describe the sink
  17. a1.sinks.k1.type = avro
  18. a1.sinks.k1.hostname = 172.16.101.54
  19. a1.sinks.k1.port = 4545
  20. a1.sinks.k1.batch-size = 200
  22. # Use a channel which buffers events in memory
  23. a1.channels.c1.type = memory
  24. a1.channels.c1.keep-alive = 60
  25. a1.channels.c1.capacity = 1000000
  26. a1.channels.c1.transactionCapacity = 600
  28. # Bind the source and sink to the channel
  29. a1.sources.r1.channels = c1
  30. a1.sinks.k1.channel = c1

4.google+baidu............


5.實在沒辦法，開啟官網

發現這麼一句話：21【線上日誌分析】之記錄一個flume-ng的tail -f引數所誘發的血案
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會每隔一段時間會讀取配置檔案來動態生效，不過我還是選擇手動重啟，立即生效)，
監控一週，執行正常。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/30089851/viewspace-2134067/，如需轉載，請註明出處，否則將追究法律責任。

相關文章