ELK日誌分析平臺學習記錄
首先ELK主要指elasticsearch 、logstash 和kibana，三個開源軟件組合而成的一套日誌平臺解決方案。可以將平時收集到的日誌，通過前臺展示出來，並且可以加以分析，理論上可以解放勞動力（再也不用幹上生產取日誌這種活了——很搓）。
最近在研究ELKstack日誌分析平臺，網上相關的中文資料不多。所以呢也就寫了這篇文章將自己的一些學習認識總結記錄下來，基本偏實戰，概念理論較少，概念這塊，我想以後可以再開一篇文章來做一個闡述總結。
這篇文章中會先講一下搭建部署的內容，這一部分我在自己電腦上建了兩臺虛擬機來做這個實驗，大致做個入門。同時後面我會記錄一下我在實際使用過程中的一些心得，還有遇到的一些坑，以及解決辦法。由於ELK stack這塊我也還在學習摸索中，還有諸多不足，如果有什麼不正確的地方，請見諒。
這裏推薦大家可以上官網查看官方文檔https://www.elastic.co/guide/index.html寫的是很全的。
一、架構
採用官方推薦的架構
首先官方推出了輕量化數據收集輸送應用beat，其中主要的做日誌收集的filebeat是新一代作爲原來logstash-forwarder的替代品，那所以就使用filebeat了。
其中beat（現在只使用filebeat）作爲 agent端收集日誌併發送給logstash，logstash做過濾再給到搜索引擎elasticsearch。最後kibana提供前臺界面給用戶。
二、安裝部署
我這裏起了兩個虛擬機作爲安裝部署的實例
| IP | role | app |
| 192.168.247.128 | server | logstash elasticsearch kibana |
| 192.168.247.129 | client | filebeat |
應用清單
elasticsearch-2.1.1
kibana-4.3.1
logstash-2.1.1-1
filebeat-1.0.1
我這邊應用基本都用最新的了，採用的架構可能也與網上較多的logstash→redis→logstash→elasticsearch→kibana的方式不同。那種基於的應用版本可能較低，但是應該在很多地方已經實際投產使用了，穩定性應該有保證。
filebeat、logstash、elasticsearch都採用rpm包安裝方式，注意logstash和elasticsearch是基於java的需要先安裝jdk。具體的安裝要求見https://www.elastic.co/support/matrix
rpm包安裝很方便，在此不做贅述
elasticsearch安裝後修改下綁定IP啓動，elasticsearch的配置文件/etc/elasticsearch/elasticsearch.yml中有許多配置項目，這裏不一一說明了。像是存數據的路徑、綁定IP端口、集羣name等等。
啓動後驗證
[root@servertest01 elasticsearch]# curl -XGET http://192.168.247.128:9200
{
"name" : "Black Crow",
"cluster_name" : "elasticsearch",
"version" : {
"number" : "2.1.1",
"build_hash" : "40e2c53a6b6c2972b3d13846e450e66f4375bd71",
"build_timestamp" : "2015-12-15T13:05:55Z",
"build_snapshot" : false,
"lucene_version" : "5.3.1"
},
"tagline" : "You Know, for Search"
}logstash先不起，我們先來寫配置文件
logstash配置文件主要分三塊，官方提供了相當相當多的plugin，可以更具情況來使用，其中filter不是必須項。
由於實驗用filebeat採集數據，然後輸出到elasticsearch。所以input plugin用beats， output plugin用elasticsearch。
input {
beats {
port => "5044"
}
}
output {
elasticsearch {
hosts => "192.168.247.128"
index =>"hello-%{+YYYY.MM.dd}"
}
}我把5044端口作爲輸入端口,logstash提供了檢查語法的功能service logstash configtest，檢查好OK後（這裏是實驗很簡單所以不用檢查也可以，但是我在實際使用中內容會比較多，會有codec filter plugin等等配置難免會有遺漏，所以檢查下養成個好習慣），啓動service logstash start
客戶端上的filebeat在啓動前，elasticsearch需要先讀取其索引模版
[root@clienttest01 ~]# curl -XPUT 'http://192.168.247.128:9200/_template/filebeat?pretty' -d@/etc/filebeat/filebeat.template.json
{
"acknowledged" : true
}來看看默認的配置文件
[root@clienttest01 filebeat]# egrep -v '^$|^#|^\s+#' filebeat.yml filebeat: prospectors: - paths: - /var/log/*.log input_type: log registry_file: /var/lib/filebeat/registry output: elasticsearch: hosts: ["localhost:9200"] shipper: logging: files: rotateeverybytes: 10485760 # = 10MB
爲做實驗我做了下修改，啓動
[root@clienttest01 filebeat]# more filebeat.yml filebeat: prospectors: - paths: - /var/log/*.log input_type: log output: logstash: hosts: ["192.168.247.128:5044"]
然後我就在 /var/log下建了a.log 隨便追加了一些信息
kibana下載後解包 直接使用 由於我們綁定了elasticsearch的IP，所以修改config目錄下配置文件kibana.yml 中elasticsearch server 的地址信息後 到bin目錄下 nohup ./kibana &
默認端口5601
瀏覽器輸入http://192.168.247.128:5601
由於索引我output plugin設的是hello 所以kibana那邊就設默認索引爲hello好了
然後看看成果
OK，基本的部署流程就這樣的。這個實驗我就起了一個elasticsearch，這就是一個節點，如果只有一個的話，elasticsearch的健康度就是***的。elasticsearch一共分紅色、***、綠色三種健康度。所以也就是說實際投產的話，至少得起兩個elasticsearch，那樣健康度才能是綠色。做實驗也就無所謂了。elasticsearch中有個配置叫cluster.name。當網絡環境一樣，多個elasticsearch的cluster.name一樣那他們就會加入到同一個集羣。這樣是很方便的。
三、注意事項
修改MMAP參數，這個官方文檔裏有明確說明
vi /etc/sysctl.conf
添加vm.max_map_count = 262144
sysctl -p
生效
修改文件描述符
文件描述符如果不調的話，elasticsearch運行一段時間就會報錯too many open files同時logstash也會報管道阻塞。所以必須調整
查看現有的情況，可以看到open files 只有1024 這是遠遠不夠的，要調大。
[root@servertest01 bin]# ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 14717 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 14717 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
修改配置 在最後添加兩行如下。
[root@servertest01 ~]# more /etc/security/limits.conf # /etc/security/limits.conf # #Each line describes a limit for a user in the form: # #<domain> <type> <item> <value> # #Where: #<domain> can be: # - a user name # - a group name, with @group syntax # - the wildcard *, for default entry # - the wildcard %, can be also used with %group syntax, # for maxlogin limit # #<type> can have the two values: # - "soft" for enforcing the soft limits # - "hard" for enforcing hard limits # #<item> can be one of the following: # - core - limits the core file size (KB) # - data - max data size (KB) # - fsize - maximum filesize (KB) # - memlock - max locked-in-memory address space (KB) # - nofile - max number of open file descriptors # - rss - max resident set size (KB) # - stack - max stack size (KB) # - cpu - max CPU time (MIN) # - nproc - max number of processes # - as - address space limit (KB) # - maxlogins - max number of logins for this user # - maxsyslogins - max number of logins on the system # - priority - the priority to run user process with # - locks - max number of file locks the user can hold # - sigpending - max number of pending signals # - msgqueue - max memory used by POSIX message queues (bytes) # - nice - max nice priority allowed to raise to values: [-20, 19] # - rtprio - max realtime priority # #<domain> <type> <item> <value> # #* soft core 0 #* hard rss 10000 #@student hard nproc 20 #@faculty soft nproc 20 #@faculty hard nproc 50 #ftp hard nproc 0 #@student - maxlogins 4 * soft nofile 65535 * hard nofile 65535 # End of file
重新ssh連上來查看，生效
[root@servertest01 ~]# ulimit -n 65535
四、遇到的一些坑和使用體會
1、發現kibana中的中文日誌有亂碼。根據檢查發現是因爲中文有亂碼的日誌文件是ISO-8859格式文件。如果想要中文沒有亂碼。日誌文件應該是UTF-8格式。這個可以用file命令查看。由於我這裏的日誌是用log4j生成的。所以生成的日誌文件類型可以在log4j中定義，統一起來也不難。配置參考如下
<appender name="FILE" class="org.apache.log4j.DailyRollingFileAppender"> <param name="File" value="./logs/app.log"/> <param name="Encoding" value="UTF-8"/> <param name="DatePattern" value="'.'yyyy-MM-dd"/>
這樣生成的文件就是UTF-8格式的了
[uat4@localhost logs]$ file app.log app.log: UTF-8 Unicode English text, with very long lines
2.我在一臺rhel5.7的服務器上 用rpm包安裝了filebeat 。用service filebeat start啓動報錯
FATAL: kernel too old，
我在官方論壇發現有人用rhel5.10啓動topbeat也有這樣的報錯
而回答是這樣
Currently we don't support RHEL 5.x as Golang doesn't have officially support for it,
但是我發現用 /usr/bin/filebeat -e -c /etc/filebeat/filebeat.yml 是可以使用的。我沒研究過源代碼，但是用後面的方法是可以用的，所以如果服務器是rhel5.X的話，可以下載filebeat的tar安裝包來使用。那樣應該是不會有問題的。
3.filebeat如果直接連elasticsearch，首先默認的話它會把所以收集的日誌信息都作爲一個以beatname命名的索引建立。實際使用時，一個服務器上可能不止跑一個應用，會有多個應用的日誌文件，那麼在kibana上就會發現所有的日誌都合在一起，那這樣子是不科學的，這些應該都區分開來。根據官方文檔所述，filebeat有個fields參數可以自定義字段。可以把不同的應用日誌用字段來區分。然後傳到logstash做判斷，不同的日誌分爲不同的索引。那這樣可以在kibana上通過不同的索引查看不同應用的日誌信息了。
舉例說明，我爲這兩個日誌自定義了字段tag，分別值爲zabbix和alivelog。就可以將日誌分類，最後在elasticsearch生成爲兩個不同的索引。
filebeat: prospectors: - paths: - "/var/log/zabbix/*.log" fields: tag: zabbix - paths: - "/home/hu/test/alivehost*" fields: tag: alivelog
logstash中output-plugin
output {
if [fields][tag] == "zabbix" {
elasticsearch {
hosts => "192.168.1.123"
index => "zabbix-%{+YYYY.MM.dd}"
}
}
if [fields][tag] == "alivelog" {
elasticsearch {
hosts => "192.168.1.123"
index => "alive-%{+YYYY.MM.dd}"
}
}
}那這樣就可以在kibana中區分了
4.將多行日誌內容合併爲一條日誌，實際使用中會有報錯日誌信息，像java的報錯信息就是需要將多行合併爲一行的，不然kibana上看到的都是每行獨立的一條記錄。這個可以使用logstash中codec插件中的multiline。通過multiline寫正則表達式匹配多行信息。將codec配置在logstash中的input裏，然後寫上對應的正則表達式。我從網上參考了java報錯日誌的正則匹配，如下
codec => multiline {
pattern => "(^\s*Caused by.+)|(^.+Exception.+)|(^\s+at .+)|(^\s+... \d+ more)"
what => "previous"
}5.分析日誌內容，將內容分成不同的字段，這裏可以使用filter_plugin中的grok
grok正則匹配日誌的話logstash默認自帶了一些模板，tomcat的模板也有。該模板可能與實際的情況不符。但是改一下就可以了，在測試環境上我修改了java文件的內容，用於匹配tomcat日誌，分爲timestamp level class logmessage 這幾個字段。這裏logstash是用rpm包安裝的。
cd /opt/logstash/vendor/bundle/jruby/1.9/gems/logstash-patterns-core-2.0.2/patterns/
可以看到有許多grok的patterns文件，這些就是模板。編輯下java文件修改tomcat的正則表達式。
[root@localhost patterns]# vi java
JAVACLASS (?:[a-zA-Z$_][a-zA-Z$_0-9]*\.)*[a-zA-Z$_][a-zA-Z$_0-9]*
#Space is an allowed character to match special cases like 'Native Method' or 'Unknown Source'
JAVAFILE (?:[A-Za-z0-9_. -]+)
#Allow special <init> method
JAVAMETHOD (?:(<init>)|[a-zA-Z$_][a-zA-Z$_0-9]*)
#Line number is optional in special cases 'Native method' or 'Unknown source'
JAVASTACKTRACEPART %{SPACE}at %{JAVACLASS:class}\.%{JAVAMETHOD:method}\(%{JAVAFILE:file}(?::%{NUMBER:line})?\)
# Java Logs
JAVATHREAD (?:[A-Z]{2}-Processor[\d]+)
#JAVACLASS (?:[a-zA-Z0-9-]+\.)+[A-Za-z0-9$]+
JAVACLASS \[(?:[a-zA-Z0-9-]+\.)+[A-Za-z0-9$]+\] -----------實際由中括號括起來
JAVAFILE (?:[A-Za-z0-9_.-]+)
JAVASTACKTRACEPART at %{JAVACLASS:class}\.%{WORD:method}\(%{JAVAFILE:file}:%{NUMBER:line}\)
JAVALOGMESSAGE (.*)
# MMM dd, yyyy HH:mm:ss eg: Jan 9, 2014 7:13:13 AM
CATALINA_DATESTAMP %{MONTH} %{MONTHDAY}, 20%{YEAR} %{HOUR}:?%{MINUTE}(?::?%{SECOND}) (?:AM|PM)
# yyyy-MM-dd HH:mm:ss,SSS ZZZ eg: 2014-01-09 17:32:25,527 -0800
#TOMCAT_DATESTAMP 20%{YEAR}-%{MONTHNUM}-%{MONTHDAY} %{HOUR}:?%{MINUTE}(?::?%{SECOND}) %{ISO8601_TIMEZONE}
TOMCAT_DATESTAMP 20%{YEAR}-%{MONTHNUM}-%{MONTHDAY} %{HOUR}:?%{MINUTE}(?::?%{SECOND})------------將時區去除
CATALINALOG %{CATALINA_DATESTAMP:timestamp} %{JAVACLASS:class} %{JAVALOGMESSAGE:logmessage}
# 2014-01-09 20:03:28,269 -0800 | ERROR | com.example.service.ExampleService - something compeletely unexpected happened...
#TOMCATLOG %{TOMCAT_DATESTAMP:timestamp} \| %{LOGLEVEL:level} \| %{JAVACLASS:class} - %{JAVALOGMESSAGE:logmessage}
TOMCATLOG %{TOMCAT_DATESTAMP:timestamp} %{LOGLEVEL:level} %{JAVACLASS:class} - %{JAVALOGMESSAGE:logmessage} -------實際環境沒有豎線所以重新配置TOMCATLOG在logstash配置文件中添加filter plugin
filter {
grok {
match => { "message" => "%{TOMCATLOG}" }
}
}重啓logstash就可以了，這樣在kibana中就可以看到處理原始日誌內容外，多出了timestamp、level、class、logmessage字段。在做日誌檢索的時候可以根據字段來做匹配，而不需要全文檢索了。logmessage內容比較多，和message字段會有重複。可以把message字段過濾掉。
總結
使用過程中的一個感受是標準規範真的很重要，如果系統開發或運維過程中都是流程化、規範化的話。那麼真的會很舒服，反之就會很難受。以前我沒有注意過，通過接觸學習ELK後發現現有系統上的日誌是很不規範的。不同應用的日誌裏面的模式幾乎都是不一樣的。那麼難道每一個應用我都要寫一套grok正則匹配麼？那肯定是不行的。所以我這方面應該通過更好管理來提高工作的規範標準化。