對於日誌的採集，給出乙個常規的思路：
執行採集日誌應用（非web程式），使用檔案流讀取文字檔案，當讀取到檔案末尾時，可以讓當前執行緒睡眠一段時間，從而達到對日誌採集的目的。
這樣就會出現幾個問題：
1、當應用異常終止時，重新啟動，那樣問題就來了：出現對日誌的重複採集。
想了下，也沒什麼更好的辦法，於是採集到的日誌行數儲存在乙個檔案中，當重新啟動時，讀取改檔案對日誌檔案進行定位採集。
2、日誌檔案一般情況下並不是有規律的，需要更多的配置re進行匹配。
下面介紹re的常規用法：
比如有如下日誌
mar 3 10:39:31 linux-c3xt slapd[4081]: conn=25 fd=9 accept from ip=192.168.0.1:4142 (ip=0.0.0.0:389)
mar 3 10:39:31 linux-c3xt slapd[4081]: conn=25 op=0 bind dn="uid=elfinesh,ou=people,o=ethionet.et,o=etc" method=128
mar 3 10:39:31 linux-c3xt slapd[4081]: perform_search: performing search in cn=elfinesh,cn=006,cn=testispusers,dc=sctel,dc=com,dc=cn, with filter (objectclass=*).
mar 3 10:39:31 linux-c3xt slapd[4081]: conn=25 op=0 bind dn="uid=elfinesh,ou=people,o=ethionet.et,o=etc" mech=****** ssf=0
mar 3 10:39:31 linux-c3xt slapd[4081]: conn=25 op=0 result tag=97 err=0 text=
mar 3 10:39:31 linux-c3xt slapd[4081]: conn=25 op=1 unbind
mar 3 10:39:31 linux-c3xt slapd[4081]: conn=25 fd=9 closed
(\\w+\\s+\\d+\\s+\\d:\\d:\\d)\\s+.+\\s+slapd+\\[\\d+\\]:\\s+conn=\\d+\\s+fd=\\d+\\s+accept\\s+from\\s+ip=.+\\w+\\s+\\d+\\s+\\d:\\d:\\d\\s+.+\\s+slapd+\\[\\d+\\]:\\s+conn=\\d+\\s+op=\\d+\\s+bind\\s+dn=\\\"uid=(\\w+),ou.+\\w+\\s+\\d+\\s+\\d:\\d:\\d\\s+.+\\s+slapd+\\[\\d+\\]:\\s+conn=\\d+\\s+op=\\d+\\s+result\\s+tag=\\d+\\s+err=(\\d+)\\s+.+\\w+\\s+\\d+\\s+\\d:\\d:\\d\\s+.+\\s+slapd+\\[\\d+\\]:\\s+conn=\\d+\\s+fd=\\d+\\s+closedre r = new re(re0);
if (r.match(讀取日誌檔案的一行))
4、對於一些特殊情況，日誌並不是孤立存在的，如存在請求日誌和響應日誌，需要對兩個日誌檔案進行同步採集。另外，如果涉及到多系統（多ip採集），可以使用到執行緒池進行優化處理。
對於執行緒池的使用，後面再來整理。
日誌採集 基於Flink的日誌採集
目前基於elk架構的日誌系統，通過filebeat收集上來的日誌都會傳送到同乙個kafka topic中，然後再由logstash消費處理寫入elasticsearch中，這種方式導致該topic包含所有業務日誌，那麼各個業務去做實時統計分析就會造成重複消費，使得流量成本的浪費 對於離線分析的日誌 ...
日誌採集處理
最近由於專案需要上線乙個日誌採集 展示的功能，藉此機會梳理了一下日誌採集的大體框架。一般日誌採集的總體框架如下 大體流程為 統一日誌系統負責收集所有系統日誌和業務日誌，轉化為流式資料，通過flume或logstash上傳到日誌中心 kafka集群 然後供track storm spark及其它系統實...
日誌採集系統
編寫日誌採集系統 邏輯分析 1.找到伺服器上日誌存在的目錄，因為日誌可能正在編寫，防止讀取檔案的時候，日誌檔名的改變，所以將編寫完成的日誌移動到某乙個臨時的資料夾下 2.在臨時資料夾下將檔案上傳至hdfs系統中 3.將讀取的檔案移動到某種備份檔案中，設定為24小時後自動刪除 採集日誌 public ...