devops 日誌處理

elk:elasticsearch kibana l是啥鬼??logstash

一個可落地的日誌處理系統?ELK or 其他????

ELK的模式?

問題:各種工具在日誌系統中起到什麼作用???

 

日誌處理的架構:

即 收集日誌(flume,fluentd,logstash這些)+消息隊列(kafka)+日誌處理(elastic search+kibana,splunk)+其他日誌處理(比如向其他服務提供log數據等),再加上日誌存儲(NFS(網絡文件系統))

 

幾大處理方案:

1.flume+kafka+splunk

2.elk+kafka

最佳實踐經驗:數據收集和轉化的環節,建議使用flume+kafka的配合,爲啥?因爲flume可以以數據流向haddop發送,kafka的緩存比flume的專業,且有自己的分佈式存儲,各有所長。

對比:

https://blog.51cto.com/splunkchina/1948105

https://blog.csdn.net/gyshun/article/details/79710534

 

首先要在服務器上收集日誌,然後把日誌傳送給需要的服務,比如用戶行爲分析服務,比如日誌v存儲服務,比如日誌分析等。基於這些服務,還要考慮中間會不會阻塞導致的數據丟失,於是便有了消息隊列(kafka,redis等)

 

splunk:一個和elk 作爲同款PK的日誌處理平臺,https://blog.51cto.com/splunkchina/1948105

kafka:apache公司的,它的最大的特性就是可以實時的處理大量數據以滿足各種需求場景:比如基於hadoop的批處理系統、低延遲的實時系統、storm/Spark流式處理引擎,web/nginx日誌、訪問日誌,消息服務等等,服務器端的日誌收集工具(比如logstash或者flume等)要配置kafka,接收端也要配置kafka,相當於一箇中轉站,接受來自於收集工具的日誌,緩存併發給下游,這麼做的意義?它是一個流處理平臺

logstash:裝於服務器上,監控,過濾並收集日誌(同時在服務器上安裝logstash agent並在elk機器上安裝logstash index接收)

elastic search:對搜索的日誌處理,存儲

kibana:日誌顯示及圖形化處理

flume:apache公司的,裝於服務器,用於日誌收集,外發,功能同logstash

fluentd: 同flume,但不是apache的

elastic search

logging driver

file base????

Prometheus

syslog  開源,可以把各服務器日誌收集在一起。

 

flume VS fluentd: https://www.slant.co/versus/959/960/~fluentd_vs_flume   

資源 :https://www.fluentd.org/       

 

日誌收集系統  

 

關於elk  https://www.cnblogs.com/JetpropelledSnake/p/9893566.html  

關於elk+kafka  :https://www.cnblogs.com/JetpropelledSnake/p/10057545.html

關於kafka:

https://www.cnblogs.com/likehua/p/3999538.html

https://www.cnblogs.com/likehua/p/3999538.html

 

第一個問題,日誌處理系統的邏輯和流程:

https://mp.weixin.qq.com/s?__biz=MzAwNTM5Njk3Mw==&mid=2247486414&idx=1&sn=4f3cf7506414d46a0cc436d4ae47755f&chksm=9b1c0b4cac6b825a05c1745aa649fc33b61fc4caaaf262a3577c01821ccbbc128d076477cb3e&scene=27#wechat_redirect

https://www.zcfy.cc/article/5-devops-tools-for-logging-and-monitoring

https://www.ibm.com/developerworks/cn/analytics/library/ba-1512-elkstack-logprocessing/index.html

日誌層級:系統日誌、應用程序日誌和安全日誌。首先是日誌收集(工具有:),收集後日志要進行統計和檢索(工具有:)

流程:

  1. 容器日誌實時採集;

  2. 查詢分析和可視化;

  3. 日誌上下文分析;

  4. LiveTail - 雲上 tail -f。

ELK的日誌處理方案:

首先在要收集日誌的服務器上安裝logstash,作爲一個agent開始收集日誌

 

》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》

kafka: apache公司的,一種把日誌處理成流的工具,有緩存機制可以臨時存儲這些log,還可以把日誌分類,比如tomcat的,db的,等等。它叫topic。https://blog.csdn.net/lingbo229/article/details/80761778

kafka的真正作用,同一條消息可能被多個應用消費或使用,不能讓每個消費或應用都去訪問消息產生的服務,這就要有一箇中介,按照topic收集消息,當其他服務需要這些消失時,再主動提供這些消息。這僅僅是基礎,解決了多次重複訪問佔用性能的問題,在此基礎上,它還有一大堆的優點,誰用誰知道,redis跟它比可能是一個小插件的意思https://www.zhihu.com/question/53331259

Apache kafka是消息中間件的一種,我發現很多人不知道消息中間件是什麼,在開始學習之前,我這邊就先簡單的解釋一下什麼是消息中間件,只是粗略的講解,目前kafka已經可以做更多的事情。

舉個例子,生產者消費者,生產者生產雞蛋,消費者消費雞蛋,生產者生產一個雞蛋,消費者就消費一個雞蛋,假設消費者消費雞蛋的時候噎住了(系統宕機了),生產者還在生產雞蛋,那新生產的雞蛋就丟失了。再比如生產者很強勁(大交易量的情況),生產者1秒鐘生產100個雞蛋,消費者1秒鐘只能吃50個雞蛋,那要不了一會,消費者就吃不消了(消息堵塞,最終導致系統超時),消費者拒絕再吃了,”雞蛋“又丟失了,這個時候我們放個籃子在它們中間,生產出來的雞蛋都放到籃子裏,消費者去籃子裏拿雞蛋,這樣雞蛋就不會丟失了,都在籃子裏,而這個籃子就是”kafka“。
雞蛋其實就是“數據流”,系統之間的交互都是通過“數據流”來傳輸的(就是tcp、http什麼的),也稱爲報文,也叫“消息”。
消息隊列滿了,其實就是籃子滿了,”雞蛋“ 放不下了,那趕緊多放幾個籃子,其實就是kafka的擴容。
各位現在知道kafka是幹什麼的了吧,它就是那個"籃子"



作者:極限求知者
鏈接:https://www.zhihu.com/question/53331259/answer/241614605
來源:知乎
著作權歸作者所有。商業轉載請聯繫作者獲得授權,非商業轉載請註明出處。

 

- 日誌收集:一個公司可以用Kafka可以收集各種服務的log,通過kafka以統一接口服務的方式開放給各種consumer,例如hadoop、Hbase、Solr等。

- 消息系統:解耦和生產者和消費者、緩存消息等。

- 用戶活動跟蹤:Kafka經常被用來記錄web用戶或者app用戶的各種活動,如瀏覽網頁、搜索、點擊等活動,這些活動信息被各個服務器發佈到kafka的topic中,然後訂閱者通過訂閱這些topic來做實時的監控分析,或者裝載到hadoop、數據倉庫中做離線分析和挖掘。

- 運營指標:Kafka也經常用來記錄運營監控數據。包括收集各種分佈式應用的數據,生產各種操作的集中反饋,比如報警和報告。

- 流式處理:比如spark streaming和storm

- 事件源

》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》

flume:

https://blog.csdn.net/gyshun/article/details/79710534

flume也有kafka的緩存功能,但是有差異,請看文檔

flume的使用方式:在服務器上裝一個flume agent用於蒐集,也叫數據採集器。再在別的server上搭一個flume collector

flume agent裏又有 source,channel,sink三組件。source是收,channel是短暫存儲,sink是傳。可以傳給存儲,也可以傳給下一個agent。

https://www.cnblogs.com/oubo/archive/2012/05/25/2517751.html

flume agent 和flume collector的關係和區別 totally have no idea。新的flume已經沒有collector的概念了貌似,

爲什麼用flume?因爲flume的數據處理和很多封裝的source和sink,且flume可以處理很大的數據量,即專門爲大數據設計

Flume does have some features that makes it attractive to be a data ingestion and simpleevent processing framework. The key benefit of Flume is that it supports many built-in sources and sinks, which you can use out of box. If you use Kafka, most likely you have to write your own producer and consumer. Of course, as Kakfa becomes more and more popular, other frameworks are constantly adding integration support for Kafka. For example, Apache Storm added Kafka Spout in release 0.9.2, allowing Storm topology to consume data from Kafka 0.8.x directly. 

Kafka does not provider native support for message processing. So mostly likely it needs to integrate with other event processing frameworks such as Apache Storm to complete the job. In contrast, Flume supports different data flow models and interceptors chaining, which makes event filtering and transforming very easy. For example, you can filter out messages that you are not interested in the pipeline first before sending it through the network for obvious performance reason. However, It is not suitable for complex event processing, which I will address in a future post. 

 

》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》

fluentd:  與flume的區別:Fluentd is easier to install and maintain and has better documentation and support than Flume and Scribe 

fluent教程

https://docs.fluentd.org/installation/install-by-rpm

採用JSON統一數據/日誌格式是它的另一個特點。相對去Flumed,配置也相對簡單一些

搭建fluentd:前期準備(並沒有準備),執行腳本安裝(curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent3.sh | sh),啓動daemon(/usr/lib/systemd/system/td-agent,必須成功),開放端口8888(參見linux基本命令之端口處理,centos7),執行測試命令: curl -X POST -d 'json={"json":"message"}' http://192.168.153.132:8888/debug.test。發現已經追加到日誌文件的末尾(/var/log/td-agent/td-agent.log),要修改配置在哪裏改?在這裏/etc/td-agent/td-agent.conf

主要用法就是:安裝,啓動daemon,然後設置配置文件(/etc/td-agent/td-agent.conf),然後測試(運行監聽的程序)

》》》》》》》》》》》》》》》》》》》》》》》

flume語法(https://flume.apache.org/releases/content/1.9.0/FlumeUserGuide.html):

先定義一個config文件,在啓動flume的時候可以調用這個配置文件,比如:

bin/flume-ng agent --conf conf --conf-file example.conf --name a1 -Dflume.root.logger=INFO,console 其中example.conf就是要使用的 配置文件。

裏面的語法格式:首先定義都有哪些channel,source,和sink,其中多個時可以放在一起,用空格隔開,比如

agent.channel =  xx xxx  xxxx xyxyxy …… 其中的“agent”就是個別名,用於在命令行裏調用,比如上面的a1

定義好三大件後開始單獨配置,語法如下:

agent.channel.xx.type = xxx

原理就是類似於成員變量賦值。

一次賦值參數給 source和sink,有很多參數可配置。可以引入環境變量,比如 ${xxxx}

 

具體的參數以及值:

比如sink裏的type的Avro,這個是個專業術語 ,是一種數據結構,中文名數據序列化系統(https://www.cnblogs.com/Henry-pan/p/7242584.html),典型的基於json的數據結構。便於交互

checkpoint 和datadirs:其中datadirs是日誌存儲位置(可以是多個的之間用逗號隔開),checkpoint是啥鬼??該磁盤上的檢查點,定期進行備份的,防止flume崩了後找不到之前的日誌

》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》

fluentd的語法(https://docs.fluentd.org/configuration/config-file):

配置文件,固定,往裏面不停的扔管道,重要參數是source和match。替代flume的source和sink的原理

 

 

》》》》》》》》》》》》》

兩種實現方式:

方式一:線路一:flume收集日誌,發送給flume collector,collector發給splunk。線路二:kafka直接從tomcat拿日誌,然後扔給elasticsearch後續處理。

方式二:fluentd直接收集

 

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章