最近想將服務的運行日志收集起來，首先了解到flume技術棧
采用flume方案定了之后有兩種方式實現
1: 在應用中，log4j2直接發送日志信息到flume ，
2: 通過監控log4j2 產生的日志文件，將日志文件新產生的日志發送到flume
下面兩種方式都會介紹，首先透漏下我們選擇的解決方案，我們選擇了第二種監控新產生的日志文件
為什么這么選擇：
第一種方式需要修改服務中log4j2的配置，添加flume Appender , 在應用中，當日志輸出時，就會輸出到flume，很顯然，這種方式耦合了應用，並且對應用的性能有影響，到底有多大影響，這個還沒有測試，其次，這種方式應用中依賴了flume的依賴，假如將來部署服務的時候不想收集日志了，會不會對項目的啟動有影響，這一點也還沒有驗證，后續可能會驗證
第二種方式完全是監控日志文件，當產生新的日志文件或者日志文件中生成新的日志時，就會觸發日志收集。完全脫離應用存在。
我們介紹第二種方式的探索過程：
需求：當日志目錄下產生新的文件或動態產生日志時，收集日志，發送到flume
接下來了解flume能不能解決我們的需求：
flume 入門相關概念：
source：
channel:
sink ;
source 中有很多分類，我們着重分析了幾個的使用場景和特點
execSource :
spooldirSource :
taildirSource:
syslogSource ;
httpSource ;
經過分析每種Source的特點，很容易發現tailSource最接近我們的需求：
但是也有幾個問題：
1：log4j2產生日志的邏輯是當日志文件內容達到設置的size上限就會重命名該日志文件（例如：sysware-2018-12-20-1.log）,然后新建一個sysware.log文件，供日志輸出，重命名日志之后，和原來的sysware.log日志文件全路徑不一致，taildirSource會當做一個新的日志文件，再次重復讀取，造成重復讀取的問題
2：dirSource監控的dir 可以指定文件名稱或者通過正則，但是如果已經有子文件夾的日志讀取不到
上面的問題只能通過源碼方式解決了
XXXXXX
所有的准備工作都做好了，我們現在開始做一個demo
XXXX