缺點：日志收集需要依賴額外的采集服務,過濾和存儲可能還需要額外配置.

被動接收

優點：業務程序直接將日志發送至存儲,靈活性強,存儲內容可在業務代碼里控制.

缺點：日志存儲不穩定的話會影響業務程序的正常運行；反之,日志量大的話也會壓垮日志存儲.

但是在建設監控系統初期,日志存儲還不是很穩定的情況下,還是用主動采集的方式比較穩妥,不影響服務穩定性為主.

Collectd功能確實很強大,它的tail插件也能滿足從文件收集日志,但是tail插件配置比較復雜而且說明文檔相較于Filebeat來說不是很詳細.

Collectd的其他插件可以采集的數據確實很多,而且也有插件支持將數據發送到Logstash和InfluxDB,但是多數插件的功能我們用不到,而且Elastic Stack中的Beats也能夠很好的收集系統參數等數據,而且跟ELK能很好的兼容.

所以在分別試用了Filebeat和Collectd這2個采集服務后,綜合上述分析決定采用Filebeat來負責從日志文件中采集日志.如下所示,Filebeat的配置簡單易懂：

filebeat:
spool_size:?1024????????????????????????????????????#?最大可以攢夠?1024?條數據一起發送出去
idle_timeout:?“5s”??????????????????????????????????#?否則每?5?秒鐘也得發送一次
registry_file:?“registry”???????????????????????????#?文件讀取位置記錄文件,會放在當前工作目錄下.
config_dir:?“path/to/configs/contains/many/yaml”????#?如果配置過長,可以通過目錄加載方式拆分配置
prospectors:????????????????????????????????????????#?有相同配置參數的可以歸類為一個?prospector
–
fields:
log_source:?“sample”????????????????????#?類似?logstash?的?add_fields,此處的”log_source”用來標識該日志來源于哪個項目
paths:
–?/var/log/system.log???????????????????#?指明讀取文件的位置
–?/var/log/wifi.log
include_lines:?[“^ERR”,?“^WARN”]????????????#?只發送包含這些字樣的日志
exclude_lines:?[“^OK”]??????????????????????#?不發送包含這些字樣的日志
–
document_type:?“apache”?????????????????????#?定義寫入?ES?時的?_type?值
ignore_older:?“24h”?????????????????????????#?超過?24?小時沒更新內容的文件不再監聽.
scan_frequency:?“10s”???????????????????????#?每?10?秒鐘掃描一次目錄,更新通配符匹配上的文件列表
tail_files:?false???????????????????????????#?是否從文件末尾開始讀取
harvester_buffer_size:?16384????????????????#?實際讀取文件時,每次讀取?16384?字節
backoff:?“1s”???????????????????????????????#?每?1?秒檢測一次文件是否有新的一行內容需要讀取
paths:
–?“/var/log/apache/*”???????????????????#?可以使用通配符
exclude_files:?[“/var/log/apache/error.log”]
–
input_type:?“stdin”?????????????????????????#?除了?“log”,還有?“stdin”
multiline:??????????????????????????????????#?多行合并
pattern:?‘^[[:space:]]’
negate:?false
match:?after
output:
logstash:
hosts:?[“localhost:5044”]??????????????????????????#?The?Logstash?hosts

4 . 日志過濾

Logstash 自2009年誕生經過多年發展,已經是很成熟并且流行的日志處理框架.Logstash使用管道方式進行日志的搜集處理和輸出.有點類似*NIX系統的管道命令 input | filter | output,input 執行完了會執行 filter,然后執行 output.在 Logstash 中,包括了三個階段：輸入input → 處理filter(不是必須的)→ 輸出output.每個階段都由很多的插件配合工作,比如 file、elasticsearch、redis 等等.每個階段也可以指定多種方式,比如輸出既可以輸出到elasticsearch中,也可以指定到stdout在控制臺打印.

Codec 是 Logstash 從 1.3.0 版開始新引入的概念(Codec 來自 Coder/decoder兩個單詞的首字母縮寫).在此之前,Logstash 只支持純文本形式輸入,然后以過濾器處理它.但現在,我們可以在輸入 期處理不同類型的數據,這全是因為有 Codec 設置.所以,這里需要糾正之前的一個概念.Logstash 不只是一個 input | filter | output 的數據流,而是一個 input | decode | filter | encode | output 的數據流!Codec 就是用來 decode、encode 事件的.Codec 的引入,使得 Logstash 可以更好更方便的與其他有自定義數據格式的運維產品共存,比如 graphite、fluent、netflow、collectd,以及使用msgpack、json、edn 等通用數據格式的其他產品等.

Logstash 提供了非常多的插件(Input plugins、Output plugins、Filter plugins、Codec plugins),可以根據需求自行組合.其中 Filter 插件 Grok 是 Logstash 最重要的插件.Grok 通過正則表達式匹配日志內容,并將日志結構化,所以理論上只要正則掌握的夠嫻熟,就能解析任何形式的日志,非常適合用來解析第三方服務產生的非結構化日志.但是如果是自己寫的服務,就沒必要將日志輸出成非結構的,增加寫正則的負擔,所以在上述日志打印一節中才規定線上的日志輸出成json形式,方便 Logstash 解析,Logstash 提供 json 的 Filter 插件.

Logstash 的配置文件默認放在 /etc/logstash/conf.d 目錄下,如果需要采集多個項目的日志,每個項目的 Logstash 配置可能不一樣,那就會在 conf.d 里存放多個配置文件,以每個項目命名方便管理.但是這樣會帶來一個問題,因為 Logstash 會將所有配置文件合并為一個,即一條日志通過input進入到Logstash后,會經過每個配置文件里的filter和output插件,造成對日志錯誤的處理和輸出.解決方式是在Filebeat的fileds配置項里增加區分不同項目的field,如果日志路徑就能區分不同項目的話也可以不用額外加field,用 Filebeat 自帶的source字段就可以,然后在每個項目對應的 Logstash 配置文件里通過IF標識項目,項目各自的日志進各自的配置,互不干擾.

input {
beats {
port => “5044”
}
}
// The filter part of this file is commented out to indicate that it is
// optional.
filter {
if [beat] and [source] =~ “sample” {
json {
source => “message”
}
ruby {
code => “event.set(‘time’,(Time.parse(event.get(‘time’)).to_f*1000000).to_i)”
}
}
}
output {
if [beat] and [source] =~ “sample” {
stdout { codec => rubydebug }
}
}

5 . 日志存儲