1. ELK日志收集架構(gòu)：

image

• 第一層、數(shù)據(jù)采集層

數(shù)據(jù)采集層位于最左邊的業(yè)務(wù)服務(wù)器集群上，在每個業(yè)務(wù)服務(wù)器上面安裝了filebeat做日志收集，然后把采集到的原始日志發(fā)送到Kafka+zookeeper集群上。

• 第二層、消息隊列層

原始日志發(fā)送到Kafka+zookeeper集群上后，會進行集中存儲，此時，filbeat是消息的生產(chǎn)者，kafka作為消息隊列進行存儲消息，存儲的消息可以隨時被消費。

• 第三層、數(shù)據(jù)分析層

Logstash作為消費者，會去Kafka+zookeeper集群節(jié)點實時拉取原始日志，然后將獲取到的原始日志根據(jù)規(guī)則進行分析、清洗、過濾，最后將清洗好的日志轉(zhuǎn)發(fā)至Elasticsearch集群。

• 第四層、數(shù)據(jù)持久化存儲

Elasticsearch集群在接收到logstash發(fā)送過來的數(shù)據(jù)后，執(zhí)行寫磁盤，建索引庫等操作，最后將結(jié)構(gòu)化的數(shù)據(jù)存儲到Elasticsearch集群上。

• 第五層、數(shù)據(jù)查詢、展示層

Kibana是一個可視化的數(shù)據(jù)展示平臺，當有數(shù)據(jù)檢索請求時，它從Elasticsearch集群上讀取數(shù)據(jù)，然后進行可視化出圖和多維度分析。

2. Filebeat：

角色分類：

• Input（新版）/ Prospecto（舊版）：[勘探者]負責管理收割機并找到所要讀取的源，在此處配置源日志路徑。
• Harvester：[收割者]讀取源路徑log文件的內(nèi)容，每個Harvester會逐行讀取各個文件，并將文件內(nèi)容發(fā)送到指定輸出中。Harvester會負責打開和關(guān)閉文件如果文件在收集過程中被刪除或重命名，F(xiàn)ilebeat 會繼續(xù)讀取該文件。這會產(chǎn)生副作用，即磁盤上的空間會被保留，直到收割機關(guān)閉。

Filebeat 如何保持文件狀態(tài)？

• 將文件狀態(tài)記錄在注冊文件中（默認在/var/lib/filebeat/registry）。此狀態(tài)可以記住Harvester收集文件的偏移量。

• 將狀態(tài)刷新到注冊表文件中的磁盤。該狀態(tài)用于記住收割機讀取的最后一個偏移量offset，并確保發(fā)送所有日志行。（注冊表記錄重建狀態(tài)）

• 當輸出無法訪問，filebeat會跟蹤發(fā)送的最后一行，在輸出可以訪問后繼續(xù)讀文件。

• 每個Input為它找到的每個文件保留一個狀態(tài)，前提是Filebeat一直運行。由于文件可以重命名或移動，文件名和路徑不足以識別文件。對于每個文件，F(xiàn)ilebeat 存儲唯一標識符以檢測之前是否收集了文件。

• 如果在收割機關(guān)閉時移動或刪除文件，則 Filebeat 將無法再次拾取該文件，收割機尚未讀取的任何數(shù)據(jù)都將丟失。

Filebeat 如何確保至少一次交付？

• 將每個事件的傳遞狀態(tài)存儲在注冊表文件中( Filebeat 將它收集的每個文件的狀態(tài)存儲在注冊表中)

• 任何發(fā)送到輸出但在 Filebeat 關(guān)閉之前未確認的事件，將在 Filebeat 重新啟動時再次發(fā)送。這可確保每個事件至少發(fā)送一次，（最終可能重復發(fā)送）可通過設(shè)置shutdown_timeout選項將 Filebeat 配置為在關(guān)閉之前等待特定時間，時filebeat在真正關(guān)閉前確認事件已經(jīng)收到。

一些常見codecs處理：

• json：使用json格式對數(shù)據(jù)進行編碼/解碼。
• multiline：將匯多個事件中數(shù)據(jù)匯總為一個單一的行。在此處對日志進行多行處理，防止在logstash處理會導致數(shù)據(jù)損壞。

配置信息（Filebeat只負責收集和多行處理，沒有對日志信息作其他操作）：

Input：輸入類型type、源日志路徑paths、擴展字段（即后續(xù)kafka的topic）fields 。

Output：主機組hosts、主題topic（此時output到kafka）、分片partition.hash 。

3. Kafka：

為什么選擇kafka？

消息傳遞模式分為兩種：點對點傳遞模式、發(fā)布-訂閱模式

• 點對點模式：到達消息隊列的每一條消息只能被消費一次，消費完該條數(shù)據(jù)從消息隊列中刪除，生產(chǎn)者發(fā)送一條消息到queue，只有一個消費者能收到。

• Kafka就是一種發(fā)布-訂閱模式。消息被持久化到一個topic中。與點對點消息系統(tǒng)不同的是，消費者可以訂閱一個或多個topic，消費者可以消費該topic中所有的數(shù)據(jù)，同一條數(shù)據(jù)可以被多個消費者消費，數(shù)據(jù)被消費后不會立馬刪除。

kafka術(shù)語解釋：

• Broker：kafka集群服務(wù)器節(jié)點node，即主機節(jié)點，broker存儲topic的數(shù)據(jù)，（當topic有n個partiton，集群有n個broker，每個broker存該topic的一個partition，其他數(shù)目另外策略）【建議：broker數(shù)大于某topic的paititon數(shù)】

• Topic：發(fā)送到kafka集群的消息一個大類別，邏輯上一個topic的消息保存于一個或多個broker，物理上不同topic(可能是同topic不同partition)的消息分開存儲？？？？

• Partition：topic切分為一個或多個partition，切分提高了kafka的吞吐率。每個partition中的數(shù)據(jù)使用多個segment文件存儲。

• Partition：單個partition中的數(shù)據(jù)是有序的，不同partition間的數(shù)據(jù)丟失了數(shù)據(jù)的順序。如果topic有多個partition，消費數(shù)據(jù)時就不能保證數(shù)據(jù)的順序。在需要嚴格保證消息的消費順序的場景下，需要將partition數(shù)目設(shè)為1。

• Segment：文件存儲單位，直接保存partiton數(shù)據(jù)。

• Producer：broker接收到生產(chǎn)者Producer發(fā)送的消息后，broker將該消息追加到當前用于追加數(shù)據(jù)的segment文件中。生產(chǎn)者也可以指定數(shù)據(jù)存儲的partition。此處生產(chǎn)者Producer是Filebeat。

• Consumer：消費者，對應(yīng)producer生產(chǎn)者。有對應(yīng)的consumer group消費者組，zookeeper會在組變化時進行rebalance。此處的消費者Consumer是Logstash。

• Leader：每個partition有多個副本，其中有且僅有一個作為Leader，Leader是當前負責數(shù)據(jù)的讀寫的partition。

• Follwer：Follower跟隨Leader，所有寫請求都通過Leader路由，數(shù)據(jù)變更會廣播給所有Follower，F(xiàn)ollower與Leader保持數(shù)據(jù)同步。

• 機制：leader失效，follower選舉新leader，通過zookeeper管理集群配置。follower卡住或者同步太慢，把此follower刪掉，重新創(chuàng)建一個新follower。(leader和follwer基于zookeeper實現(xiàn))

• Offset：offset值表示在分區(qū)partition中的位置。

kafka工作機制：

• 每條消費都必須指定它的topic。

• partiton順序?qū)懘疟P，每條消息append到該partiton上。

• kafka的pull模式，concumer消費者必須主動從kafka拉（pull）取數(shù)據(jù)、訂閱數(shù)據(jù)。

• Kafka提供兩種策略刪除舊數(shù)據(jù)。一是基于時間，二是基于Partition文件大小。

• 每個partiton相當于一個文件夾，里面存儲這個partition的消息和索引。超過一個的partiton會失去數(shù)據(jù)的順序。

配置信息：

• 配置文件配置保留數(shù)據(jù)策略log，分區(qū)數(shù)partition，zk監(jiān)聽地址connection，kafka唯一標識碼broker.id。
• 提前在命令行創(chuàng)建寫入kafka的主題topic、分區(qū)數(shù)partition以及副本數(shù)replication-factor。

4. Zookeeper：

功能作用：

在基于 Kafka 的分布式消息隊列中，ZooKeeper 的作用有：broker 注冊、topic 注冊、消費組的控制、producer 和 consumer 負載均衡、維護 partition 與 consumer 的關(guān)系、記錄消息消費的進度以及 consumer 注冊等。

5. Logstash：

內(nèi)部結(jié)構(gòu)圖：

image

角色類型：

• Input ：從kafka集群訂閱消息。（logstash 管道中的每個輸入階段都在自己的線程中運行）
• Filter：過濾器（做正則匹配和加解碼）
• Output：輸出es集群集群

配置信息：

配置input：kafka集群地址，組group id， kafka中的消費主題topics。

配置filter：過濾器，配置json解碼，grok正則，ruby匹配。

配置output：es集群地址,es存放索引。

使用 Grok 正則過濾器例子：

• 原日志格式

55.3.244.1 GET /index.html 15824 0.043

• Grok match匹配

%{IP:client} %{WORD:method} %{URIPATHPARAM:request} %{NUMBER:bytes} %{NUMBER:duration} #格式轉(zhuǎn)換(IP WORD 這些是提前設(shè)定的正則表達式)

• 結(jié)果輸出

client: 55.3.244.1

method: GET

request: /index.html

bytes: 15824

duration: 0.043

6. Elasticsearch（簡稱ES）：

功能作用：

• 一個分布式的實時文檔存儲，每個字段可以被索引與搜索

• 一個分布式實時分析搜索引擎

ES術(shù)語解釋：

• node 節(jié)點：一個運行中的Elasticsearch 實例稱為一個節(jié)點。（分為master節(jié)點，data節(jié)點，client節(jié)點）

• cluster 集群：集群是由一個或者多個擁有相同 cluster.name配置的節(jié)點組成， 它們共同承擔數(shù)據(jù)和負載的壓力。

• shard 分片：分片是數(shù)據(jù)的容器，文檔保存在分片內(nèi)，分片又被分配到集群內(nèi)的各個節(jié)點里。分片 是一個底層的工作單元，它僅保存了全部數(shù)據(jù)中的一部分。它本身就是一個完整的搜索引擎。

• 文檔：它是指最頂層或者根對象, 這個根對象被序列化成 JSON 并存儲到 Elasticsearch 中，指定了唯一 ID。

• 文檔被存儲和索引到分片內(nèi)。應(yīng)用程序是直接與索引而不是與分片進行交互。

• 一個文檔不僅僅包含它的數(shù)據(jù) ，也包含元數(shù)據(jù)—— 有關(guān)文檔的信息。 三個必須的元數(shù)據(jù)元素如下：

_index 索引名

文檔在哪存放 [一個索引應(yīng)該是因共同的特性被分組到一起的文檔集合]

_type 索引類型

文檔表示的對象類別

_id 文檔名

它和 _index 以及 _type 組合就可以唯一確定 Elasticsearch 中的一個文檔，生成一個文檔

• 文檔是不可變的：他們不能被修改，只能被替（當對文檔作修改時底層是生成新文檔，然后做新的索引）

ES集群健康狀態(tài)：

• green

所有的主分片和副本分片都正常運行。

• yellow

所有的主分片都正常運行，但不是所有的副本分片都正常運行。

• red

有主分片沒能正常運行。

(測試：curl -X GET "localhost:9200/_cluster/health?pretty”）

查看 status 字段中展示為 green 、 yellow 或者 red

ES集群內(nèi)部工作操作：

1. 新建、索引和刪除 請求都是寫操作（在主分片上面完成修改之后，被復制到相關(guān)的副本分片）

在客戶端收到成功響應(yīng)時，文檔變更已經(jīng)在主分片和所有副本分片執(zhí)行完成，變更是安全的。

image

2. 取回單個文檔（讀不一定要在主分片讀，可以在副本分片上讀取文檔，負載均衡讀）

image

3. 作為用戶，我們可以將請求發(fā)送到 集群中的任何節(jié)點 ，包括主節(jié)點。 每個節(jié)點都知道任意文檔所處的位置，并且能夠?qū)⑽覀兊恼埱笾苯愚D(zhuǎn)發(fā)到存儲我們所需文檔的節(jié)點

ES集群配置：

• Elasticsearch 默認被配置為使用單播發(fā)現(xiàn)，以防止節(jié)點無意中加入集群。
• ES集群要有同樣的 cluster.name配置，它就會自動發(fā)現(xiàn)集群并加入到其中。 但是在不同機器上啟動節(jié)點的時候，為了加入到同一集群，你需要配置一個可連接到的單播主機列表[discovery.zen.ping.unicast.hosts#設(shè)置集群中master節(jié)點的初始列表，可以通過這些節(jié)點來自動發(fā)現(xiàn)新加入集群的節(jié)點] 。

ES數(shù)據(jù)結(jié)構(gòu)：

• Elasticsearch 使用一種稱為倒排索引的結(jié)構(gòu)。

• 一個倒排索引由文檔中所有不重復詞的列表構(gòu)成，對于其中每個詞，有一個包含它的文檔列表。

• 倒排索引包含一個有序列表，列表包含所有文檔出現(xiàn)過的不重復個體，或稱為 詞項 ，對于每一個詞項，包含了它所有曾出現(xiàn)過文檔的列表。

• 例子：

1. <u>The quick brown fox jumped over the lazy dog</u>
2. <u>Quick brown foxes leap over lazy dogs in summer</u>

Term Doc_1 Doc_2 #維護的文檔列表

Quick | | X

The | X |

brown | X | X

dog | X |

dogs | | X

fox | X |

foxes | | X

in | | X

jumped | X |

lazy | X | X

leap | | X

over | X | X

quick | X |

summer | | X

the | X |

之后在根據(jù)近義詞，大小寫，單復數(shù)等等的相關(guān)性，對文檔列表進行標準化

Term Doc_1 Doc_2 #維護的標準化文檔列表

brown | X | X

dog | X | X

fox | X | X

in | | X

jump | X | X

lazy | X | X

over | X | X

quick | X | X

summer | | X

the | X | X

7. Kibana：

功能作用：

數(shù)據(jù)查詢，數(shù)據(jù)展示，導出數(shù)據(jù)信息

語法：

• url拆分：http_host 域名/upstream_name(服務(wù)名)/具體路徑 #(upstream最終一定能到達)

• url拆分：http_host 域名/request(請求詳情) #(request不一定能全部到達）

• status： 狀態(tài)碼

• x-user-id： 用戶ID

• remote_addr： 遠程IP

• http_x_forwarded_for : 遠程IP

• request_api： 請求的api，不帶參數(shù)

導出不需要統(tǒng)計的數(shù)據(jù)：

Step 1:

image

Step 2:

image

Step 3:

image

注意：從kibana中導出的數(shù)據(jù)有大小限制，此處最大支持導出文件大小500MB,可在配置文件修改maxsize，但是不建議過大，設(shè)置過大值可能會導致kibana服務(wù)器崩潰。

導出統(tǒng)計的數(shù)據(jù)：

image

步驟：visualize--加號（?）----Data----Data Table----new search----選擇檢索的日志（index：ngxlog-public-*）----Metrics(選擇監(jiān)控項)----Buckets(選擇切割方式)