前言
收集日誌的方式很多，本片主要講述ELK方案，其他方案如
採用Apache的成熟組件Flume和Kafka來實現這一套日誌採集系統，並使用HDFS來做數據存儲。
參考鏈接：https://blog.csdn.net/dada_1036/article/details/50814889
爲什麼使用ELK
傳統意義上，ELK是作爲替代Splunk的一個開源解決方案。Splunk 是日誌分析領域的領導者。日誌分析並不僅僅包括系統產生的錯誤日誌，異常，也包括業務邏輯，或者任何文本類的分析。而基於日誌的分析，能夠在其上產生非常多的解決方案，譬如：
- 問題排查。我們常說，運維和開發這一輩子無非就是和問題在戰鬥，所以這個說起來很樸實的四個字，其實是沉甸甸的。很多公司其實不缺錢，就要穩定，而要穩定，就要運維和開發能夠快速的定位問題，甚至防微杜漸，把問題殺死在搖籃裏。日誌分析技術顯然問題排查的基石。基於日誌做問題排查，還有一個很帥的技術，叫全鏈路追蹤，比如阿里的eagleeye 或者Google的dapper，也算是日誌分析技術裏的一種。
- 監控和預警。 日誌，監控，預警是相輔相成的。基於日誌的監控，預警使得運維有自己的機械戰隊，大大節省人力以及延長運維的壽命。
- 關聯事件。多個數據源產生的日誌進行聯動分析，通過某種分析算法，就能夠解決生活中各個問題。比如金融裏的風險欺詐等。這個可以可以應用到無數領域了，取決於你的想象力。
- 數據分析。 這個對於數據分析師，還有算法工程師都是有所裨益的。
基於市場流行度、海量數據的處理功能豐富度、開源等特性，我們選擇了使用elk Stack這套技術棧
ELK Stack 簡介
ELK 不是一款軟件，而是 Elasticsearch、Logstash 和 Kibana 三種軟件產品的首字母縮寫。這三者都是開源軟件，通常配合使用，而且又先後歸於 Elastic.co 公司名下，所以被簡稱爲 ELK Stack。根據 Google Trend 的信息顯示，ELK Stack 已經成爲目前最流行的集中式日誌解決方案。
Elasticsearch：分佈式搜索和分析引擎，具有高可伸縮、高可靠和易管理等特點。基於 Apache Lucene 構建，能對大容量的數據進行接近實時的存儲、搜索和分析操作。通常被用作某些應用的基礎搜索引擎，使其具有複雜的搜索功能；
Logstash：數據收集引擎。它支持動態的從各種數據源蒐集數據，並對數據進行過濾、分析、豐富、統一格式等操作，然後存儲到用戶指定的位置；
Kibana：數據分析和可視化平臺。通常與 Elasticsearch 配合使用，對其中數據進行搜索、分析和以統計圖表的方式展示；
Filebeat：ELK 協議棧的新成員，一個輕量級開源日誌文件數據蒐集器，基於 Logstash-Forwarder源代碼開發，是對它的替代。在需要採集日誌數據的server上安裝 Filebeat，並指定日誌目錄或日誌文件後，Filebeat就能讀取數據，迅速發送到 Logstash 進行解析，亦或直接發送到 Elasticsearch 進行集中式存儲和分析。
更多ELK Stack介紹看集中式日誌系統 ELK 協議棧詳解
ELK 常用架構及使用場景介紹
1、 logstash -> elasticsearch -> kibana
2、 filebeats -> elasticsearch -> kibana
3、 logstash -> 消息隊列(kafka/redis) -> logstash -> elasticsearch -> kibana
4、 filebeats -> logstash -> elasticsearch -> kibana
5、 filebeats -> 消息隊列(kafka/redis) -> logstash -> elasticsearch -> kibana
選型對比
| 屬性\類型 | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| 過濾方式 | logstash | elasticsearch Ingest | logstash | logstash | logstash |
| 過濾能力 | 強 | 一般 | 強 | 強 | 強 |
| 採集速度 | 一般 | 快 | 一般 | 快 | 快 |
| 採集後傳輸速度 | 一般 | 快 | 很快 | 一般 | 很快 |
| 日誌規模 | 較小 | 大 | 海量 | 大 | 海量 |
| 框架重量級 | filebeat輕量級 | logstash較重 | logstash較重 | filebeat輕量級 | filebeat輕量級 |
| 採集源機器cpu、內存消耗 | 大 | 小 | 大 | 小 | 小 |
| 處理機器cpu、內存消耗 | 大 | 大 | 大 | 大 | 大 |
| 安裝複雜度 | 4 | 4 | 6 | 5 | 6 |
| 拓展性 | es集羣 | es集羣 | 消息隊列、es、logstash集羣 | es、logstash集羣 | 消息隊列、es、logstash集羣 |
| 安全性 | 8 | 8 | 6 | 7 | 6 |
| 穩定性 | 8 | 7 | 7.5 | 8 | 7 |
| 應急能力 | 8 | 8 | 8 | 8 | 8 |
| 流行度 | 1 | 5 | 6.5 | 6.5 | 8 |
選型一、
這種架構非常簡單，使用場景也有限。適合單臺測試機器查看和分析日誌使用。
這種架構的擴展，把一個 Logstash 數據蒐集節點擴展到多個，分佈於多臺機器，將解析好的數據發送到 Elasticsearch server 進行存儲，最後在 Kibana 查詢、生成日誌報表等。詳見圖 2
這種結構因爲需要在各個服務器上部署 Logstash，而它比較消耗 CPU 和內存資源，所以比較適合計算資源豐富的服務器，否則容易造成服務器性能下降，甚至可能導致無法正常工作。
選型二、
這種架構引入 Beats 作爲日誌蒐集器。
Beats 將蒐集到的數據發送到 Logstash，經 Logstash 解析、過濾後，將其發送到 Elasticsearch 存儲，並由 Kibana 呈現給用戶。詳見圖 3。
這種架構解決了 Logstash 在各服務器節點上佔用系統資源高的問題。相比 Logstash，Beats 所佔系統的 CPU 和內存幾乎可以忽略不計。另外，Beats 和 Logstash 之間支持 SSL/TLS 加密傳輸，客戶端和服務器雙向認證，保證了通信安全。
因此這種架構適合對數據安全性要求較高，同時各服務器性能比較敏感的場景。
選型三、
這種架構適合於日誌規模比較龐大的情況。但由於 Logstash 日誌解析節點和 Elasticsearch 的負荷比較重，可將他們配置爲集羣模式，以分擔負荷。引入消息隊列，均衡了網絡傳輸，從而降低了網絡閉塞，尤其是丟失數據的可能性，但依然存在 Logstash 佔用系統資源過多的問題。
選型四、
基於 Filebeat 的 ELK 集羣架構
選型四解決了logstash資源佔用過多的問題，日誌龐大的情況下主要壓力在於logstash，較多的日誌文件網絡傳輸也可能導致日誌服務器的文件系統填滿，可以引入消息隊列。見選型五。
選型五、
因爲免費的 ELK 沒有任何安全機制，所以這裏使用了 Nginx 作反向代理，避免用戶直接訪問 Kibana 服務器。加上配置 Nginx 實現簡單的用戶認證，一定程度上提高安全性。另外，Nginx 本身具有負載均衡的作用，能夠提高系統訪問性能。
當前選型
以上五種選型中其實主要區別在於：logstash和filebeat的選用，是否引入消息隊列，以及是否引入es和logstash集羣
綜合主要考慮有以下：
-
相比 logstash，fileBeat做採集功能更加輕量化，相比 Logstash，Beats 所佔系統的 CPU 和內存幾乎可以忽略不計。根據相關測試數據，8線程8GB內存下，logstash常駐內存660M（JAVA），filebeat常駐內存不到30M（GO）。
-
官方推薦使用filebeat替代logstash做採集功能。
-
filebeat 也會和 logstash 一樣記住上次讀取的偏移。
-
5.x 開始，Elasticsearch 具有解析的能力（像 Logstash 過濾器）— Ingest。這也就意味着可以將數據直接用 Filebeat 推送到 Elasticsearch。
-
filebeat的日誌解析功能仍然不夠強大，還需要logstash做採集後的日誌處理
-
隨着日誌量的增大，文件存儲和傳輸對於服務器內存和帶寬影響大，則需要把數據先推到消息隊列，減少採集端服務器文件存儲和內存壓力，同時引入集羣部署，
-
行業流行度看，filebeat支持消息隊列之後，更多的公司使用filebeat結合消息隊列的集羣方式實現。
-
對於安全性和角色的控制，需要使用nginx反向代理實現角色和權限控制
綜合以上比對和分析
- 測試系統採用了選型一和選型二：因爲單臺機器日誌收集和應用部署都在同一臺機，對於測試系統本機使用了logstash，對於推送到網絡組elk集羣的日誌，使用了filebeat。
- 網絡組elk集羣，將使用方案四或五：應用服務器部署filebeat，推送至集羣的logstash機器，目前數據量小，是否引入消息隊列取決於網絡組的考慮，對於集羣中使用logstash，因爲elasticsearch的日誌過濾功能較單一，且同樣存在性能開銷，所以仍需要logstash做數據處理才能滿足日誌過濾。
- 對於生產系統，則建議採用方案五
版本選擇
各個版本及更新時間：
https://www.elastic.co/cn/downloads/past-releases#elasticsearch
es 5到7的版本變動，最大是type的變動
- 5.x 支持多種type
- 6.x 只能有一種type
- 7.x 將去除type 沒有類型的概念了
考慮使用比較穩定的5./6.，或者7.*
目前測試系統使用了5.6.12和最新版7.4.2，運行中使用7.。
網絡組es集羣當前使用7.。
elasticsearch和jdk版本
版本向下兼容，但是對不上的話會有很多異常警告，有些功能運用過程中會失敗，需要配置文件中配置好對應的版本
參考文檔
https://www.csdn.net/gather_24/MtTaYgxsOTYyNy1ibG9n.html
https://www.ibm.com/developerworks/cn/opensource/os-cn-elk-filebeat/
https://blog.upx8.com/2320
http://www.51niux.com/?id=203
https://www.elastic.co/cn/blog/elasticsearch-7-4-0-released
https://www.csdn.net/gather_24/MtTaYgxsOTYyNy1ibG9n.html
https://www.elastic.co/cn/downloads/past-releases#elasticsearch
https://www.csdn.net/gather_24/MtTaYgxsOTYyNy1ibG9n.html
https://blog.csdn.net/u010871982/article/details/79035317/
https://blog.csdn.net/cgs666/article/details/84206025
https://www.cnblogs.com/jingmoxukong/p/8185321.htm