文章目錄
- 1. 前言
- 2. 什麼是ELK?
- 3. ELK的架構
- 4. ELK各元件簡介
-
- 4.1 Beats
- 4.2 Logstash
- 4.3 Elasticsearch
- 4.4 Kibana
- 5. 總結
- 參考
本文中的圖多來源于網際網路。
1. 前言
傳統的日志分析場景
直接在日志檔案中
grep
、
awk
就可以獲得自己想要的資訊。但在規模較大的場景中,此方法效率低下,面臨如下問題:
- 日志量太大如何歸檔?
- 文本搜尋太慢怎麼辦?
- 如何多元度查詢?
- 等等
解決上面的問題,需要
集中化的日志管理
,所有伺服器上的日志收集彙總。常見解決思路是建立集中式日志收集系統,将所有節點上的日志統一收集,管理,通路。
ELK就是解決這些問題的一種解決方案
。
2. 什麼是ELK?
ELK
是三個開源項目的首字母縮寫,這三個項目分别是:
Elasticsearch
、
Logstash
和
Kibana
,這三個是ELK的核心元件,但并非全部。
•
Elasticsearch
是一個搜尋和分析引擎。
•
Logstash
是伺服器端資料處理管道,能夠同時從多個來源采集資料,轉換資料,然後将資料轉發到諸如
Elasticsearch
等“存儲庫”中。
•
Kibana
則可以讓使用者在
Elasticsearch
中使用圖形和圖表對資料進行可視化。
Elastic Stack
是
ELK Stack
的更新換代産品
3. ELK的架構
ELK的常見架構有4種。
-
Logstash -> Elasticsearch -> Kibana
。适合供學習者和小規模叢集使用
優點:搭建簡單,易于上手
缺點:
- Logstash耗費資源較大,運作占用CPU和記憶體高
- 另外沒有消息隊列緩存,存在資料丢失隐患。
-
Beats -> Logstash -> Elasticsearch -> Kibana
。适合大叢集系統的運維日志資料監控和查詢。
優點:
- 可擴充性和靈活性較高
- 解決了Logstash耗費資源大的問題
- 另外沒有消息隊列緩存,存在資料丢失隐患。
-
Logstash agent -> Kafka/Redis -> Logstash server -> Elasticsearch -> Kibana
。适合大叢集系統的運維日志資料監控和查詢。
優點:有消息隊列緩存,解決了資料丢失隐患。
缺點:
- Logstash耗費資源較大,運作占用CPU和記憶體高
-
Beats -> Kafka/Redis -> Logstash -> Elasticsearch -> Kibana
。适合大叢集系統的運維日志資料監控和查詢。
優點:
- 有消息隊列緩存,解決了資料丢失隐患。
- 使用Filebeat代替Logstash agent,耗費資源小
- 架構搭建、配置較複雜,不易上手
4. ELK各元件簡介
4.1 Beats
Beats
是一款輕量型資料采集器,相比
Logstash
占用更少的系統資源。
Beats
是一個免費且開放的平台,集合了多種單一用途資料采集器。它們從成百上千或成千上萬台機器和系統向
Logstash
或
Elasticsearch
轉發資料。
Beats
是作為
agent
安裝在伺服器上,用于将營運資料轉發到
Elasticsearch
。
Elastic
提供了如下Beats來采集資料:
以
Beats
中的
Filebeat
為例進行介紹:
Beats
中的
Filebeat
的工作原理如下圖所示:
啟動Filebeat後,會為我們指定的日志檔案或位置啟動一個或多個
input
。
對于每一個Filebeat所監控的log檔案,Filebeat都會啟動一個
harvester
。每個 harvester 讀取一個log檔案以擷取新内容,并将新日志資料發送到libbeat,libbeat會彙總事件并将彙總的資料發送到你為Filebeat配置的output。
Filebeat主要由兩個元件組成:
和
inputs
harvesters
。
1. input 負責管理harvester和查找所有要讀取的資源。如果input類型為log,則input将查找驅動器上與定義的glob路徑比對的所有檔案,并為每個檔案啟動一個harvester。 每個input都在其自己的Go例程中運作。
2. 一個 harvester 負責讀取一個檔案的内容。harvester 逐行讀取檔案,将内容發送給output。一個檔案會啟動一個harvester。harvester負責打開和關閉檔案,這意味着在harvester運作時檔案描述符保持打開狀态。
3. Filebeat會經常将檔案狀态資訊(如harvester發送到哪一行了),持久化到某注冊檔案中,確定發送所有日志行。
Filebeat
的配置截圖
4.2 Logstash
Logstash是一款開源資料收集引擎。 Logstash可以統一來自不同來源的資料将資料标準化,然後輸出到你選擇的目标位置, 以用于下遊的分析和可視化(如ES,Kibana)。Logstash擁有許多插件,可以處理各式各樣的資料。
資料來源
- 日志和名額資料:擷取各種格式的日志檔案。
- Web:通過HTTP API擷取資料,如健康、性能、名額等資訊。
- 資料存儲和流:各種JDBC接口,消息隊列的資料流。
- 傳感器和物聯網:各種智能裝置資料。
Logstash的組成
:
- inputs(必需)。消費資料源的資料
- outputs(必需)。将資料寫入目标位置。
- filters(可選)。根據你的需要修改資料。
Logstash的示例配置截圖:
4.3 Elasticsearch
Elasticsearch
是目前最常用的全文搜尋引擎。
Elasticsearch
的功能:
- 一個
,每個字段 可以被索引與搜尋分布式的實時文檔存儲
- 一個
分布式實時分析搜尋引擎
- 能勝任上百個服務節點的擴充,并支援
級别的結構化或者非結構化資料PB
什麼是全文檢索
根據百度百科的定義
全文搜尋:是指計算機索引程式通過掃描文章中的每一個詞,對每一個詞建立一個索引,指明該詞在文章中出現的次數和位置,當使用者查詢時,檢索程式就根據事先建立 的索引進行查找,并将查找的結果回報給使用者的檢索方式。
全文搜尋兩個最重要的方面是:
- 相關性(Relevance)。評價查詢和查詢結果間的相關程度,并根據這種相關程度對結果排名的一種能力。
- 分析(Analysis)。将文本塊轉換為有差別的、規範化的token的一個過程。
結構化資料、半結構化資料和非結構化資料
結構化資料:
結構化的資料是指可以使用關系型資料庫表示和存儲,表現為二維形式的資料。一般特點是:資料以行為機關,一行資料表示一個實體的資訊,每一行資料的屬性是相同的。如:日期、時間和數字都是結構化的,他們有精确的格式,我們可以對這些格式進行邏輯操作。
半結構化資料:
半結構化資料是結構化資料的一種形式,它并不符合關系型資料庫或其他資料表的形式關聯起來的資料模型結構,但包含相關标記,用來分隔語義元素以及對記錄和字段進行分層。是以,它也被稱為自描述的結構。如
和
XML
JSON
。
非結構化資料:
半結構化資料是結構化資料的一種形式,它并不符合關系型資料庫或其他資料表的形式關聯起來的資料模型結構,但包含相關标記,用來分隔語義元素以及對記錄和字段進行分層。是以,它也被稱為自描述的結構。
-
搜尋結構化資料:
像MySQL之類的關系型資料庫實作搜尋很簡單,使用對應的
語句進行查詢即可。因為關系型資料庫中存的都是SQL
(格式固定,長度有限的資料)結構化資料
-
搜尋非結構化資料:
針對非結構化資料,有兩種搜尋方法:
1.
順序掃描法(Serial Scanning)
。對每一個文檔從頭看到尾,如果此文檔包含我們查找的字元串,則此文檔為我們要找的檔案。然後依次這樣看下去,知道掃描完所有的文檔。
2.
。将非結構化資料中的一部分資訊提取出來,重新組織,使其變得有一定結構,然後對此有一定結構的資料進行搜尋,進而達到搜尋相對較快的目的。這部分從非結構化資料中提取出的然後重新組織的資訊,我們稱之全文檢索(Full-text Search)
。索引
例如:字典。字典的拼音表和部首檢字表就相當于字典的索引,對每一個字的解釋是非結構化的,如果字典沒有音節表和部首檢字表,在茫茫辭海中找一個字隻能順序掃描。然而字的某些資訊可以提取出來進行結構化處理,比如讀音,就比較結構化,分聲母和韻母,分别隻有幾種可以一一列舉,于是将讀音拿出來按一定的順序排列,每一項讀音都指向此字的詳細解釋的頁數。我們搜尋時按結構化的拼音搜到讀音,然後按其指向的頁數,便可找到我們的非結構化資料——也即對字的解釋。
這種先建立索引,再對索引進行搜尋的過程就叫
。全文檢索(Full-text Search)
提到
Elasticsearch
就不得不說
Lucene
了,因為
Elasticsearch
是建立在全文搜尋引擎庫
Apache Lucene
基礎之上。 。
Lucene
是
Apache
下的一個開源全文檢索引擎工具包。圖檔來自 什麼是全文檢索
但是僅僅隻是一個庫。為了充分發揮其功能,你需要使用
Lucene
并将
Java
直接內建到應用程式中。 更糟糕的是,您可能需要獲得資訊檢索學位才能了解其工作原理。
Lucene
非常 複雜。
Lucene
也是使用
Elasticsearch
編寫的,它的内部使用
Java
做索引與搜尋,但是它的目的是使全文檢索變得簡單, 通過隐藏
Lucene
的複雜性,取而代之的提供一套簡單一緻的
Lucene
。
RESTful API
下面的表中列出的
Elasticsearch
中常遇到的一些概念。
概念 | 描述 | 對應關系型資料庫 |
---|---|---|
文檔(document) | 一個JSON對象 | row,一行 |
文檔中繼資料 | 描述文檔的一些資訊,如_index, _type, _id等。 一個文檔的 、 和 唯一辨別一個文檔。 | / |
索引(名詞) | 一個索引類似于關系型資料庫的一個庫 | 庫 |
索引(動詞) | 索引一個文檔,即存儲一個文檔到一個索引(名詞) | INSERT |
類型(type) | 類型 在 Elasticsearch 中表示一類相似的文檔 | 表 |
反向索引 | 一個反向索引由文檔中所有不重複詞的清單構成,對于其中每個詞,有一個包含它的文檔清單。 | B樹索引 |
屬性 | 一列,即字段 | |
映射(mapping) | 映射, 就像資料庫中的 schema ,描述了文檔可能具有的字段或 屬性 、每個字段的資料類型—比如 string, integer 或 date —以及Lucene是如何索引和存儲這些字段的。 | 表結構(schema) |
分片(shard) | 在建立一個索引時可以指定分成多少個分片來存儲。每個分片本身也是一個功能完善且獨立的“索引”,可以被放置在叢集的任意節點上。分片的好處:允許我們水準切分/擴充容量,可在多個分片上進行分布式的、并行的操作,提高系統的性能和吞吐量。分片是最小底層工作單元,實際是一個 執行個體。 主分片的數量決定了索引能儲存的最大資料量。 在索引建立後不能修改 | / |
副本(replica) | 即副分片 | / |
叢集(cluster) | 多個協同工作的節點的集合就是一個叢集。 端口用于 接口, 端口用于叢集件通信(使用的 協定,效率高于 協定。) | / |
節點(node) | 一個節點就是一個ES執行個體,每個節點都可以: 、 、 | / |
分析(analysis) | 分析 包含下面的過程: 首先,将一塊文本分成适合于反向索引的獨立的 詞條 , 之後,将這些詞條統一化為标準格式以提高它們的“可搜尋性”,或者 recall | / |
分析器(analyzer) | 分析器執行分析工作,它分為三個子功能: 、 、 | / |
查詢DSL | / | SQL |
GET http://… | 檢索文檔 | SELECT * FROM 表名 |
PUT http://… | 更新文檔 | UPDATE 表名 SET … |
DELETE http://… | 删除文檔 | DELETE … |
4.4 Kibana
Kibana界面如下圖所示:
在Kibana中有許多功能如下圖列出的這些:
Kibana常用的功能是:
Discovery
、
Visualizations
和
Dashboard
。
在Discovery中可以選擇,展示不同index pattern的資料;也可以通過KQL查詢資料;還可以添加filter對資料過濾。如下圖所示:
Visualizations中,可以繪制各種類型的圖表,如圖中的Type所示,有許多圖表類型。這裡繪制完成的圖,最終可以整合到Dashboard中。如下圖所示:
Dashboard是将多個次元繪制的多個圖表,展示在同一螢幕中,友善從多個角度對資料進行分析。如下圖所示:
建構Dashboard的過程
- 将資料加載到Elasticsearch中
- 定義一個index pattern 來連接配接Elasticsearch
- 發現和探索資料
- 可視化資料
- 将可視化添加到dashboard
目前,正式版Kibana中沒有告警相關功能,測試版中才有。
5. 總結
ELK
或者說
Elastic Stack
是一種日志分析的解決方案,它有多個開源元件組成,每個開源元件都有很多值得學習的地方,本文也沒法都寫上(目前,我也沒這個實力)。本文就是對
ELK
做個科普,有興趣的直接去官網上看官方文檔并實操吧。
參考
[1] elastic官網
[2] 全文搜尋引擎 Elasticsearch 入門教程
[3] 什麼是全文檢索
[4] 結構化資料、半結構化資料和非結構化資料
[5] Elasticsearch: 權威指南
[6] Lucene官方文檔
[7] Elasticsearch的基本概念及工作流程
[8] 終于有人把Elasticsearch原理講透了!