ELK-概念

概念

ELK是Elasticsearch、Logstash、Kibana三大開源框架首字母大寫簡稱。市面上也被成爲Elastic Stack。其中Elasticsearch是一個基於Lucene、分佈式、經過Restful方式進行交互的近實時搜索平臺框架。像相似百度、谷歌這種大數據全文搜索引擎的場景均可以使用Elasticsearch做爲底層支持框架，可見Elasticsearch提供的搜索能力確實強大,市面上不少時候咱們簡稱Elasticsearch爲es。Logstash是ELK的中央數據流引擎，用於從不一樣目標（文件/數據存儲/MQ）收集的不一樣格式數據，通過過濾後支持輸出到不一樣目的地（文件/MQ/redis/elasticsearch/kafka等）。Kibana能夠將elasticsearch的數據經過友好的頁面展現出來，提供實時分析的功能。

經過上面對ELK簡單的介紹，咱們知道了ELK字面意義包含的每一個開源框架的功能。市面上不少開發只要提到ELK可以一致說出它是一個日誌分析架構技術棧總稱，但實際上ELK不只僅適用於日誌分析，它還能夠支持其它任何數據分析和收集的場景，日誌分析和收集只是更具備表明性。並不是惟一性。咱們本教程主要也是圍繞經過ELK如何搭建一個生產級的日誌分析平臺來說解ELK的使用。

日誌管理平臺

在過往的單體應用時代，咱們全部組件都部署到一臺服務器中，那時日誌管理平臺的需求可能並無那麼強烈，咱們只須要登陸到一臺服務器經過shell命令就能夠很方便的查看系統日誌，並快速定位問題。隨着互聯網的發展，互聯網已經全面滲入到生活的各個領域，使用互聯網的用戶量也愈來愈多，單體應用已不可以支持龐大的用戶的併發量，尤爲像中國這種人口大國。那麼將單體應用進行拆分，經過水平擴展來支持龐大用戶的使用迫在眉睫，微服務概念就是在相似這樣的階段誕生，在微服務盛行的互聯網技術時代，單個應用被拆分爲多個應用，每一個應用集羣部署進行負載均衡，那麼若是某項業務發生系統錯誤，開發或運維人員仍是以過往單體應用方式登陸一臺一臺登陸服務器查看日誌來定位問題，這種解決線上問題的效率可想而知。日誌管理平臺的建設就顯得極其重要。經過Logstash去收集每臺服務器日誌文件，而後按定義的正則模板過濾後傳輸到Kafka或redis，而後由另外一個Logstash從KafKa或redis讀取日誌存儲到elasticsearch中建立索引，最後經過Kibana展現給開發者或運維人員進行分析。這樣大大提高了運維線上問題的效率。除此以外，還能夠將收集的日誌進行大數據分析，獲得更有價值的數據給到高層進行決策。

架構圖

下面咱們簡單畫一下利用ELK技術棧搭建日誌管理平臺的最佳架構。

簡單粗暴版架構圖：

 

 

 

上面架構是簡單粗暴的架構，這種架構對數據源服務器性能影響較大，由於Logsash是須要安裝和運行在須要收集的數據源服務器中，而後將收集到的數據實時進行過濾，過濾環節是很耗時間和資源的，過濾完成後才傳輸到ES中。下面是優化後的架構圖：

 

能夠看到，優化後的架構圖中添加了Kafka做爲緩衝存儲做用，運行在數據源的Logstash採集器收集到數據後做爲生產者直接傳輸到Kafka,注意這裏省略了過濾動做，這樣對數據源服務器影響最小，由於Kafka你們都清楚，它的讀寫性能是很是高的。另外一方面，咱們須要獨立部署一個專門消費的Logstash，這個Logstash負責過濾，並將過濾好的數據傳輸到ES，後面依然由Kibana讀取ES數據進行展現。這個架構不但性能好，並且耦合低，而且能夠針對不一樣環節進行平行擴展，在有條件的生產級部署中，強烈推薦第二種部署架構。下面是在新的架構上平行擴展可能演變的架構圖：

 

固然，kafka可能不止兩個節點，而是更多節點，ES也可能集羣分佈式部署更多節點。

本文分享自微信公衆號 - Java軟件編程之家（gh_b3a87885f8f5）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。