Elasticsearch 5.0和ELK/Elastic Stack指南

這篇文章是一步一步的使用指南，介紹瞭如何結合使用Elasticsearch和其他ELK技術棧（現在叫Elastic Stack）來傳送、解析、儲存和分析日誌。在這個指南里我會使用：

• Filebeat：用於收集日誌（注意：日誌裡包括的資訊還可能有指標、SQL事務記錄和其他的Beat能收集的資訊源）。

• Logstash：用於處理日誌和指標，並把他們轉變成結構化的事件，以便於Elasticsearch進行索引處理。

• Kibana：用於對儲存在Elasticsearch裡的結構化資料做視覺化展現。

在這裡，我會使用Apache的訪問日誌作為例子。但你從這篇文章裡所獲得的知識可以讓你運用於其他型別的日誌。文章最後我們會看看對這樣的系統擴充套件到生產級別所面臨的挑戰，無論是你自己幹還是使用第三方提供的ELK/Elastic Stack。

安裝和配置Elasticsearch、Kibana和Filebeat。

Elasticsearch

Elasticsearch是一個Java應用，所以你需要安裝最新版的JDK（Oracle的或是Ubuntu 16.04上的OpenJDK）。在Ubuntu 16.04版裡，你可以用下面的命令安裝OpenJDK 8。

sudo apt-get install openjdk-8-jdk

如果你用的是RPM/DEB的Linux，我推薦下面這個官方包。文章裡會用APT資源庫來獲得5.x版本。

wget -qO – https://packages.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add –

echo “deb https://artifacts.elastic.co/packages/5.x/apt stable main” | sudo tee -a /etc/apt/sources.list.d/elasticsearch-5.x.list

sudo apt-get update && sudo apt-get install elasticsearch

在啟動Elasticsearch（命令是sudo service elasticsearch start）前，你需要決定給它分配多少記憶體。這可以通過修改/etc/elasticsearch/jvm.options檔案裡面的-Xms和-Xmx值來確定。經驗法則是一開始使用伺服器總記憶體的一半來配置這兩個值，這樣剩下的一半記憶體可以被作業系統用於快取。以後可以通過監控Elasticsearch的heap使用情況以及根據IO吞吐量的需求再調整這兩個值。

Kibana

Kibana可以通過使用Elasticsearch同一個APT資源庫來獲取並安裝。

sudo apt-get install kibana

sudo service kibana start

Filebeat

同樣，我們還是使用同一個APT資源庫來安裝Filebeat。

sudo apt-get install filebeat

預設地Filebeat 5.0會向Elasticsearch推送一個模版。對於大多數的應用場景，這個模版都可以配置與filebeat*模式相匹配的索引。例如，大部分的字串都會被作為關鍵字索引起來，從而能很好地為分析（Kibana的視覺化）所用。message欄位會作為文字被索引，從而能被用來做全文字搜尋（Kibana的Discover分頁）。對應於Apache的日誌檔案，你需要通過配置filebeat.prospectors（裡面的第一個prospector定義為：input_type: log）裡面的paths（路徑）變數來把Filebeat指向它們。你需要用如下方式來定義這個路徑：

paths:

– /var/log/apache.log

然後啟動Filebeat。你的日誌應該開始被匯入了：

sudo service filebeat start

在Kibana裡對日誌進行視覺化展現

到這裡，你可以在瀏覽器裡開啟Kibana（預設埠是5601）來檢視Elasticsearch裡的日誌了。首先你需要通過定義一個“索引模式”來指示被搜尋的索引。把它設成filebeat-*:

圖1 圖片由Radu Gheorghe友情授權使用

接著你可以去Discover皮膚並搜尋日誌。例如，你採用與grep類似的方式搜尋日誌的內容，但也會有一樣的缺陷。比如，如果你搜尋“200”，你就無法確定是“200 OK”響應還是“200 bytes”被傳送。

圖2 圖片由Radu Gheorghe友情授權使用

需要視覺化時，你可以進入Visualize分頁並按主機名區分顯示。但是同樣的，你也無法使用message欄位裡的資訊，因為它裡面的不同的部分（比如響應編碼）還沒有被解析為它們自己的欄位：

圖3 圖片由Radu Gheorghe友情授權使用

使用Logstash解析資料

為了能全面地探索你的日誌資料，你需要一個能解析它們的工具。Logstash就是這樣一個工具。在Elasticsearch 5.0版裡，你可以使用一個Elasticsearch的“消化節點”來進行這一處理，它能帶來效能的顯著提升。但是消化管道並不能為Logstash提供靈活性（例如條件）。所以在這個文章裡我們會只會關注Logstash。

為了構建Filebeat -> Logstash -> Elasticsearch -> Kibana的管道，你需要安裝和配置Logstash，並更新Filebeat的配置選項來讓它從原來指向Elasticsearch改為指向Logstash。讓我們一步一步地完成這個過程：

首先用相同的資源庫來安裝Lostash：

sudo apt-get install logstash

隨後在/etc/logstash/conf.d/資料夾裡建立一個檔案（比如說logstash.conf）。在這個檔案裡設定一個beats input讓Filebeat來連線。接著你可以使用grok filter來解析你的資料，然後再傳送給Elasticsearch。

input {

beats {

port => 5044

}

}

filter {

grok {

match => [ “message”, “%{COMMONAPACHELOG}” ]

}

}

output {

elasticsearch {

hosts => “localhost:9200”

}

}

在Filebeat裡，你需要註釋掉整個output.elasticsearch小節，並把output.logstash下面的hosts配置修改為Logstash的地址：

### Logstash as output

logstash:

# The Logstash hosts

hosts: [“localhost:5044”]

為了能讓Filebeat通過Logstash來重發日誌資料，你需要做以下幾個動作：

• 先停掉Filebeat（sudo service filebeat stop）。

• 刪除註冊檔案。Filebeat在這個檔案裡記錄了它原來指向的Apache日誌。這個動作讓Filebeat完全重啟：sudo rm /var/lib/filebeat/registry

• 刪除Elasticsearch裡面已經索引的資料：curl -XDELETE localhost:9200/filebeat*

• 最後啟動Logstash和Filebeat：sudo service logstash start; sudo service filebeat start

現在你的日誌應該已經被Elasticsearch再次索引了。只是這次它們是結構化的，並且預設是存在索引logstash-*下面。Logstash使用了一個與Filebeat類似的模版，所以目前你還不用操心它的配置。

再去看一下Kibana。你需要在Settings分頁下新建一個索引模式，並配置logstash-*指向索引。你可能也想把這個模式設為預設的。

圖4 圖片由Radu Gheorghe友情授權使用

因為現在Apache的日誌已經是結構化的了，所以你可以搜尋指定的欄位。比如這個response欄位：

圖5 圖片由Radu Gheorghe友情授權使用

你也可以構建視覺化圖來檢視不同型別的響應時間隨時間變化的情況：

圖6 圖片由Radu Gheorghe友情授權使用

從概念驗證到生產系統

如你所見，Elastic Stack的入門是相當得簡單明瞭。不過想把它用於生產環境的資料則需要做更多的工作。

在資料收集側，Logstash可能會成為瓶頸，除非你能把它擴充套件部署到很多節點，或是單機多節點。還有其他的備選方案。比如你可以使用rsyslog。它也很快還是輕量級的。你可以很容易地把它裝在每個Web伺服器上，讓它完成解析和直接傳送資料到Elasticsearch的任務。不過，不同的傳送者用不同的特徵集合。在我們這個場景裡，rsyslog允許配置rulesets來使用不同的通道傳送訊息，但GeoIP預設是不支援這個功能的。

在Elasticsearch一側，為了實現容錯以及處理更多的日誌，你需要為叢集加入更多的節點。你需要在elasticsearch.yml裡做一些修改來實現這個目標。

實現容錯

首先定義discovery.zen.ping.unicast.hosts，這樣節點間才能相互知道其他的節點的存在，從而形成一個叢集。生產環境至少需要3個節點。這樣即使一個節點掛了，其他的節點還是能形成一個仲裁組。想定義仲裁組的大小，可以設定discovery.zen.minimum_master_nodes為NUMBER_OF_NODES/2+1。最後，你可以通過設定network.host來讓Elasticsearch監聽外部介面（而不是監聽預設的localhost地址）。這樣就能讓Filebeat、Logstash、Elasticsearch、Kibana和你的瀏覽器執行在不同的機器上。

對於包括更多節點的叢集的配置或是對已有叢集的調優則會要求你對Elasticsearch的工作方式有更深的理解。O’Reilly的培訓視訊《使用Elasticsearch》只有3個小時長，但會提供給你所有需要知道的關於如何配置和管理Elasticsearch的足夠資訊。視訊內容針對日誌和其他的應用場景，例如社交媒體分析和內容搜尋等。

自建還是購買

自建Elastic Stack可以讓你對Elasticsearch有更多的掌控，包括何時升級、安裝什麼外掛以及如何與其他的在用的技術（如資料庫、資料處理工具等）相整合。缺點則是要花很多時間、精力和投資來進行日常維護、升級、調優，以及在基礎的ELK/Elastic Stack上開發各種各樣你需要的特性。如果自建對你來說不是那麼有吸引力，你還是有一些其他的選擇。

一種選擇是使用雲端的日誌管理服務。這能讓你很快就上生產，節省你在配置和維護Elasticsearch上的時間和投入。這些服務一般包括監控、備份和升級等。

如果你想自建Elastic Stack，同時還想降低啟動的時間，那就有很多的選擇可供考慮。比如這個O’Reilly的視訊課程、Elasticsearch培訓和ELK/Elastic Stack諮詢服務等。

 

Radu Gheorghe

Radu Gheorghe是Sematext公司的搜尋諮詢師和軟體工程師。作為諮詢師，他與客戶一起基於Elasticsearch或Solr開發搜尋、分析和日誌的解決方案。他也是支援團隊的一員，幫助解決這些解決方案的生產系統裡的問題。作為軟體工程師，他主要貢獻於Logsene、Sematext的日誌SaaS。Radu是《使用Elasticsearch》視訊教程的作者，同時也是《Elasticsearch in Action》的作者之一。