早些時分 Erda Show 針對微服務(wù)監(jiān)控、日志等內(nèi)容做了專場共享，許多同學(xué)聽完后意猶未盡，想了解更多關(guān)于日志剖析的內(nèi)容。Erda 團(tuán)隊做日志剖析也有一段時刻了，所以這次計劃和咱們詳細(xì)共享一下咱們在做的一些工作，期望對咱們有所協(xié)助。

日志剖析途徑其實(shí)是 Erda 微服務(wù)管理子途徑下面的一個功用模塊，那么今天我將從三個方面來打開共享：

• 日志剖析途徑出現(xiàn)的必要性；
• 日志剖析途徑架構(gòu)規(guī)劃；
• Erda 現(xiàn)在是怎么做的、做了哪些工作以及未來的發(fā)展方向。

日志剖析途徑的必要性

“微服務(wù)”這一概念大概在 2013 年出現(xiàn)，從這一概念初期到現(xiàn)在，大部分應(yīng)用的事務(wù)場景皆是分布式、容器化的布置架構(gòu)，或許至少是多服務(wù)架構(gòu)，每個服務(wù)基本上對錯單點(diǎn)的，并且會做單服務(wù)多實(shí)例的高可用布置。

在這種場景下，咱們需求重點(diǎn)處理關(guān)于日志的幾個問題。

需求處理的問題

1. 接口報錯了，如安在應(yīng)用的多個容器中快速的找到詳細(xì)的反常日志？

第一個要處理的問題是關(guān)于反常日志的定位功率問題。比方，前端在請求某個頁面，接口報錯了，隨后反饋給開發(fā)人員，慣例的接口報錯一般不會直接給用戶暴露特別詳細(xì)的反常信息，只會有一個狀態(tài)或是扼要的過錯概述，這時需求開發(fā)者經(jīng)過日志找到詳細(xì)的反常信息（比方倉庫等）。

一般來說，經(jīng)過接口途徑咱們能夠定位是哪個服務(wù)的報錯，但進(jìn)一步講，咱們怎么確認(rèn)是這個服務(wù)下的哪個實(shí)例的報錯呢？假設(shè)說咱們選用這種比較原始的方法，或許需求開發(fā)者分別檢查每個實(shí)例（容器）的日志，這樣會直接對開發(fā)功率產(chǎn)生影響。

2. 怎么便利的檢查現(xiàn)已宕機(jī)的應(yīng)用容器的日志？

別的一個需求處理的問題是日志存儲的耐久性問題。比方說在 K8s 途徑下，某個應(yīng)用服務(wù)的某個 pod 掛掉了被重新調(diào)度到了其他節(jié)點(diǎn)，或許本地存儲的容器日志由于時刻的翻滾而翻滾沒了，這時假設(shè)咱們想去回頭看一下之前的日志，在機(jī)器上現(xiàn)已不太簡略找到了。

3. 怎么能及時的發(fā)現(xiàn)某個應(yīng)用容器產(chǎn)生了反常？

前兩個問題歸于被動型的需求，也便是說前端事務(wù)上現(xiàn)已暴露出一些問題，然后咱們?nèi)セ厮荨⒉檎乙恍┤罩镜脑敿?xì)記錄的需求。由于是用戶反饋，這個流程鏈上的毛病處理時刻是相對較長的，那么應(yīng)該怎么縮短毛病處理時刻？

很天然咱們會想到主動告警，在還沒有大面積前端接口被大量用戶發(fā)現(xiàn)前，后端出現(xiàn)反常時，體系能夠更及時的進(jìn)行告警，并告訴相關(guān)人員及時處理，削減毛病時刻。這時咱們就非常需求一個別系能夠繼續(xù)監(jiān)聽一切容器的日志，幫忙開發(fā)者發(fā)現(xiàn)其間的反常并主動告警。

假設(shè)說沒有日志剖析途徑，其實(shí)以上三個問題并不是不能處理，可是會極大程度的影響功率。那么假設(shè)有了這樣的日志剖析途徑，由它來供給集中式查詢、耐久化存儲以及主動告警等功用，咱們能夠快速且高效的處理這三個問題。

日志剖析途徑能供給什么

說到日志剖析途徑的必要性，咱們務(wù)必要了解一下它能為咱們供給什么樣的服務(wù)，下面咱們就來詳細(xì)看一下：

1. 集中式、一站式查詢

在查詢方面，日志剖析途徑應(yīng)該是集中式、一站式的查詢，不再需求登錄不同機(jī)器或許容器去低效地手動檢查日志，而只需求在一個一致的頁面上輸入一些查詢語句，就能輕松查詢一切容器的日志了。

2. 耐久化，前史可追溯

在存儲方面，能夠給日志剖析途徑配備有預(yù)期的專門存儲配額，以便能夠更好地應(yīng)對宕機(jī)、升級、調(diào)度等導(dǎo)致日志跨節(jié)點(diǎn)的情況，保持查詢前史日志時的簡略性。

3. 智能化，主動發(fā)現(xiàn)問題

智能化告警一般也是一個必要功用，這兒的智能化有兩層意思：

你能夠主動裝備一些規(guī)矩，比方說依據(jù)代碼或現(xiàn)已產(chǎn)生的一些反常日志，能夠知道特定反常是什么姿態(tài)，隨后配一個規(guī)矩，體系就會繼續(xù)對輸入的日志做一些規(guī)矩檢測，假設(shè)發(fā)現(xiàn)匹配項，就會進(jìn)一步經(jīng)過你提前裝備的告警途徑，告訴到詳細(xì)的人；
主動發(fā)現(xiàn)“反常”，其實(shí)有點(diǎn)類似現(xiàn)在的機(jī)器學(xué)習(xí)、深度學(xué)習(xí)，也便是說，即便你沒有裝備任何規(guī)矩，可是體系能夠經(jīng)過對日志流的監(jiān)聽和學(xué)習(xí)，去發(fā)現(xiàn)反常的日志，然后告訴你去關(guān)注，這是更智能化的一些東西。

日志剖析途徑架構(gòu)規(guī)劃

咱們現(xiàn)已知道，日志剖析途徑能夠給咱們帶來便利及功率的提升，那么假設(shè)咱們想完成這樣一個途徑，需求怎么進(jìn)行架構(gòu)規(guī)劃呢？

想要做架構(gòu)規(guī)劃，首要要了解事務(wù)場景和需求，然后結(jié)合被處理數(shù)據(jù)的特色，才能夠揣度途徑架構(gòu)規(guī)劃應(yīng)該具有哪些才能。之后咱們再依據(jù)這些才能去尋覓、規(guī)劃相匹配的計劃，并在這些計劃中挑選真正可落地的去執(zhí)行。

數(shù)據(jù)特色

1. 時序數(shù)據(jù)

咱們知道日志歸于時序數(shù)據(jù)，只新增、不刪去。它有幾個字段比較要害：timestamp，tags，fields

• timestamp：時刻字段對時序型數(shù)據(jù)是用來進(jìn)行比較和要害的字段；
• tags：tags 代表一組字段，一般關(guān)于時序數(shù)據(jù)來講，作為標(biāo)簽類型的字段一般都是能夠查找的，也便是這些字段需求建立索引，如：服務(wù)名、容器名、容器 IP 等；
• fields：fields 也代表一組字段，這些字段相關(guān)于 tags 的不同在于，fields 字段是一般存儲那些不需求查找的內(nèi)容，比方：假設(shè)關(guān)于詳細(xì)的日志內(nèi)容你不計劃去查找，就能夠用 fields 類型字段存儲。

日志時序數(shù)據(jù)的特色提示咱們，能夠考慮運(yùn)用時序數(shù)據(jù)庫來存儲日志，比方 cassandra。

2. 時效性強(qiáng)

關(guān)于日志數(shù)據(jù)來講，咱們一般只關(guān)心一段時刻的數(shù)據(jù)，關(guān)于很早之前的數(shù)據(jù)，比方一個月、兩個月之前，乃至半年之前的數(shù)據(jù)，咱們基本上是不會去關(guān)心的。由于一般有毛病的時分，咱們或許才需求去看一下詳細(xì)的日志信息，而出現(xiàn)毛病時不大或許會拖到很久之后才去處理和復(fù)盤這個問題。

3. 數(shù)據(jù)量大

數(shù)據(jù)量大有兩個含義：一是說數(shù)據(jù)的單條日志或許比較大，比方像 Java 應(yīng)用的一個反常倉庫，特別那種 Caused by 嵌套了好幾層的，或許單條日志就會有幾百行；別的一個是說，日志的條數(shù)多，跟著事務(wù)和應(yīng)用的增多，加上某些應(yīng)用還或許會開啟 DEBUG 等級的日志，全體的日志量也會比較大，而且或許出現(xiàn)短時的峰值。

以上是日志數(shù)據(jù)的特色，然后咱們對從咱們?nèi)罩酒饰鐾緩竭@個角度來看看，咱們對體系有什么需求。

事務(wù)需求特色

1. 查詢速度快，秒級呼應(yīng)

首要，咱們期望它能夠快速查詢，輸入查詢要害字，就能夠秒級呼應(yīng)查詢結(jié)果。

2. 時刻段規(guī)模查詢

一般，查詢會依照一個清晰的時刻規(guī)模操作，這有一個優(yōu)點(diǎn)：后端存儲的挑選會更多一些。

3. 高基數(shù)值點(diǎn)查詢

什么是高基數(shù)值呢？像用戶 IP、Trace ID 這類數(shù)據(jù)，幾乎每個用戶請求的值都不一樣，這就歸于高基數(shù)。關(guān)于這類數(shù)據(jù)的查詢也是一個強(qiáng)需求，比方前端 web 接口報錯，而呼應(yīng)里加了 Trace ID 這樣的字段，此時就能夠經(jīng)過 Trace ID 字段去檢查整個過程中記錄的反常日志或要害日志，這也是一個比較常見的需求。

4. 標(biāo)簽查詢

標(biāo)簽查詢一般能夠認(rèn)為是對服務(wù)名、容器 IP 這樣的字段查詢需求，這也歸于強(qiáng)需求之一。

5. 全文檢索查詢

全文檢索查詢是否歸于強(qiáng)需求之一，其實(shí)是個值得權(quán)衡的問題。假設(shè)客戶端在收集端現(xiàn)已做了一些預(yù)處理，如：把整行的日志 content 在收集時拆分成了詳細(xì)的時刻等級、反常類型等單個要害字段，這樣來講，全文檢索查詢或許就不是一個強(qiáng)需求了，但一起，備選計劃的規(guī)?；蛟S會更大一些。這兒需求提醒的是，沒有全文檢索支撐，并不代表不能含糊檢索。憑借列存儲的高壓縮率和高 IO 功率，在內(nèi)存中進(jìn)行含糊過濾的作用也很贊！

6. 聚合計算

聚合計算中最簡略的是 Count 計算，更雜亂一點(diǎn)的有依據(jù)更多字段維度的雜亂聚合圖表支撐，這些功用在一些產(chǎn)品中也有供給，但需依據(jù)個別詳細(xì)需求來判別該項是不是強(qiáng)需求。

7. 主動告警

主動告警意味著體系不只具備被動查詢功用，一起也能夠及時發(fā)現(xiàn)問題并告警，這樣才能削減毛病時刻。

介紹完事務(wù)需求方面的 7 個特色后，在規(guī)劃架構(gòu)時，就能夠助力咱們敏捷 get 到需求考慮哪些方面了。

架構(gòu)要求

1. 軟硬本錢

當(dāng)然，本錢是一定要的，不管是做什么規(guī)劃，必定需求考慮本錢，這其間包含軟硬的本錢。

硬件本錢指的是咱們的機(jī)器數(shù)量：CPU、內(nèi)存、磁盤等這樣的資源。這兒面存在一個問題，由于關(guān)于日志而言，咱們講數(shù)據(jù)量大，單條的體積或許也比較大，假設(shè)確認(rèn)不需求全文檢索，或只檢索其間很少的幾個要害字段，關(guān)于那些較長的字段，僅僅只是想跟著查找條件把它展現(xiàn)出來，這個時分咱們或許就會考慮，關(guān)于不需求索引的這些數(shù)據(jù)，是不是能夠經(jīng)過一些更廉價的存儲方法（比方像 OSS）存下來，這樣能夠節(jié)省全體的存儲本錢。

另一方面需求考慮軟件本錢，拿方才 OSS 存儲的例子，假設(shè)咱們想用很高效的存儲方法來存儲索引的數(shù)據(jù)，而那些不需求查詢的字段用 OSS 存儲，這時的架構(gòu)計劃或許會稍微雜亂一些，開發(fā)雜亂度和難度，以及人力投入也會相對高一些，軟件的全體本錢也會相應(yīng)增加。

2. 存儲要有過期機(jī)制

數(shù)據(jù)的實(shí)效性對存儲機(jī)制也提出了要求，關(guān)于數(shù)據(jù)的過期機(jī)制，需求考慮，怎么確保和約束執(zhí)行數(shù)據(jù)過期刪去時的功用耗費(fèi)不會對整個別系的吞吐有過大影響。

3. 異步處理，吞吐要大，不能被事務(wù)流量打垮

在數(shù)據(jù)量大的場景下，要求日志體系在承受采極點(diǎn)數(shù)據(jù)的時分，需求考慮異步處理等手法，確保不能被事務(wù)流量打垮。假設(shè)說事務(wù)體系有問題了，日志體系也因此出現(xiàn)問題，導(dǎo)致不能運(yùn)用日志體系來查詢、排查事務(wù)問題，那這個途徑存在的含義就會受到挑戰(zhàn)。一般來說咱們會用 MQ 這樣的中間件來做異步的削峰填谷處理。

4. 即席查詢才能（內(nèi)存、緩存、并行、高效過濾等機(jī)制）

依據(jù)對查詢速度的要求，能夠秒級呼應(yīng)的存儲計劃會被優(yōu)先挑選。

5. 存儲結(jié)構(gòu)對時刻規(guī)模查詢友好

依據(jù)時刻段的規(guī)模查詢是最高頻的場景之一，針對此類場景，咱們能夠考慮挑選時序數(shù)據(jù)庫，因其自身對時刻序列查詢做了本錢上的優(yōu)化，一起也是功率較高的計劃。

6. 二級索引才能

高基數(shù)單點(diǎn)查詢對索引才能提出了要求，這將約束咱們關(guān)于時序數(shù)據(jù)庫的挑選。由于像 promethus 這樣的時序數(shù)據(jù)庫對高基數(shù)值的單點(diǎn)查詢是存在問題的，這是由于它的存儲的特色決議的。一般來說，假設(shè)咱們想支撐高基數(shù)值的單點(diǎn)查詢，需求需求有一個二級特色才能的數(shù)據(jù)庫。

7. 全文檢索才能

怎么支撐含糊查詢，也是咱們要考量的一個要素。由于假設(shè)要做完好的全文檢索才能支撐，比方：分詞、相關(guān)性算分排序等，咱們的可選計劃會被進(jìn)一步約束。

8. 存儲結(jié)構(gòu)聚合操作友好（如列存儲）

們知道關(guān)于聚合計算操作對話，列存儲的聚合功用是比較高的，由于它有很高對壓縮比，一次讀盤能夠讀到許多有效的數(shù)據(jù)，全體對 IO 功率會很高。

9. 告警模塊

最終一點(diǎn)便是架構(gòu)里必須規(guī)劃告警模塊怎么去做。

以上內(nèi)容針對數(shù)據(jù)特色、事務(wù)需求提出的一些架構(gòu)要求進(jìn)行介紹，能夠看出，核心取舍在于存儲。下面一張圖，展現(xiàn)了整個架構(gòu)的處理流程和要害組件，接下來的內(nèi)容將對存儲部分的選型進(jìn)行打開介紹。

存儲計劃選型

上圖中關(guān)于存儲部分，有幾個開源的可選存儲中間件：像 Cassandra、Hbase、ElasticSearch、ClickHouse、Grafana Loki等。下圖將會針對這些中間件的優(yōu)缺陷進(jìn)行對比剖析：

上圖的計劃選型圖表對各個計劃的描述現(xiàn)已相對比較詳細(xì)，在此就不再贅述，接下來咱們看下在 Erda 中是怎么做的。

Erda 日志剖析途徑實(shí)踐

Erda 現(xiàn)在選用的其實(shí)是比較常見的完成計劃：運(yùn)用 Elasticsearch 作為底層存儲。當(dāng)然，其間也存在前史原因，Erda 的開源時刻盡管并不是很長，可是其存在前史能夠算比較久了。在其時看來，挑選 Elasticsearch 也是比較合理的挑選。當(dāng)然，現(xiàn)狀并不是終點(diǎn)，咱們后邊仍會繼續(xù)探索在本錢、功率方面更優(yōu)的計劃。

假設(shè)說挑選 ES 這樣的一個計劃的話，詳細(xì)應(yīng)該怎么做呢？

方才的計劃選型圖表中列出了運(yùn)用 Elasticsearch 的大致核心思路，接下來咱們詳細(xì)深入看下怎么去做。

之前說到，運(yùn)用 Elasticsearch 計劃的特色便是功用全和開箱即用，上圖中列出了在 Erda 中所利用的一些要害才能來完成現(xiàn)在 Erda 想要供給的部分要害功用，如下圖所示。

總的來說，Erda 現(xiàn)在選用的其實(shí)仍是比較慣例的計劃，并在此基礎(chǔ)上有一些小的優(yōu)化，整個代碼結(jié)構(gòu)上也是做了一層籠統(tǒng)，并沒有說以后便是綁死在 Elasticsearch 上面，后續(xù)咱們還會考慮支撐一些其他可替換計劃。

Erda 日志剖析途徑未來的方向

對 Erda 日志剖析途徑而言，未來咱們有幾個努力的方向：

1. 存儲更高效、可擴(kuò)展

首要是存儲方面，上文咱們也說到，Erda 現(xiàn)在首要選用依據(jù) Elasticsearch 的存儲計劃，但運(yùn)用 Elasticsearch 有一個不行忽視的缺陷，那便是它的全體資源占用本錢相對較高，而像 Clickhouse、Grafana Loki 等，的確有各自的優(yōu)勢需求咱們?nèi)ソ梃b。所以說 Erda 作為一個開源產(chǎn)品，后續(xù)或許會支撐更多的底層存儲，用戶能夠在這些計劃之間依據(jù)自身的需求和本錢來進(jìn)行挑選。

別的，自研存儲也將會是咱們的一個投入方向，由于監(jiān)控范疇除了日志，還有指標(biāo)、Trace 數(shù)據(jù)。這些數(shù)據(jù)能否選用一個一致的存儲內(nèi)核來下降體系的雜亂度，一起能夠?qū)Σ煌瑪?shù)據(jù)類型做專項優(yōu)化來平衡本錢和功用，這些都是咱們考慮自研存儲的出發(fā)點(diǎn)。

2. 告警更快捷、更智能

現(xiàn)在在 Erda 途徑上，假設(shè)想從日志剖析出發(fā)去創(chuàng)建告警規(guī)矩，實(shí)際運(yùn)用的鏈路仍是有點(diǎn)長，所以后續(xù)咱們會優(yōu)化這條鏈路上的產(chǎn)品和功用體驗(yàn)。

別的的一個方向便是智能化，依據(jù)日志的主動反常檢測。在上文中有簡略說到這點(diǎn)，便是說即便用戶沒有顯式的去裝備任何規(guī)矩，體系也能夠協(xié)助用戶去發(fā)現(xiàn)預(yù)期之外的一些反常。這兒的反常，不一定非得是事務(wù)應(yīng)用拋出的過錯的倉庫，它是一個相關(guān)于“正?！钡母拍睿凑?shù)據(jù)流中忽然出現(xiàn)了一個非常不同尋常的數(shù)據(jù)，這或許會需求用到一些機(jī)器學(xué)習(xí)的模型來檢測。

---

以上便是本次想要和咱們共享的有關(guān)日志剖析架構(gòu)的一些內(nèi)容，后續(xù)咱們也將不忘初心，繼續(xù)優(yōu)化產(chǎn)品功用和用戶體驗(yàn)，也非常等待有更多對此感興趣的開發(fā)者參加進(jìn)來與咱們共建 Erda，每一條建議咱們都會認(rèn)真聆聽，等待更多的聲音協(xié)助咱們變得更好！