Kafka-ELK的學習筆記
經常聽說消息隊列啥的?但是,目前在的小公司是不使用這東西的。
所以,還是先看看,瞭解一下是做什麼用的東東!!!!
消息隊列:是分佈式系統中的重要組件,使用消息隊列主要是爲了通過異步處理提高系統性能和削峯、降低系統耦合性。目前使用較多的消息隊列有ActiveMQ,RabbitMQ,Kafka,RocketMQ;
有啥子用處?
-
通過異步處理提高系統性能
-
如上圖,在不使用消息隊列服務器的時候,用戶的請求數據直接寫入數據庫,在高併發的情況下數據庫壓力劇增,使得響應速度變慢。但是在使用消息隊列之後,用戶的請求數據發送給消息隊列之後立即 返回,再由消息隊列的消費者進程從消息隊列中獲取數據,異步寫入數據庫。由於消息隊列服務器處理速度快於數據庫(消息隊列也比數據庫有更好的伸縮性),因此響應速度得到大幅改善。
通過以上分析我們可以得出消息隊列具有很好的削峯作用的功能——即通過異步處理,將短時間高併發產生的事務消息存儲在消息隊列中,從而削平高峯期的併發事務。 舉例:在電子商務一些秒殺、促銷活動中,合理使用消息隊列可以有效抵禦促銷活動剛開始大量訂單湧入對系統的衝擊。如下圖所示:
-
-
降低系統耦合性
-
我們知道如果模塊之間不存在直接調用,那麼新增模塊或者修改模塊就對其他模塊影響較小,這樣系統的可擴展性無疑更好一些。
我們最常見的事件驅動架構類似生產者消費者模式,在大型網站中通常用利用消息隊列實現事件驅動結構。如下圖所示:
利用消息隊列實現事件驅動結構
消息隊列使利用發佈-訂閱模式工作,消息發送者(生產者)發佈消息,一個或多個消息接受者(消費者)訂閱消息。 從上圖可以看到消息發送者(生產者)和消息接受者(消費者)之間沒有直接耦合,消息發送者將消息發送至分佈式消息隊列即結束對消息的處理,消息接受者從分佈式消息隊列獲取該消息後進行後續處理,並不需要知道該消息從何而來。對新增業務,只要對該類消息感興趣,即可訂閱該消息,對原有系統和業務沒有任何影響,從而實現網站業務的可擴展性設計。
消息接受者對消息進行過濾、處理、包裝後,構造成一個新的消息類型,將消息繼續發送出去,等待其他消息接受者訂閱該消息。因此基於事件(消息對象)驅動的業務架構可以是一系列流程。
-
另外爲了避免消息隊列服務器宕機造成消息丟失,會將成功發送到消息隊列的消息存儲在消息生產者服務器上,等消息真正被消費者服務器處理後才刪除消息。在消息隊列服務器宕機後,生產者服務器會選擇分佈式消息隊列服務器集羣中的其他服務器發佈消息。
備註: 不要認爲消息隊列只能利用發佈-訂閱模式工作,只不過在解耦這個特定業務環境下是使用發佈-訂閱模式的。除了發佈-訂閱模式,還有點對點訂閱模式(一個消息只有一個消費者),我們比較常用的是發佈-訂閱模式。 另外,這兩種消息模型是 JMS 提供的,AMQP 協議還提供了 5 種消息模型。
一些問題?
- 系統可用性降低: 系統可用性在某種程度上降低,爲什麼這樣說呢?在加入MQ之前,你不用考慮消息丟失或者說MQ掛掉等等的情況,但是,引入MQ之後你就需要去考慮了!
- 系統複雜性提高: 加入MQ之後,你需要保證消息沒有被重複消費、處理消息丟失的情況、保證消息傳遞的順序性等等問題!
- 一致性問題: 我上面講了消息隊列可以實現異步,消息隊列帶來的異步確實可以提高系統響應速度。但是,萬一消息的真正消費者並沒有正確消費消息怎麼辦?這樣就會導致數據不一致的情況了!
協議JMS vs AMQP
對比方向 | JMS | AMQP |
---|---|---|
定義 | Java API | 協議 |
跨語言 | 否 | 是 |
跨平臺 | 否 | 是 |
支持消息類型 | 提供兩種消息模型:①Peer-2-Peer;②Pub/sub | 提供了五種消息模型:①direct exchange;②fanout exchange;③topic change;④headers exchange;⑤system exchange。本質來講,後四種和JMS的pub/sub模型沒有太大差別,僅是在路由機制上做了更詳細的劃分; |
支持消息類型 |
StreamMessage -- Java原始值的數據流 MapMessage--一套名稱-值對 TextMessage--一個字符串對象 ObjectMessage--一個序列化的 Java對象 BytesMessage--一個字節的數據流 |
byte[](二進制) |
總結:
- AMQP 爲消息定義了線路層(wire-level protocol)的協議,而JMS所定義的是API規範。在 Java 體系中,多個client均可以通過JMS進行交互,不需要應用修改代碼,但是其對跨平臺的支持較差。而AMQP天然具有跨平臺、跨語言特性。
- JMS 支持TextMessage、MapMessage 等複雜的消息類型;而 AMQP 僅支持 byte[] 消息類型(複雜的類型可序列化後發送)。
- 由於Exchange 提供的路由算法,AMQP可以提供多樣化的路由方式來傳遞消息到消息隊列,而 JMS 僅支持 隊列 和 主題/訂閱 方式兩種。
常見組件對比
對比方向 | 概要 |
---|---|
吞吐量 | 萬級的 ActiveMQ 和 RabbitMQ 的吞吐量(ActiveMQ 的性能最差)要比 十萬級甚至是百萬級的 RocketMQ 和 Kafka 低一個數量級。 |
可用性 | 都可以實現高可用。ActiveMQ 和 RabbitMQ 都是基於主從架構實現高可用性。RocketMQ 基於分佈式架構。 kafka 也是分佈式的,一個數據多個副本,少數機器宕機,不會丟失數據,不會導致不可用 |
時效性 | RabbitMQ 基於erlang開發,所以併發能力很強,性能極其好,延時很低,達到微秒級。其他三個都是 ms 級。 |
功能支持 | 除了 Kafka,其他三個功能都較爲完備。 Kafka 功能較爲簡單,主要支持簡單的MQ功能,在大數據領域的實時計算以及日誌採集被大規模使用,是事實上的標準 |
消息丟失 | ActiveMQ 和 RabbitMQ 丟失的可能性非常低, RocketMQ 和 Kafka 理論上不會丟失。 |
總結:
- ActiveMQ 的社區算是比較成熟,但是較目前來說,ActiveMQ 的性能比較差,而且版本迭代很慢,不推薦使用。
- RabbitMQ 在吞吐量方面雖然稍遜於 Kafka 和 RocketMQ ,但是由於它基於 erlang 開發,所以併發能力很強,性能極其好,延時很低,達到微秒級。但是也因爲 RabbitMQ 基於 erlang 開發,所以國內很少有公司有實力做erlang源碼級別的研究和定製。如果業務場景對併發量要求不是太高(十萬級、百萬級),那這四種消息隊列中,RabbitMQ 一定是你的首選。如果是大數據領域的實時計算、日誌採集等場景,用 Kafka 是業內標準的,絕對沒問題,社區活躍度很高,絕對不會黃,何況幾乎是全世界這個領域的事實性規範。
- RocketMQ 阿里出品,Java 系開源項目,源代碼我們可以直接閱讀,然後可以定製自己公司的MQ,並且 RocketMQ 有阿里巴巴的實際業務場景的實戰考驗。RocketMQ 社區活躍度相對較爲一般,不過也還可以,文檔相對來說簡單一些,然後接口這塊不是按照標準 JMS 規範走的有些系統要遷移需要修改大量代碼。還有就是阿里出臺的技術,你得做好這個技術萬一被拋棄,社區黃掉的風險,那如果你們公司有技術實力我覺得用RocketMQ 挺好的
- kafka 的特點其實很明顯,就是僅僅提供較少的核心功能,但是提供超高的吞吐量,ms 級的延遲,極高的可用性以及可靠性,而且分佈式可以任意擴展。同時 kafka 最好是支撐較少的 topic 數量即可,保證其超高吞吐量。kafka 唯一的一點劣勢是有可能消息重複消費,那麼對數據準確性會造成極其輕微的影響,在大數據領域中以及日誌採集中,這點輕微影響可以忽略這個特性天然適合大數據實時計算以及日誌收集。
所以,用RocketMQ 還是 Kafka 呢,畢竟打算用的是Spring Cloud Alibaba的啊 。。。。。
Kafka 介紹
首先是一些概念:
- Kafka作爲一個集羣,運行在一臺或者多臺服務器上.
- Kafka 通過 topic 對存儲的流數據進行分類。
- 每條記錄中包含一個key,一個value和一個timestamp(時間戳)。
Kafka有四個核心的API:
- The Producer API 允許一個應用程序發佈一串流式的數據到一個或者多個Kafka topic。
- The Consumer API 允許一個應用程序訂閱一個或多個 topic ,並且對發佈給他們的流式數據進行處理。
- The Streams API 允許一個應用程序作爲一個流處理器,消費一個或者多個topic產生的輸入流,然後生產一個輸出流到一個或多個topic中去,在輸入輸出流中進行有效的轉換。
- The Connector API 允許構建並運行可重用的生產者或者消費者,將Kafka topics連接到已存在的應用程序或者數據系統。比如,連接到一個關係型數據庫,捕捉表(table)的所有變更內容。
Kafka官方說明的用處
-
但請注意,消費者組中的消費者實例個數不能超過分區的數量。 ???
-
作爲存儲系統
-
可認爲Kafka是一種高性能、低延遲、具備日誌存儲、備份和傳播功能的分佈式文件系統。
-
關於Kafka提交日誌存儲和備份設計的更多細節,可以閱讀 這頁 。
-
用做流處理
-
用做批處理
使用場景
- 日誌收集:一個公司可以用Kafka可以收集各種服務的log,通過kafka以統一接口服務的方式開放給各種consumer,例如hadoop、Hbase、Solr等。
- 消息系統:解耦和生產者和消費者、緩存消息等。
- 用戶活動跟蹤:Kafka經常被用來記錄web用戶或者app用戶的各種活動,如瀏覽網頁、搜索、點擊等活動,這些活動信息被各個服務器發佈到kafka的topic中,然後訂閱者通過訂閱這些topic來做實時的監控分析,或者裝載到hadoop、數據倉庫中做離線分析和挖掘。
- 運營指標:Kafka也經常用來記錄運營監控數據。包括收集各種分佈式應用的數據,生產各種操作的集中反饋,比如報警和報告。
- 流式處理:比如spark streaming和storm
- 事件源
我覺得做:日誌收集,用戶活動跟蹤 這兩個比較可能整合到我目前使用的web項目裏面去。
以下是新浪kafka日誌處理應用案例:轉自(http://cloud.51cto.com/art/201507/484338.htm)
- Kafka:接收用戶日誌的消息隊列
- Logstash:做日誌解析,統一成JSON輸出給Elasticsearch
- Elasticsearch:實時日誌分析服務的核心技術,一個schemaless,實時的數據存儲服務,通過index組織數據,兼具強大的搜索和統計功能
- Kibana:基於Elasticsearch的數據可視化組件,超強的數據可視化能力是衆多公司選擇ELK stack的重要原因
Kafka的使用
其實Kafka的消息隊列系統和項目使用的 Cloud 集羣是分開的。
所以無所謂使用的是Spring Cloud Alibaba 的那一套,Nacos啥的。
Kafka的集羣使用的部署依賴是ZooKeeper 。【ZooKeeper 的集羣也是獨立的】
即使用Alibaba 全家桶的RocketMQ,使用的部署依賴也是單獨的項目-Name Server 而不是 Nacos ,所以無所謂的 ╮(╯_╰)╭
所以,基於Kafka的使用,還是用來試試日誌管理吧。ELK的那一套日誌管理【Filebeat+*Kafka+Logstash+*ElasticSearch+Kibana】
瞭解各個組件的作用
- Filebeat是一個日誌文件託運工具,在你的服務器上安裝客戶端後,filebeat會監控日誌目錄或者指定的日誌文件,追蹤讀取這些文件(追蹤文件的變化,不停的讀)
- Kafka是一種高吞吐量的分佈式發佈訂閱消息系統,它可以處理消費者規模的網站中的所有動作流數據
- Logstash是一根具備實時數據傳輸能力的管道,負責將數據信息從管道的輸入端傳輸到管道的輸出端;與此同時這根管道還可以讓你根據自己的需求在中間加上濾網,Logstash提供裏很多功能強大的濾網以滿足你的各種應用場景
- ElasticSearch它提供了一個分佈式多用戶能力的全文搜索引擎,基於RESTful web接口
- Kibana是ElasticSearch的用戶界面
在實際應用場景下,爲了滿足大數據實時檢索的場景,利用Filebeat去監控日誌文件,將Kafka作爲Filebeat的輸出端,Kafka實時接收到Filebeat後以Logstash作爲輸出端輸出,到Logstash的數據也許還不是我們想要的格式化或者特定業務的數據,這時可以通過Logstash的一些過了插件對數據進行過濾最後達到想要的數據格式以ElasticSearch作爲輸出端輸出,數據到ElasticSearch就可以進行豐富的分佈式檢索了
Filebeat+Kafka 日誌收集
Kafka 安裝默認安裝
默認安裝就可以了,使用的就是官方的教程,照着搞就可以了。
使用版本2.5.0
# Download the 2.5.0 release and un-tar it.
> tar -xzf kafka_2.12-2.5.0.tgz
> cd kafka_2.12-2.5.0
# Start Zookeeper Server used nohup and zookeeper.properties [nothing to change]
nohup bin/zookeeper-server-start.sh config/zookeeper.properties > /u01/kafka/log/zookeeper-log.log 2>&1 &
# Start Kafka Server need change config to listener 9092 port ,otherwise only use localhost。
# e.g:listeners=PLAINTEXT://192.168.1.180:9092
nohup bin/kafka-server-start.sh config/server.properties > /u01/kafka/log/kafka-log.log 2>&1 &
# create new topic
bin/kafka-topics.sh --create --bootstrap-server 192.168.1.180:9092 --replication-factor 1 --partitions 1 --topic xiaohang-test
# query all topic list
bin/kafka-topics.sh --list --bootstrap-server 192.168.1.180:9092
# e.g:
# [root@localhost kafka_2.12-2.5.0]# bin/kafka-topics.sh --list --bootstrap-server 192.168.1.180:9092
# __consumer_offsets
# elk-test
# xiaohang-test
# ok this's all. (~ ̄▽ ̄)~
Filebeat 安裝,監控日誌文件
這個的安裝就也是很簡單的,調整一下輸入輸出的配給就可以了。
版本使用7.7.1 。使用在於Kafka不在同一臺機子裏,是在使用項目的測試環境中。
調整filebeat.yml配置文件
filebeat.inputs:
- type: log
# Change to true to enable this input configuration.
enabled: true
# Paths that should be crawled and fetched. Glob based paths.
paths:
#- /var/log/*.log
- /u01/happyPay/admin/logs/*.log
#- c:\programdata\elasticsearch\logs\*
#============================= Filebeat modules ===============================
filebeat.config.modules:
# Glob pattern for configuration loading
path: ${path.config}/modules.d/*.yml
# Set to true to enable config reloading
reload.enabled: false
# Period on which files under path should be checked for changes
#reload.period: 10s
#==================== Elasticsearch template setting ==========================
setup.template.settings:
index.number_of_shards: 1
#index.codec: best_compression
#_source.enabled: false
#----------------------------- Logstash output --------------------------------
output.kafka:
hosts: ["192.168.1.180:9092"]
topic: xiaohang-test
required_acks: 1
#output.logstash:
# The Logstash hosts
#hosts: ["localhost:5044"]
#================================ Processors =====================================
# Configure processors to enhance or manipulate events generated by the beat.
processors:
- add_host_metadata: ~
- add_cloud_metadata: ~
- add_docker_metadata: ~
- add_kubernetes_metadata: ~
然後啓動就可以了
nohup ./filebeat -e -c filebeat.yml > /u01/Filebeat/log/Filebeat-log.log 2>&1 &
然後就可以 ╮(╯_╰)╭
最後差不多的效果
差不多這個樣子,可以設計一些系統日誌的監控的模型,用來監控各種問題的平率等等。
如果,系統前端app等,有操作埋點的話,也可以用來分析用戶操作的。
各種的參考文章
- https://www.jianshu.com/p/36a7775b04ec
- http://kafka.apache.org/
- https://www.jianshu.com/p/734cf729d77b - Kafka史上最詳細原理總結上
- https://www.jianshu.com/p/acf010e67a19 - Kafka史上最詳細原理總結下
- https://www.w3cschool.cn/apache_kafka/ - W3C教程
- https://www.jianshu.com/p/7c02290bc421 spring cloud alibaba + kafka 問題
- https://www.pianshen.com/article/6287978769/ 一樣的 https://blog.csdn.net/LSY_CSDN_/article/details/105199663
- https://blog.csdn.net/aoxiangzhe/article/details/91045431 使用場景的東西
- Filebeat+*Kafka+Logstash+*ElasticSearch+Kibana 日誌系統搭建博客
- https://blog.csdn.net/sanyaoxu_2/article/details/88671043 一個叫做PP的東東Pinpoint
- https://blog.csdn.net/zxl646801924/article/details/105659481/ RocketMQ的東東
- https://www.jianshu.com/p/2838890f3284 Rocketmq原理&最佳實踐
- ElasticSearch 的官網:https://www.elastic.co/cn/elasticsearch/
- ELK下載地址:https://www.elastic.co/cn/downloads/
- Filebeat本地文件的日誌數據採集器:https://www.jianshu.com/p/0a5acf831409
- 提供的ELK雲盤鏡像:https://blog.csdn.net/weixin_37281289/article/details/101483434
小杭 ୧(๑•̀◡•́๑)૭
2020-06-17
ELK 日誌分析管理
查看小東編寫的文檔:ELK安裝部署 。