iT邦幫忙

第 12 屆 iT 邦幫忙鐵人賽

DAY 2
0

上一篇簡單的講解了Elastic Stack
今天就來介紹一些常見的架構

All-In-One

這種架構只有一個Logstash、Elasticsearch、Kibana實例,集中部署在同一台服務器,Logstash通過輸入插件(input)獲取數據,再通過過濾插件(filter)整理數據,最後通過輸出插件(output)發送給Elasticsearch,再經由Kibana顯示
數據源 → Logstash(收集、解析) → Elasticsearch(儲存) → Kibana(圖形介面顯示)

Logstash分布式採集

把Logstash搜尋數據節點拓展到多個,分佈到多台機器,將收集好的數據發送給Elasticsearch,最後再經由Kibana顯示,是All-In-One的拓展
數據源 → Logstash(收集、解析) ↘︎
數據源 → Logstash(收集、解析) → Elasticsearch(儲存) → Kibana(圖形介面顯示)
數據源 → Logstash(收集、解析) ↗
這種架構需要在多台主機上部署Logstash,但由於Logstash比較消耗CPU跟記憶體,所以比較適合計算資源比較豐富的時候使用

Beats分布式採集

這種架構使用Beats進行數據收集,目前Beats有很多種例如:Packetbeat(搜集網絡流量數據)、Topbeat(搜集系統、進程和文件系統級別的CPU和內存使用情況等數據)、Filebeat(搜集文件數據)、Winlogbeat(搜集 Windows 事件日誌數據)、Metricbeat(指標)、Auditbeat(審計日誌)、Heartbeat(可用性檢測),收集的數據再發送給Logstash整理、過濾後再發送給Elasticsearch,再經由Kibana顯示
數據源→Beats(收集)↘︎
數據源→Beats(收集)→Logstash(解析) → Elasticsearch(儲存) → Kibana(圖形介面顯示)
數據源→Beats(收集)↗
用Beats這種較輕量的數據收集器代替Logstash進行數據收集就能改善上一種架構中在多台主機部署Logstash較消耗計算資源的問題,同時Beats

引入消息隊列機制的Logstash分布式架構

其實就是Logstash分布式採集架構在加入隊列機制來預防數據丟失的情況,目前Logstash支持Kafka、Redis、RabbitMQ等消息隊列,透過Logstash(收集)輸入插件收集數據再經過輸出插件丟入隊列,Logstash(解析)輸入插件再從隊列獲取數據,經過過濾插件最後讓輸出插件丟到Elasticsearch,最後由Kibana顯示
數據源 → Logstash(收集) ↘︎
數據源 → Logstash(收集) → 隊列 → Logstash(解析) → Elasticsearch(儲存) → Kibana(圖形介面顯示)
數據源 → Logstash(收集) ↗

引入消息隊列機制的beat+Logstash分布式架構

在Beats分布式採集基礎上加上隊列(Redis、Kafka、RabbitMQ)的機制來預防數據丟失的情況,目前有提供的隊列服務的Beats有Metricbeat、Filebeat、Packetbeat,更詳細的資訊可以去官方文件看
https://www.elastic.co/guide/en/beats/libbeat/7.9/getting-started.html
數據源 → Beats(收集) ↘︎
數據源 → Beats(收集) → 隊列 → Logstash(解析) → Elasticsearch(儲存) → Kibana(圖形介面顯示)
數據源 → Beats(收集) ↗

如果文中有寫錯的地方歡迎指正,下篇將針對Elasticsearch做更多的介紹


上一篇
IT鐵人第1天 Elastic Stack簡單介紹
下一篇
IT鐵人第3天 Elasticsearch簡單介紹
系列文
Python&Elasticsearch 入門30

尚未有邦友留言

立即登入留言