elk產生的場景:
css
在微服務開發過程當中,通常都會利用多臺服務器作分佈式部署,如何可以把分散在各個服務器中的日誌歸集起來作分析處理,是一個微服務服務須要考慮的一個因素。
搭建一個日誌系統
搭建一個日誌系統須要考慮一下一些因素:
利用什麼技術,是本身實現還利用現成的組件
日誌須要定義統一的格式
日誌須要擁有一個錨點來進行全局跟蹤
第一個問題,針對咱們小公司來講,基本沒有本身的研發能力,絕對是選用第三方開源的組件了。ELK配置比較簡單,有現成的UI界面,容易檢索日誌信息,是首選。
第二個問題,利用log4j2定義好統一的日誌格式,利用logstash過濾日誌內容。
第三個問題,全局跟蹤的ID有幾種生產方式,一種是利用UUID或者生成隨機數,一種是利用數據庫來生成sequence number,還能夠經過自定義一個id生成服務來獲取。考慮到自身服務的須要,這裏選用生成隨機數來實現。html
ELK+Filebeat 集中式日誌解決方案詳解
前端
Elasticsearch:分佈式搜索和分析引擎,具備高可伸縮、高可靠和易管理等特色。基於 Apache Lucene 構建,能對大容量的數據進行接近實時的存儲、搜索和分析操做。一般被用做某些應用的基礎搜索引擎,使其具備複雜的搜索功能;java
Logstash:數據收集引擎。它支持動態的從各類數據源蒐集數據,並對數據進行過濾、分析、豐富、統一格式等操做,而後存儲到用戶指定的位置;node
Kibana:數據分析和可視化平臺。一般與 Elasticsearch 配合使用,對其中數據進行搜索、分析和以統計圖表的方式展現;linux
Filebeat:ELK 協議棧的新成員,一個輕量級開源日誌文件數據蒐集器,基於 Logstash-Forwarder 源代碼開發,是對它的替代。在須要採集日誌數據的 server 上安裝 Filebeat,並指定日誌目錄或日誌文件後,Filebeat 就能讀取數據,迅速發送到 Logstash 進行解析,亦或直接發送到 Elasticsearch 進行集中式存儲和分析nginx
在這個章節中,咱們將介紹幾種經常使用架構及使用場景。git
在這種架構中,只有一個 Logstash、Elasticsearch 和 Kibana 實例。Logstash 經過輸入插件從多種數據源(好比日誌文件、標準輸入 Stdin 等)獲取數據,再通過濾插件加工數據,而後經 Elasticsearch 輸出插件輸出到 Elasticsearch,經過 Kibana 展現。詳見圖 1。github
這種架構很是簡單,使用場景也有限。初學者能夠搭建這個架構,瞭解 ELK 如何工做。web
這種架構是對上面架構的擴展,把一個 Logstash 數據蒐集節點擴展到多個,分佈於多臺機器,將解析好的數據發送到 Elasticsearch server 進行存儲,最後在 Kibana 查詢、生成日誌報表等。詳見圖 2。
這種結構由於須要在各個服務器上部署 Logstash,而它比較消耗 CPU 和內存資源,因此比較適合計算資源豐富的服務器,不然容易形成服務器性能降低,甚至可能致使沒法正常工做。
這種架構引入 Beats 做爲日誌蒐集器。目前 Beats 包括四種:
Packetbeat(蒐集網絡流量數據);
Topbeat(蒐集系統、進程和文件系統級別的 CPU 和內存使用狀況等數據);
Filebeat(蒐集文件數據);
Winlogbeat(蒐集 Windows 事件日誌數據)。
Beats 將蒐集到的數據發送到 Logstash,經 Logstash 解析、過濾後,將其發送到 Elasticsearch 存儲,並由 Kibana 呈現給用戶。詳見圖 3。
這種架構解決了 Logstash 在各服務器節點上佔用系統資源高的問題。相比 Logstash,Beats 所佔系統的 CPU 和內存幾乎能夠忽略不計。另外,Beats 和 Logstash 之間支持 SSL/TLS 加密傳輸,客戶端和服務器雙向認證,保證了通訊安全。
所以這種架構適合對數據安全性要求較高,同時各服務器性能比較敏感的場景。
到筆者整理本文時,Beats 還不支持輸出到消息隊列,因此在消息隊列先後兩端只能是 Logstash 實例。這種架構使用 Logstash 從各個數據源蒐集數據,而後經消息隊列輸出插件輸出到消息隊列中。目前 Logstash 支持 Kafka、Redis、RabbitMQ 等常見消息隊列。而後 Logstash 經過消息隊列輸入插件從隊列中獲取數據,分析過濾後經輸出插件發送到 Elasticsearch,最後經過 Kibana 展現。詳見圖 4。
這種架構適合於日誌規模比較龐大的狀況。但因爲 Logstash 日誌解析節點和 Elasticsearch 的負荷比較重,可將他們配置爲集羣模式,以分擔負荷。引入消息隊列,均衡了網絡傳輸,從而下降了網絡閉塞,尤爲是丟失數據的可能性,但依然存在 Logstash 佔用系統資源過多的問題。
前面提到 Filebeat 已經徹底替代了 Logstash-Forwarder 成爲新一代的日誌採集器,同時鑑於它輕量、安全等特色,愈來愈多人開始使用它。這個章節將詳細講解如何部署基於 Filebeat 的 ELK 集中式日誌解決方案,具體架構見圖 5。
由於免費的 ELK 沒有任何安全機制,因此這裏使用了 Nginx 做反向代理,避免用戶直接訪問 Kibana 服務器。加上配置 Nginx 實現簡單的用戶認證,必定程度上提升安全性。另外,Nginx 自己具備負載均衡的做用,可以提升系統訪問性能。
ELK 官網對於每種軟件提供了多種格式的安裝包(zip/tar/rpm/DEB),以 Linux 系列系統爲例,若是直接下載 RPM,能夠經過 rpm -ivh path_of_your_rpm_file
直接安裝成系統 service。之後就可使用 service 命令啓停。好比 service elasticsearch start/stop/status
。很簡單,但缺點也很明顯,就是不能自定義安裝目錄,相關文件放置比較分散。
實際使用中更經常使用是使用 tar 包安裝。每種軟件產品的安裝過程很是類似,因此下面僅以 Elasticsearch 爲例簡述安裝過程。
軟件包
實驗環境中使用的4個軟件包都是5.1.1版本,也能夠到官網http://www.elastic.co/下載最新的版本
環境:
配置hosts兩臺服務器網絡通暢
agent1 安裝es1,agent3安裝es2 作成集羣,後期可能還會用到redis,redis提供的功能至關於kafka,收集logstatsh發來的數據,es從redis中提取數據。
agent1 安裝kibana 作數據展現
agent3安裝logstatsh 作數據收集
filebeat安裝在須要收集日誌的服務器上
爲了安全起見 elasticsearch 5.x默認不能用root啓動,因此 須要用elasticsearch 用戶啓動ES
首先關閉防火牆和Selinux,Redhat7.2關閉防火牆的方法以下
systemctl status firewall
systemctl stop firewalld
systemctl disable firewall
systemctl enable firewall
因爲es logstatsh kibana基於java 開發,因此安裝jdk ,jdk版本不要太低,不然會提醒升級jdk。
安裝elasticsearch(agent1,agent3全都安裝es)
在agent1,agent3上安裝一個大於1.8的jdk版本,而後解壓5.1.1的es的tar.gz
一個 Elasticsearch 集羣中通常擁有三種角色的節點,master、data 和 client。
master:master 節點負責一些輕量級的集羣操做,好比建立、刪除數據索引、跟蹤記錄集羣中節點的狀態、決定數據分片(shards)在 data 節點之間的分佈;
data:data 節點上保存了數據分片。它負責數據相關操做,好比分片的 CRUD,以及搜索和整合操做。這些操做都比較消耗 CPU、內存和 I/O 資源;
client:client 節點起到路由請求的做用,實際上能夠看作負載均衡器。
配置文件中有兩個與集羣相關的配置:
node.master:默認 true。True 表示該節點是 master 節點;
node.data:默認 true。True 表示該節點時 data 節點。若是兩個值都爲 false,表示是 client節點。
一個集羣中不必定有 client 節點,可是確定有 master 和 data 節點。
默認第一個啓動的節點是 master。Master 節點也能起到路由請求和搜索結果整合的做用,因此在小規模的集羣中,無需 client 節點。可是若是集羣規模很大,則有必要設置專門的 client。
logstash是一個管理日誌和事件的工具,你能夠收集它們,解析它們,並存儲它們以供之後使用(例如日誌搜索),logstash有一個內置的web界面,用來搜索你的全部日誌。logstash在部署時有兩種運行模式:standalone和centralized:
* standalone:standalone的意思是全部的事情都在一臺服務器上運行,包括日誌收集、日誌索引、前端WEB界面都部署在一臺機器上。
* centralized:就是多服務器模式,從不少服務器運輸(ship)日誌到一臺總的日誌(collector)服務器上用來索引和查找。
須要注意的是logstash自己並無什麼shipper和collector這種說法,由於不管是運輸日誌的進程仍是聚集總的日誌的進程運行的都是同一個程序,只是使用的配置文件不一樣而已。
elasticsearch:
基於lucene的開源搜索引擎,是一個分佈式的搜索分析系統,主要特色有:realtime data、real time analytics、distributed、high availability、multi-tenancy、fulltext search、document oriented、conflict management、schema free、restful api等等。
kibana3:
可視化日誌和數據系統,做爲WEB前端能夠很容易的和elasticsearch系統結合。kibana有版本2和版本3的區分,版本2採用ruby編寫,部署起來很麻煩,須要安裝不少ruby依賴包(目前網上可能是這個版本的部署),版本3採用純html+css編寫,所以部署起來很方便,解壓即用
最基本的elk
每臺須要被收集的日誌 服務器上安裝Logstash,而後過Logstash將日誌數據流發送給ES服務器,ES服務器將收集到的數據流發送的Kibana,kibana將數據流展現出來
大概就是這樣的原理
Elesticsearch部署
es1的配置:ip地址爲192.168.137.11
[root@agent1 ~]# grep -n '^[a-Z]' /usr/local/elasticsearch-5.1.1/config/elasticsearch.yml
17:cluster.name: my-application
23:node.name: node-2
33:path.data: /var/lib/elasticsearch
37:path.logs: /var/log/elasticsearch
55:network.host: 192.168.137.11
56:network.bind_host: 192.168.137.11
57:network.publish_host: 192.168.137.11
58:http.port: 9201
59:node.master: false
60:node.data: true
61:http.enabled: true
62:http.cors.enabled: true
63:http.cors.allow-origin: "*"
76:discovery.zen.ping.unicast.hosts: ["192.168.137.11","192.168.137.13"]
es2的配置,設置es2爲master節點:ip地址爲192.168.137.13
[root@agent3 ~]# egrep -v "^#|^$" /usr/local/elasticsearch-5.1.1/config/elasticsearch.yml
cluster.name: my-application
node.name: ${HOSTNAME}
node.master: true
node.data: true
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
network.host: 192.168.137.13
network.bind_host: 192.168.137.13
network.publish_host: 192.168.137.13
http.enabled: true
http.cors.enabled: true
http.cors.allow-origin: "*"
http.port: 9200
discovery.zen.ping.unicast.hosts: ["192.168.137.13","192.168.137.11"]
[root@agent3 ~]#
啓動es1
su - elasticsearch
/usr/local/elasticsearch-5.1.1/bin/elasticsearch -d
補充:
默認狀況下,Elasticsearch在前臺運行,將其日誌打印到標準輸出(stdout),並能夠經過按Ctrl-C中止。 要將Elasticsearch做爲daemon運行,請在命令行上指定-d,並使用-p選項將進程ID記錄在文件中:
bin/elasticsearch -d -p pid
日誌消息記錄在$ES_HOME/logs 文件夾中 要關閉Elasticsearch,請刪除pid文件中記錄的進程ID:
kill `cat pid`
或者:
su - elasticsearch -c "/usr/local/elasticsearch-5.1.1/bin/elasticsearch &"
查看java進程
[root@agent1 bin]# ps -ef | grep java
501 5153 5121 0 11:11 pts/1 00:01:53 /usr/local/jdk1.8.0_121//bin/java -Xms2g -Xmx2g -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -server -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true -Djdk.io.permissionsUseCanonicalPath=true -Dio.netty.noUnsafe=true -Dio.netty.noKeySetOptimization=true -Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true -Dlog4j.skipJansi=true -XX:+HeapDumpOnOutOfMemoryError -Des.path.home=/usr/local/elasticsearch-5.1.1 -cp /usr/local/elasticsearch-5.1.1/lib/elasticsearch-5.1.1.jar:/usr/local/elasticsearch-5.1.1/lib/* org.elasticsearch.bootstrap.Elasticsearch
root 6529 5328 0 16:53 pts/4 00:00:00 grep java
查看es1的啓動端口
[root@agent1 bin]# netstat -tulnp | grep java
tcp 0 0 ::ffff:192.168.137.11:9201 :::* LISTEN 5153/java
tcp 0 0 ::ffff:192.168.137.11:9300 :::* LISTEN 5153/java
[root@agent1 bin]#
能夠看到es的9201端口已經啓動
Elasctisearch 節點默認使用 9300 端口尋找集羣,因此必須開啓這個端口。
測試:
在es機器上訪問:
curl 'http://localhost:9200'
curl 'http://localhost:9200/?pretty'
或者在瀏覽器窗口中輸入 http://localhost:9200/?pretty
es1結果以下:
es集羣搭建
集羣的搭建也很是簡單,保證cluster_name一致, node_name不一致就行了,
能夠在同一個網段自動發現新節點,也能夠在配置文件的discovery.zen.ping.unicast.hosts屬性中指定集羣的節點IP;node2的es端口改爲9201
判斷設備的角色
http://192.168.137.13:9200/_cat/master?v
http://192.168.137.11:9201/_cat/nodes?v
*表明master
Logstash部署
一、解壓logstash-5.1.2.tar.gz
tar xvzf logstash-5.1.2.tar.gz
在/usr/local/logstash-5.1.1/config/下建立配置文件logstash-simple.conf
input { stdin { } }
output {
elasticsearch { hosts => ["localhost:9200"] }
stdout { codec => rubydebug }}
三、啓動logstash
bin/logstash -f /usr/local/logstash-5.1.1/config/logstash-simple.conf
四、執行curl http://192.168.137.13:9200/,提示下面的信息說明啓動成功。
Kibana部署
解壓kibana而且安裝和啓動
修改配置文件config/kibana.yml ,在21行左右去掉elasticsearch.url前面註釋
server.port: 5601
server.host: "192.168.137.11"
elasticsearch_url: "http://192.168.137.13:9200"
cd /usr/local/kibana-5.1.1-linux-x86_64 && nohup ./bin/kibana &
經過 http://IP:5601 訪問kibana
curl -XGET 'localhost:9200/_cat/indices?v&pretty' #查看索引
[root@agent3 tmp]# curl -XGET '192.168.137.13:9200/_cat/indices?v&pretty'
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open .kibana QJEp9a-eT2iysoLIg9e6HQ 1 1 1 0 6.3kb 3.1kb
green open twitter OzTyY2dlTL6HcPns4OuCHQ 5 1 1 0 10.1kb 5kb
Elasticsearch5.1.1安裝問題集錦
使用Elasticsearch5.X 必須安裝jdk1.8
問題1:
org.elasticsearch.bootstrap.StartupException: java.lang.RuntimeException:
can not run elasticsearch
as
root
解決方案:
由於安全問題elasticsearch 不讓用root用戶直接運行,因此要建立新用戶
建議建立一個單獨的用戶用來運行ElasticSearch
建立elasticsearch用戶組及elasticsearch用戶
groupadd asticsearch
useradd elasticsearch -g elasticsearch -p elasticsearch
而後修改安裝配置文件
chown elasticsearch:elasticsearch /usr/local/elasticsearch-5.1.1 -R
另外指定的日誌文件和數據文件也須要遞歸修改用戶和組,啓動程序時切換到自定的elasticsearch用戶,./elasticsearch -d在後臺的方式啓動
root 啓動elasticsearch報錯
/bin/elasticsearchException in thread "main" java.lang.RuntimeException: don't run elasticsearch as root. at org.elasticsearch.bootstrap.Bootstrap.initializeNatives(Bootstrap.java:93) at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:144) at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:285) at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:35)
Refer to the log for complete error details.12345671234567
解決方案:
bin/elasticsearch -Des.insecure.allow.root=true
啓動失敗
Exception in thread "main" java.lang.RuntimeException: don't run elasticsearch as root.
解釋:爲「防止attacker 獲取root權限」, 若是是RPM包安裝,會自動建立elastsearch組和elastsearch用戶,設置好密碼,換一個用戶啓動便可
問題2:
使用elasticsearch啓動ES後 又會遇到如下問題
ERROR: bootstrap checks failed
max file descriptors [10240] for elasticsearch process likely too low, increase to at least [65536]
max number of threads [1024] for user [elsearch] likely too low, increase to at least [2048]
max virtual memory areas vm.max_map_count [65530] likely too low, increase to at least [262144]
[2016-11-14T10:22:17,569][INFO ][o.e.n.Node ] [mysteel-node1] stopping ...
[2016-11-14T10:22:17,615][INFO ][o.e.n.Node ] [mysteel-node1] stopped
[2016-11-14T10:22:17,615][INFO ][o.e.n.Node ] [mysteel-node1] closing ...
[2016-11-14T10:22:17,638][INFO ][o.e.n.Node ] [mysteel-node1] closed
max virtual memory areas vm.max_map_count [65530] likely too low,increase to at least [262144]
解決方案:
切換到root用戶
vi /etc/security/limits.conf
添加以下內容:
* soft nofile 65536
* hard nofile 131072
* soft nproc 2048
* hard nproc 4096
vi /etc/security/limits.d/20-nproc.conf
修改以下內容:
* soft nproc 1024
#修改成
* soft nproc 2048
max file descriptors [10240] for elasticsearch process likely too low, increase to at least [655360]
vi /etc/sysctl.conf
添加下面配置:
vm.max_map_count=655360
並執行命令:
sysctl -p
而後,從新啓動elasticsearch,便可啓動成功。
或者直接用命令行臨時的方式進行更改進行修改值:
sysctl -w vm.max_map_count=262144
查看修改結果:
sysctl -a|grep vm.max_map_count
ulimit -Hn
65536
Increase RLIMIT_MEMLOCK, soft limit: XXXXX, hard limit: XXXXX
es爲了性能考慮,推薦關掉swap,並鎖定一部分mem,按照日誌中的指引操做便可
問題3:
外網訪問9200端口系統redhat7.2安裝elasticsearch後本機能夠訪問127.0.0.1:9200,但不能訪問【公網IP:9200】
解決方案
修改配置文件 config/elasticsearch.yml
network.host: 0.0.0.0
http.port: 9200
注意關閉防火牆和selinux
問題4:
cannot allocate memory
解決方案: 虛擬機內存不夠,關掉虛擬機,從新加大內存分配,原先是512M,如今分配到2000M
前輩經驗:
問個問題,ES集羣搭建爲何官方建議3臺或者5臺,2臺哪裏很差?
ES集羣屬於分佈式,分佈式系統默認是3個副本
奇數才能作仲裁,偶數怎麼作仲裁
技術來源於生活
恩,這裏的仲裁怎麼解釋
架設多我的投票,你說偶數投票能有什麼結果
必須投同一或是不一樣意
偶數就會形成腦裂
elasticsearch-head使用
5.X版本 有了x-pack 和cerebro 就夠了
2.X 集羣有配置head 可是咱們幾乎沒用
5.X的集羣 咱們用的x-pack和cerebro
logstash規則學習
logstash是日誌收集、分析組件,啓動須要指點啓動腳本,腳本中定義日誌的input、output已經filter等日誌過濾規則。
2.2.1. input
經常使用的input包括如下:
標準輸入
input {
stdin {}
}
文件輸入
input {
file {
path => "/home/yarn/hadoop-2.5.2/logs/*.log"
type => "hadoop"
codec => multiline {
# Grok pattern names are valid! :)
pattern => "^%{TIMESTAMP_ISO8601} "
negate => true
what => previous
}
}
}
tcp輸入
input {
tcp {
port => 8888
mode => "server"
ssl_enable => false
}
}
syslog輸入
input {
syslog {
port => "514"
}
}
log4j輸入
input {
log4j {
type => "test-log4j"
port => 4560
}
}
說明:使用log4j類型的input須要在log4j配置文件中配置logstash輸出。
log4j.properties:
log4j.rootLogger=DEBUG, logstash
###SocketAppender###
log4j.appender.logstash=org.apache.log4j.net.SocketAppender
log4j.appender.logstash.Port=4560
log4j.appender.logstash.RemoteHost=172.18.84.66
log4j.appender.logstash.ReconnectionDelay=60000
log4j.appender.logstash.LocationInfo=true
log4j.xml 添加如下配置
<appender name="LOGSTASH" class="org.apache.log4j.net.SocketAppender">
<param name="RemoteHost" value="172.18.84.66" />
<param name="ReconnectionDelay" value="60000" />
<param name="LocationInfo" value="true" />
<param name="Threshold" value="DEBUG" />
<param name="Port" value="4560" />
</appender>
把新定義的appender添加到root logger裏面,能夠跟其餘已有logger共存
<appender-ref ref="LOGSTASH" />
2.2.2. output
經常使用的output包括:
標準輸出
output {
stdout {
codec => rubydebug
}
}
輸出到elasticsearch
output {
elasticsearch {
hosts => "xdata66"
}
stdout{
codec => rubydebug
}
}
發送email
output {
email {
to => ""
}
}
2.2.3. 數據處理
grok
...
說明:logstash任務是個agent,能夠在一個節點或者多個節點同時啓動多個agent。
Filebeat 和 ELK 的安裝很簡單,比較難的是如何根據需求進行配置。這個章節選取了幾個比較典型且重要的配置需求和配置方法。
用戶可使用 TLS 雙向認證加密 Filebeat 和 Logstash 的鏈接,保證 Filebeat 只向可信的 Logstash 發送加密的數據。一樣的,Logstash 也只接收可信的 Filebeat 發送的數據。
這個功能默認是關閉的。可經過以下步驟在配置文件中打開:
生成 Filebeat 自簽名證書和 key 文件
由於試驗用,因此這裏使用的都是自簽名證書。如何使用 openssl 生成自簽名證書,網上有不少教程,Elastic github 上也直接提供了參考指令。
openssl req -subj '/CN=hostname/' -x509 -days $((100*365)) -batch -nodes -newkeys rsa:2048 -keyout ./pki/tlk/provate/filebeat.key -out ./pki/tls/certs/filebeat.crt
|
這條指令生成自簽名證書和 key 文件。讀者須要把 hostname 部分改爲實際環境的 hostname,或者是 IP 地址。
生成 Logstash 自簽名證書和 key 文件
命令相似。
Filebeat 配置
首先把 Logstash 的自簽名證書傳送到 Filebeat 所在服務器。而後,對 logstash output 部分的 tls 配置做以下修改:
tls:
## logstash server 的自簽名證書。
certificate_authorities: ["/etc/pki/tls/certs/logstash.crt"]
certificate: "/etc/pki/tls/certs/filebeat.crt"
certificate_key: "/etc/pki/tls/private/filebeat.key"
|
其中:
certificate_authorities:CA 證書,即用來簽署證書的證書。這裏表示配置 Filebeat 使其信任全部由該 CA 證書發行的證書。由於自簽名證書的發行者和證書主體相同,因此這裏直接使用 Logstash 證書使 Filebeat 信任使用該證書的 Logstash server;
certificate & certificate_key:Filebeat 證書和 key 文件。Filebeat 將使用它們向 Logstash server 證實本身的可信身份。
Logstash 配置
同 Filebeat 配置相似,首先把 Filebeat client 上的證書複製到 Logstash server 上,而後做以下修改。
1
2
3
4
5
6
7
8
9
10
|
input {
beats {
port => 5044
ssl => true
ssl_certificate_authorities => ["/etc/pki/tls/certs/filebeat.crt"]
ssl_certificate => "/etc/pki/tls/certs/logstash.crt"
ssl_key => "/etc/pki/tls/private/logstash.key"
ssl_verify_mode => "force_peer"
}
}
|
其中:
ssl:true 表示開啓 Logstash 的 SSL/TLS 安全通訊功能;
ssl_certificate_authorities:配置 Logstash 使其信任全部由該 CA 證書發行的證書;
ssl_certificate & ssl_key:Logstash server 證書和 key 文件。Logstash 使用它們向 Filebeat client 證實本身的可信身份;
ssl_verify_mode:代表 Logstash server 是否驗證 Filebeat client 證書。有效值有 peer 或 force_peer。若是是 force_peer,表示若是 Filebeat 沒有提供證書,Logstash server 就會關閉鏈接。
通俗的說,log rotation 是指當日志文件達到指定大小後,把隨後的日誌寫到新的日誌文件中,原來的日誌文件重命名,加上日誌的起止時間,以實現日誌歸檔的目的。
Filebeat 默認支持 log rotation,但須要注意的是,Filebeat 不支持使用 NAS 或掛載磁盤保存日誌的狀況。由於在 Linux 系列的操做系統中,Filebeat 使用文件的 inode 信息判斷當前文件是新文件仍是舊文件。若是是 NAS 或掛載盤,同一個文件的 inode 信息會變化,致使 Filebeat 沒法完整讀取 log。
雖然 Filebeat 默認支持 log rotation,可是有三個參數的設置須要留意。
registry_file:這個文件記錄了當前打開的全部 log 文件,以及每一個文件的 inode、當前讀取位置等信息。當 Filebeat 拿到一個 log 文件,首先查找 registry_file,若是是舊文件,就從記錄的當前讀取位置處開始讀取;若是是新文件,則從開始位置讀取;
close_older:若是某個日誌文件通過 close_older 時間後沒有修改操做,Filebeat 就關閉該文件的 handler。若是該值過長,則隨着時間推移,Filebeat 打開的文件數量不少,耗費系統內存;
scan_frequency:Filebeat 每隔 scan_frequency 時間讀取一次文件內容。對於關閉的文件,若是後續有更新,則通過 scan_frequency 時間後,Filebeat 將從新打開該文件,讀取新增長的內容。
Elasticsearch 啓動時會根據配置文件中設置的集羣名字(cluster.name)自動查找並加入集羣。Elasctisearch 節點默認使用 9300 端口尋找集羣,因此必須開啓這個端口。
一個 Elasticsearch 集羣中通常擁有三種角色的節點,master、data 和 client。
master:master 節點負責一些輕量級的集羣操做,好比建立、刪除數據索引、跟蹤記錄集羣中節點的狀態、決定數據分片(shards)在 data 節點之間的分佈;
data:data 節點上保存了數據分片。它負責數據相關操做,好比分片的 CRUD,以及搜索和整合操做。這些操做都比較消耗 CPU、內存和 I/O 資源;
client:client 節點起到路由請求的做用,實際上能夠看作負載均衡器。
配置文件中有兩個與集羣相關的配置:
node.master:默認 true。True 表示該節點是 master 節點;
node.data:默認 true。True 表示該節點時 data 節點。若是兩個值都爲 false,表示是 client 節點。
一個集羣中不必定有 client 節點,可是確定有 master 和 data 節點。默認第一個啓動的節點是 master。Master 節點也能起到路由請求和搜索結果整合的做用,因此在小規模的集羣中,無需 client 節點。可是若是集羣規模很大,則有必要設置專門的 client。
日誌數據通常都是非結構化數據,並且包含不少沒必要要的信息,因此須要在 Logstash 中添加過濾插件對 Filebeat 發送的數據進行結構化處理。
使用 grok 正則匹配把那些看似毫無心義、非結構化的日誌數據解析成可查詢的結構化數據,是目前 Logstash 解析過濾的最好方式。
Grok 的用戶不須要從頭開始寫正則。ELK github 上已經寫好了不少有用的模式,好比日期、郵箱地址、IP4/六、URL 等。具體查看這裏。除此以外,還有 grok 正則表達式的debug 工具,能方便快速檢驗所寫表達式是否正確。
下面是一個 grok 的配置實例,讀者能夠適當修改知足你的需求。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
filter {
grok {
match => {
"message" => [
"\[(?<
Logtime
>(%{MONTHNUM}/%{MONTHDAY}/%{YEAR})\s+%{TIME}\s+%{WORD})\]\s+%{BASE16NUM}\s+(?<
LogSource
>([\w|\S]+))\s+%{WORD:LogLevel}\s+(?<
LogStr
>[\w|\W]*)",
"\[(?<
Logtime
>(%{MONTHNUM}/%{MONTHDAY}/%{YEAR})\s+%{TIME}\s+%{WORD})\]\s+%{BASE16NUM}\s+%{WORD:LogLevel}\s+(?<
LogStr
>[\w|\W]*(\\n)+)"
]
}
remove_field => ["message"]
}
if "_grokparsefailure" in [tags] {
grok {
match => ["message", "(?<
LogStr
>[\w|\W]+)"]
remove_field => ["message"]
remove_tag => ["_grokparsefailure"]
add_field => {
LogSource => "-"
LogLevel => "-"
LogTime => "-"
}
}
}
}
|
第一個 grok 列了兩種正則表達式,若是第一種不匹配,則自動使用第二種。若是第二種也沒有匹配,則匹配失敗,log 數據中添加一個"_grokparsefailure"域,代表 grok 匹配失敗了。讀者可根據實際需求決定如何處理匹配失敗的數據。這裏,對於匹配失敗的,將再匹配一次,並給沒有匹配上的域賦予默認值"-",這樣使得日誌數據格式統一,都含有 4 個域:Logtime、LogSource、LogLevel、LogTime,便於後續數據搜索和展現。
關於這部分配置的教程不少,這裏就不贅述了。
若是 Filebeat 所在 server 上運行有多個 application servers,各自有不一樣的日誌目錄,那 Filebeat 如何同時讀取多個目錄,這是一個很是典型的問題。
解決方案:經過配置多個 prospector 就能達到要求。在配置文件的 prospectors 下,每一個"-"表示一個 prospector,每一個 prospector 包含一些配置項,指明這個 prospector 所要讀取的日誌信息。以下所示:
1
2
3
4
5
6
7
8
9
|
prospectors:
-
paths:
- /home/WLPLog/*.log
# 其餘配置項,具體參考 Elastic 官網
-
paths:
- /home/ApacheLog/*.log
# 其餘配置項,具體參考 Elastic 官網
|
仍是上題中提到的場景,Filebeat 雖然能讀取不一樣的日誌目錄,可是在 Logstash 這邊,或者是 Elasticsearch 這邊,怎麼區分不一樣 application server 的日誌數據呢?
解決方案:Filebeat 的配置項 fields 能夠實現不一樣日誌來源的區分。用法以下:
1
2
3
4
5
6
7
8
9
10
11
|
prospectors:
-
paths:
- /home/WLPLog/*.log
fields:
log_source: WLP
-
paths:
- /home/ApacheLog/*.log
fields:
log_source: Apache
|
在 fields 配置項中,用戶能夠自定義域來標識不一樣的 log。好比上例中的"log_source"就是筆者自定義的。如此,從 Filebeat 輸出的 log 就有一個叫作 log_source 的域代表該 log 的實際來源。
咱們知道 Logstash 使用 Elasticsearch 輸出插件就能把數據發送到 Elasticsearch 進行存儲和搜索。Elasticsearch 插件中有個 hosts 配置項說明 Elasticsearch 信息。可是假如是一個 Elasticsearch 集羣,應該怎麼配置 hosts?
解決方案:最簡單的作法是把集羣中全部的 Elasticsearch 節點的 IP 或者是 hostname 信息都在 hosts 中配上(它支持數組)。可是若是集羣比較大,或者是集羣節點變更頻繁的話,還須要維護這個 hosts 值,不太方便。比較推薦的作法是隻配集羣中某個節點的信息,能夠是 client 節點,也能夠是 master 節點或者是 data 節點。由於無論是哪一個節點,都知道該它所在集羣的信息(集羣規模,各節點角色)。這樣,Logstash 與任意節點通訊時都會先拿到集羣信息,而後再決定應該給哪一個節點發送數據輸出請求。
解決方案:當數據存儲在 Elasticsearch 端以後就能夠在 Kibana 上清楚的展現了。首先在瀏覽器上打開 Kibana 頁面。若是使用了 Nginx,就使用 Nginx 配置的 URL;不然就是http://yourhostname:5601。
建立日誌索引。Logstash 發送的數據,默認使用 logstash 前綴做爲數據索引。見圖 7。
點擊 Create,再選擇 Discover 頁面就能看見 Logstash 發送的數據了,如圖 8 所示。
Kibana 具體的使用,好比如何建立日誌 visualization,如何將 visualization 添加到 dashboard,如何在 Kibana 上搜索日誌,這些能夠參考官網。
本文首先簡要介紹了 ELK 協議棧的幾種典型的架構及其使用場景,而後針對 Filebeat 的架構,詳細說明了如何安裝和配置。限於篇幅,同時因爲某些基本配置,官網有詳盡的說明,因此本文只是選取了幾個比較重要,同時官網上說得不是很明確的地方做說明,但願對你們有幫助。
ELK 論壇上有很多內部人士熱心幫忙解答用戶的問題。若是讀者在使用過程當中有不懂的,搜索了好久也找不到答案的問題,能夠在 ELK 論壇尋求幫助。
查看ELK 官方網站,瞭解 ELK+Beats 等產品的介紹;
搜索ELK 論壇,尋找關於 ELK 在實際使用中的問題及解答;
查看文章部署和擴展 ELK,瞭解更多關於如何擴展 ELK 架構的知識;
參考使用 Nginx 實現 Kibana 登錄認證博客,學習如何配置 Nginx 做爲 Kibana 的反向代理,且實現登錄認證;
查閱Filebeat 文檔,系統全面地學習 Filebeat 的安裝配置細節;
查閱Elasticsearch 文檔,系統全面地學習 Elasticsearch 的安裝配置細節;
查閱Logstash 文檔,系統全面地學習 Logstash 的安裝配置細節;
查閱Kibana 文檔,系統全面地學習 Kibana 的安裝配置細節。
博客參考地址:
http://m.blog.csdn.net/article/details?id=51280058
elastic官方文檔
https://www.elastic.co/guide/en/elasticsearch/reference/current/settings.html
https://www.gitbook.com/book/chenryn/elk-stack-guide-cn/details
https://www.elastic.co/guide/en/elasticsearch/reference/master/shard-allocation-filtering.html
https://kibana.logstash.es/content/kibana/v5/source-code-analysis/kbnindex.html 中文 指南