一、ELK簡介
ELK分別表示Elasticsearch、Logstash、Kibana，是一套完整的日志收集以及展示的解決方案，新增了一個FileBeat，是一個輕量型的日志收集處理工具，FileBeat占用的資源少，適合在各個服務器上搜集日志后傳輸給Logstash；
二、ELK-B介紹
- Elasticsearch簡稱ES，是一個基于Lucene的、支持全文索引的分布式存盤和索引引擎，提供搜集、分析、存盤資料三大功能，特點是具備分布式、零配置、自動發現、索引自動分片、索引副本機制、restFul風格介面、多資料源、自動搜索負載等，主要負責將日志索引存盤起來，方便業務搜索查詢；
- Logstash是一個具有實時傳輸能力的資料收集引擎，是日志收集、過濾、轉發的中間件，支持大量的資料獲取方式，一般作業方式為C/S架構，client端安裝在需要收集日志的主機上，Server端負責將收到的各節點日志進行過濾、修改等操作在一并發往elasticsearch上去，主要負責將各條業務線的各類日志統一收集、過濾后、轉發給ES進行下一步的處理；
- Kibana提供給了ES和Logstash一個友好的可視化Web界面，可以幫助匯總、分析和搜索重要資料匯總，可以在ES的索引中查找，互動資料，并且生成各種緯度表格；
- FileBeat，是一個輕量級的開源日志檔案資料搜集器，基于Logstash-Forwarder源代碼開發，在需要采集的Server上安裝FileBeat，并且指定日志目錄或者日志檔案后，FileBeat就能讀取資料，迅速發送到Logstash進行決議，也可以直接發送到ES中進行集中式的存盤和分析；
Beats作為日志收集器，使用beats的日志收集器架構，目前beats包括四種：
- Packetbeat（搜集網路流量資料）
- Filebeat（搜集檔案資料）
- Topbeat（搜集系統、行程、檔案系統級別的CPU和記憶體使用情況等資料）
- Winlogbeat（搜集Windows事件的日志資料）
三、ELK解決的問題、功能、用途
A、解決的問題和實作的功能效果
| 問題 | 效果 |
|---|---|
| 開發人員不能完全登錄線上服務器查看詳細日志 | 日志資訊平臺化、方便查看 |
| 微服務架構中各個服務都有日志，日志資料分散難以查找 | 日志集中管理、且經過過濾梳理 |
| 日志資料量大、查詢速度慢、或者資料不夠實時 | 通過底層插件實作資料的快速采集與存盤 |
B、ELK的用途
ELK是一個日志收集分析系統，日志分析并不是僅僅包括系統產生的錯誤日志，例外，也包括業務邏輯，或者任何文本類的分析，而基于日志的分析，能夠在其上產生很多解決方案；
- 問題排查：日志分析技術顯然問題排查的基石，基于日志做問題排查也叫全鏈追蹤；
- 監控與預警：日志，監控，預警是相輔相成的，基于日志的監控，預警使得運維有自己的機械戰隊，大大節省人力以及延長運維的壽命，
- 關聯事件：多個資料源產生的日志進行聯動分析，通過某種分析演算法，就能夠解決生活中各個問題，比如金融里的風險欺詐等，
- 資料分析；
四、與傳統日志處理方案相比，ELK存在的優點
優點
- 處理方式靈活：Elasticsearch是實時全文索引，不需要像storm那樣先編程才能使用；
- 配置簡單上手：Elasticsearch全部采用JSON介面，Logstash是Ruby DSL設計，都是目前業界最通用的配置語法設計；
- 檢索性能高效：雖然每次查詢都是實時計算，但是優秀的設計和實作基本可以達到全天資料查詢的秒級回應；
- 集群線性拓展：不管是Elasticsearch集群還是Logstash集群都是可以線性擴展的；
- 前端操作友好：Kibana友好的Web可視化操作；
其他的解決方案
參考：基于 Sphinx + Google char的， Sphinx 對應ES, Google char 對應 Kibana，
五、ELK架構方式
5.1、Logstash+ES+Kibana
由Logstash分布于各個節點上搜索相關日志、資料，并經過分析、過濾后發送給遠端服務器上的Elasticsearch進行存盤，Elasticsearch將資料以分片的形式壓縮后存盤并提供多種API供用戶查詢、操作，用戶也可以更直觀的通過配置Kibana WebPortal方便對日志查詢，并根據資料生成報表，
優點： 搭建簡單，易上手，
缺點： Logstash消耗資源大，運行占用cpu和記憶體高，另外沒有訊息佇列快取，存在資料丟失隱患，
應用場景： 適合小規模集群使用，
這種結構因為需要在各個服務器上部署 Logstash，而它比較消耗 CPU 和記憶體資源，所以比較適合計算資源豐富的服務器，否則容易造成服務器性能下降，甚至可能導致無法正常作業，
5.2、Logstash+Kafka+ES+Kibana
引入訊息佇列機制，位于各個節點上的Logstash Agent先將資料/日志傳遞給Kafka（或者redis），并將佇列中訊息或資料間接傳遞給Logstash過濾、分析后將資料傳遞給Elasticsearch存盤，最后由Kibana將日志和資料呈現給用戶，因為引入Kafka（或者redis），所以即使遠端Logstash server因故障停止運行，資料將會先被存盤下來，從而避免資料丟失，
優點： 引入訊息佇列機制，均衡了網路傳輸，從而降低了網路閉塞尤其是丟失資料的可能性，
缺點： 依然存在Logstash占用系統資源過多的問題，
應用場景： 適合較大集群方案，
這種架構適合于日志規模比較龐大的情況，但由于 Logstash 日志決議節點和 Elasticsearch 的負荷比較重，可將他們配置為集群模式，以分擔負荷，引入訊息佇列，均衡了網路傳輸，從而降低了網路閉塞，尤其是丟失資料的可能性，但依然存在 Logstash 占用系統資源過多的問題，
Beats還不支持輸出到訊息佇列，所以訊息佇列前后兩端只能是Logstash實體，這種架構使用logstash從各個資料源搜集資料，然后經過訊息佇列輸出到訊息佇列中，目前Logstash支持Kafka、Redis、RabbitMQ等常見的訊息佇列，然后Logstash通過訊息佇列輸入插件從佇列中獲取資料，分析過濾后輸出插件發送到ES中，最后通過Kibana展示；
5.3、FileBeat+LogStash+ES+Kibana
此架構將收集端Logstash替換為FlieBeat，更靈活，消耗資源更少，擴展性更強，同時可配置Logstash和Kibana集群用于支持大集群的運維日志資料監控和查詢，
基于FileBeat的ELK集群架構；
上面架構都包含了ELK，這三種組件不能被替換；
ELK安裝與教程（更多的是ES的）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/396130.html
標籤：其他
上一篇：hive專案實訓