??想了解更多關(guān)于開(kāi)源的內(nèi)容，請(qǐng)?jiān)L問(wèn)：??

??51CTO 開(kāi)源基礎(chǔ)軟件社區(qū)??

??https://ost.51cto.com??

Loggie萌芽于網(wǎng)易嚴(yán)選業(yè)務(wù)的實(shí)際需求，成長(zhǎng)于嚴(yán)選與數(shù)帆的長(zhǎng)期共建，持續(xù)發(fā)展于網(wǎng)易數(shù)帆與網(wǎng)易傳媒、中國(guó)工商銀行的緊密協(xié)作。廣泛的生態(tài)，使得項(xiàng)目能夠基于業(yè)務(wù)需求不斷完善、成熟。目前已經(jīng)開(kāi)源：https://github.com/loggie-io/loggie。

1、背景

嚴(yán)選日志平臺(tái)初期，使用filebeat采集云內(nèi)日志，用flume采集云外日志。期間經(jīng)歷了一段痛苦的運(yùn)維排障時(shí)期，被問(wèn)的最多的幾個(gè)問(wèn)題：

• 某條日志為何沒(méi)有采集？
• 某條日志為何重復(fù)采集了？
• 能否將漏采集的那條日志補(bǔ)采集？
• 某個(gè)日志文件為何沒(méi)有采集？
• 某個(gè)日志文件的采集速度怎么這么慢（延遲超過(guò)30s）？
• 服務(wù)重新發(fā)布后，之前的日志怎么沒(méi)有了？
• …

而且同時(shí)維護(hù)了2套日志采集agent，維護(hù)成本高。不管是filebeat還是flume都存在以下幾點(diǎn)嚴(yán)重的問(wèn)題：

• 采集性能低：大促時(shí)間，部分節(jié)點(diǎn)的日志打印速度超過(guò)100MB/s，然而filebeat的采集性能上限只有80MB/s左右，flume更差一點(diǎn)。
• 資源占用高：filebeat單節(jié)點(diǎn)采集文件超過(guò)100個(gè)，cpu使用率超800%；flume空跑內(nèi)存就得占用200MB+，大促期間不得不開(kāi)啟限流以避免影響核心業(yè)務(wù)系統(tǒng)。
• 擴(kuò)展性差：fliebeat復(fù)雜的架構(gòu)以及單output設(shè)計(jì)無(wú)法滿足多變的業(yè)務(wù)需求。

同時(shí)也調(diào)研其他開(kāi)源的日志采集agent，或多或少都存在上述問(wèn)題，且都沒(méi)有足夠的可觀測(cè)性和運(yùn)維手段（工具）來(lái)幫助運(yùn)維排障，更不用說(shuō)完整的日志解決方案。

因此我們走向了自研的道路。

loggie在2022年初已開(kāi)源：https://github.com/loggie-io/loggie

歡迎大家使用，與社區(qū)一起成長(zhǎng)！

2、架構(gòu)設(shè)計(jì)

基于golang，借鑒經(jīng)典生產(chǎn)者-消費(fèi)者模式的微內(nèi)核設(shè)計(jì)。一個(gè)pipeline只有source、queue、sink、interceptor4個(gè)組件概念，且interceptor也不是必須的。pipeline支持配置熱加載，組件熱插拔，pipeline之間強(qiáng)隔離，防止相互影響。

（1） pipeline設(shè)計(jì)

pipeline的設(shè)計(jì)初衷主要是為了隔離性。之前運(yùn)維遇到的一個(gè)嚴(yán)重問(wèn)題：云內(nèi)使用filebeat采集多個(gè)業(yè)務(wù)的多個(gè)日志文件，但是其中一個(gè)日志文件的采集配置的topic被誤刪，導(dǎo)致發(fā)送到kafka失敗而阻塞，進(jìn)而導(dǎo)致整個(gè)物理機(jī)幾點(diǎn)的所有日志都阻塞。因此我們需要一種泳道隔離手段，來(lái)隔離不用業(yè)務(wù)、不同優(yōu)先級(jí)的日志，避免相互影響。

易擴(kuò)展

pipeline的簡(jiǎn)潔設(shè)計(jì)使得我們的擴(kuò)展極其便捷。在概念上，一個(gè)pipeline只有4種組件：source、queue、sink、interceptor，而且interceptor不是必須的。越少的概念，擴(kuò)展者者就有越少的學(xué)習(xí)成本。并且，為了進(jìn)一步提高擴(kuò)展性，pipeline中的所有組件都抽象為component，所有的組件擁有一致的生命周期與實(shí)現(xiàn)方式。不僅方便了擴(kuò)展，也方便了loggie對(duì)組件的統(tǒng)一管理。

隔離性與reload

基于pipeline，我們實(shí)現(xiàn)了配置熱更新，組件熱加載。reloader與discovery組件可以基于K8S CRD、http監(jiān)聽(tīng)等方式（預(yù)留接口，可以對(duì)接例如zookeeper、consul、apollo等配置中心），以pipeline維度進(jìn)行reload。因此，在保證了reload能力的同時(shí)仍然滿足了pipeline隔離的目的。

功能增強(qiáng)：interceptor

interceptor在loggie中是一個(gè)可選的組件，卻在loggie中扮演著非常重要的角色。loggie中絕大多數(shù)的增強(qiáng)功能都是基于interceptor實(shí)現(xiàn)的，例如限流、背壓、日志切分、encode&decode、字符編碼、結(jié)構(gòu)化等。用戶可以根據(jù)實(shí)際情況選擇對(duì)應(yīng)的interceptor提升loggie的適應(yīng)能力。

完整內(nèi)置interceptor：https://loggie-io.github.io/docs/reference/pipelines/interceptor/overview/。

3、日志采集

對(duì)于一個(gè)日志采集agent來(lái)說(shuō)，通常需要重點(diǎn)關(guān)心以下3點(diǎn)的設(shè)計(jì)與實(shí)現(xiàn)：

• 高效采集：高效指的是高性能的同時(shí)低能耗，即如何采集的快服務(wù)器資源占用有小。
• 公平性：例如寫(xiě)入快的文件不能影響寫(xiě)入慢的文件采集、最近更新的文件不能影響之前更新的文件的采集，刪除文件的合理采集與釋放。
• 可靠性：日志不丟失。包括進(jìn)程崩潰重啟、服務(wù)發(fā)布&遷移&容器漂移、下游阻塞等情況。

（1）高效采集

日志采集，我們關(guān)心的是這么幾個(gè)問(wèn)題：

• 如何及時(shí)發(fā)現(xiàn)新創(chuàng)建的文件？
• 如何及時(shí)發(fā)現(xiàn)最新的寫(xiě)入？
• 如何快速讀取文件？

這其實(shí)是兩方面的問(wèn)題：

• 事件感知：及時(shí)發(fā)現(xiàn)文件事件。例如文件新建、刪除、寫(xiě)入。
• 文件讀?。?/strong>高效讀取文件內(nèi)容。盡可能快的讀取文件內(nèi)容，減少磁盤(pán)io，cpu可控。

事件感知

如何做到文件事件感知呢？業(yè)界有兩種做法：

• 定時(shí)輪詢：定時(shí)檢查目錄文件狀態(tài)。
• OS事件通知：注冊(cè)O(shè)S文件事件，由OS通知具體的文件事件。

兩種方式各有利弊：

• 定時(shí)輪詢：

• 優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單，安全可靠。
• 缺點(diǎn)：輪詢的時(shí)間間隔不太好確定，間隔太短耗cpu，間隔太長(zhǎng)發(fā)現(xiàn)事件就太慢。

• OS事件通知：

• 優(yōu)點(diǎn)：能夠第一時(shí)間發(fā)現(xiàn)文件事件
• 缺點(diǎn)：

• 實(shí)現(xiàn)成本高（不同OS的實(shí)現(xiàn)方式不同，需要適配）。
• 存在bug：例如在最常用的linux系統(tǒng)中存在一些bug（https://man7.org/linux/man-pages/man7/inotify.7.html） ，其中影響最大的幾點(diǎn)：通知丟失、注冊(cè)數(shù)量有上限、文件改名事件無(wú)法通知改名后的文件名。
• 使用有限制：例如無(wú)法對(duì)通過(guò) NFS（Network File System） 掛載的網(wǎng)盤(pán)&云盤(pán)生效，無(wú)法對(duì) FUSE（filesystem in userspace） 生效等。

因此loggie結(jié)合兩者共同實(shí)現(xiàn)了一個(gè)安全可靠，卻又能及時(shí)感知事件的方案：

同時(shí)啟用定時(shí)輪詢和OS通知，使用OS通知然后搭配一個(gè)相對(duì)較長(zhǎng)（loggie默認(rèn)為10s）的定時(shí)輪詢，將兩者發(fā)現(xiàn)的事件進(jìn)行合并以減少重復(fù)處理，這樣就能同時(shí)兼具兩者的優(yōu)點(diǎn)。

但是實(shí)際測(cè)試下來(lái)，我們發(fā)現(xiàn)了cpu占用上升，分析原因：

• OS事件過(guò)多：特別是寫(xiě)文件的時(shí)候，對(duì)應(yīng)有兩個(gè)os事件（chmod+write），一旦文件寫(xiě)得頻繁，os的事件將非常多，loggie疲于處理系統(tǒng)事件。

所以，我們重新分析，什么樣的事件是我們真正關(guān)心并需要及時(shí)感知的呢？

• 文件寫(xiě)事件？

當(dāng)我們無(wú)法及時(shí)發(fā)現(xiàn)文件寫(xiě)事件，會(huì)有什么影響呢？有兩種情況：

• 如果這個(gè)文件正處于采集中（持有文件句柄），那這個(gè)文件的寫(xiě)事件沒(méi)有影響。因?yàn)檎谧x這個(gè)文件，后續(xù)的寫(xiě)入理所當(dāng)然能被讀到。
• 如果這個(gè)文件處于不活躍狀態(tài)（即文件已經(jīng)讀取到了末尾，并且一定時(shí)間內(nèi)沒(méi)有發(fā)現(xiàn)新內(nèi)容，甚至文件的文件句柄被釋放了），這個(gè)情況我們希望能及時(shí)感知文件的寫(xiě)事件以方便我們及時(shí)采集最新的寫(xiě)入內(nèi)容。

因此，重要的是“不活躍”文件的寫(xiě)事件。

• 文件新建（滾動(dòng)）事件？

當(dāng)我們沒(méi)有及時(shí)發(fā)現(xiàn)新建事件，會(huì)有什么影響呢？

首條日志寫(xiě)時(shí)間到發(fā)現(xiàn)時(shí)間之間的日志將會(huì)延遲采集（對(duì)于loggie來(lái)說(shuō)，最大延遲在10s左右，因?yàn)槟J(rèn)的輪詢時(shí)間間隔為10s），但是一旦感知到事件，采集可以很快追上進(jìn)度。因此新建事件不那么重要。

• 文件刪除事件？

當(dāng)我們沒(méi)有及時(shí)發(fā)現(xiàn)刪除事件，會(huì)有什么影響呢？有3種場(chǎng)景：

• 文件被刪除后，希望未采集完成的文件繼續(xù)采集：這種情況，刪除事件遲到不總要。因?yàn)楫?dāng)文件還未采集完，及時(shí)發(fā)現(xiàn)的刪除事件沒(méi)有意義；當(dāng)文件采集完后，未及時(shí)發(fā)現(xiàn)的刪除事件僅影響文件句柄釋放延遲。
• 文件被刪除后，希望盡快釋放磁盤(pán)空間：僅僅導(dǎo)致文件句柄釋放延遲，即磁盤(pán)空間釋放延遲（大概在10s左右）。
• 文件被刪除后，希望未采集完的文件給予一定的容忍時(shí)間再釋放磁盤(pán)空間：這種情況近會(huì)導(dǎo)致文件最終釋放延遲的時(shí)間=容忍時(shí)間+事件遲到時(shí)間。

因此，刪除事件不重要。

• 文件改名事件？

同上，不重要。但是如何得知文件改名以及改成什么名確實(shí)個(gè)值得好好思考的問(wèn)題！（暫不展開(kāi)）

所以，真正重要的是不活躍的文件寫(xiě)事件。因此我們的架構(gòu)調(diào)整為：

成果：

• 節(jié)省大量不必要的目錄和文件的系統(tǒng)事件注冊(cè)和監(jiān)聽(tīng)以及對(duì)應(yīng)監(jiān)聽(tīng)產(chǎn)生的大量事件，進(jìn)一步降低了CPU的損耗。
• 事件處理這一層去掉了事件合并這一步，因?yàn)樗惺录际怯行录?，進(jìn)一步降低了CPU的損耗。

文件讀取

文件讀的快的原則：

1. 減少磁盤(pán)io：意味著每次需要讀取更多的字節(jié)數(shù)緩沖在內(nèi)存，再按行分割處理。
2. cpu可控：減少gc和線程調(diào)度。

矛盾點(diǎn)：

• 原則1注定了我們需要重復(fù)分配長(zhǎng)數(shù)組來(lái)承載讀取的內(nèi)容。這意味了很多大對(duì)象。
• 原則2中的gc最害怕的恰恰是轉(zhuǎn)瞬即逝的大對(duì)象。

因此文件讀取的原理為：

• 復(fù)用讀取緩存數(shù)組：重復(fù)利用大對(duì)象。
• 讀取字節(jié)數(shù)：4k的n倍，充分利用os的page cache。

成果： 讀取性能達(dá)到2G/s（本地macbook ssd環(huán)境測(cè)試）。

（2）公平性

公平性我們關(guān)心的是文件之間的讀取平衡，不要造成文件讀取饑餓（長(zhǎng)時(shí)間得不到讀取而造成數(shù)據(jù)延遲）。業(yè)界這塊的做法有兩種：

• 每個(gè)文件對(duì)應(yīng)一個(gè)讀取線程，有os調(diào)度文件讀取保證公平性。

• 優(yōu)點(diǎn)：能夠保證公平性。
• 缺點(diǎn)：同時(shí)采集的文件數(shù)量多的時(shí)候cpu消耗太大。

• 匹配到的文件按照更新事件倒序，按照順序挨個(gè)讀取文件。

• 優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單。
• 缺點(diǎn)：無(wú)法保證公平性，更新時(shí)間早的文件必然會(huì)饑餓。

因此loggie實(shí)現(xiàn)了基于“時(shí)間片”的讀取方式：

成果： 僅僅用一個(gè)線程（goroutine）就處理了loggie所有的日志讀取任務(wù)，且最大可能的保證了公平性。

（3）可靠性

loggie保證了數(shù)據(jù)的不丟失，實(shí)現(xiàn)了at least once保證。對(duì)于文件讀取來(lái)說(shuō)，可靠性的實(shí)現(xiàn)有一定特殊性：需要保序ack，即我們對(duì)于采集點(diǎn)位記錄的持久化前提是當(dāng)前ack之前的ack全部done。因此為了提高保序ack的性能，我們的這塊的設(shè)計(jì)進(jìn)行了一些優(yōu)化：

對(duì)于sink端提交的ack不立即進(jìn)行持久化，而且進(jìn)行了雙重壓縮：

• 在ack chain階段只會(huì)提交最尾端的ack到db。
• db中會(huì)對(duì)提交的ack再進(jìn)一步壓縮。

成果： 大大減少了cpu的消耗和ack持久化的磁盤(pán)io次數(shù)。

（4）性能對(duì)比

對(duì)比f(wàn)ilebeat，同等情況下，發(fā)送至Kafka（單行、單文件、相同發(fā)送并發(fā)度、無(wú)解析場(chǎng)景）：

• 單文件采集對(duì)比，Loggie和Filebeat消耗的CPU相比，大概僅為后者的1/4，同時(shí)發(fā)送吞吐量為后者的1.6～2.6倍。
• Filebeat的極限吞吐量存在瓶頸，80MB/s后很難提升，而Loggie的極限值更高，多文件采集下能輕松達(dá)到200MB/s+。

4、運(yùn)維治理

基于loggie我們做了很多運(yùn)維治理，以及應(yīng)用分析的事情：

（1）可觀測(cè)

根據(jù)長(zhǎng)期運(yùn)維、排障經(jīng)驗(yàn)歸納提煉的內(nèi)置指標(biāo)，可以指導(dǎo)幫助我們快速發(fā)現(xiàn)定位問(wèn)題：

提供了grafana模版，可以一鍵配置：https://github.com/loggie-io/installation/tree/main/prometheus/grafana-dashboard。

（2）完整性

日志從采集到最終的存儲(chǔ)，鏈路可能比較冗長(zhǎng)，中間任何一個(gè)環(huán)節(jié)出問(wèn)題都可能導(dǎo)致日志丟失。因此需要有一個(gè)日志完整性校驗(yàn)的機(jī)制來(lái)判斷日志的采集情況。通常我們比較關(guān)心兩方面問(wèn)題：

• 某個(gè)服務(wù)的某個(gè)日志數(shù)據(jù)有沒(méi)有丟？
• 丟的數(shù)據(jù)能否補(bǔ)？

那如何計(jì)算日志有沒(méi)有丟呢？精確完整性計(jì)算的核心原理：

• 計(jì)算維度：機(jī)器ip+日志文件唯一標(biāo)識(shí)

機(jī)器ip是確定的，但是如何唯一標(biāo)識(shí)日志文件呢？

文件名可能重復(fù)，因此需要文件名+文件inode（文件標(biāo)識(shí)）。但是inode只在磁盤(pán)分區(qū)中唯一，因此需要修改為文件名+文件inode（文件標(biāo)識(shí)）+dev（磁盤(pán)標(biāo)識(shí)）。但是inode存在復(fù)用的情況，如果文件被采集完后被刪除了，inode被復(fù)用給一個(gè)同名的文件，這樣就變相的造成重復(fù)，因此我們需要增加文件內(nèi)容的前n個(gè)字符編碼。最終的計(jì)算維度為：機(jī)器ip+文件名稱+inode+dev+{fistNBytes}。

• 近實(shí)時(shí)計(jì)算：小時(shí)級(jí)批任務(wù)計(jì)算

之所以用小計(jì)批任務(wù)計(jì)算，主要有兩個(gè)原因：

• 日志的完整性計(jì)算不需要太實(shí)時(shí)，因?yàn)椴杉娜罩究赡芤驗(yàn)榉N種原因而遲到，實(shí)時(shí)計(jì)算的話很可能會(huì)存在太多的數(shù)據(jù)丟失的情況。而且計(jì)算的量級(jí)非常大，不適合實(shí)時(shí)計(jì)算。
• 另一面，不使用更大的時(shí)間間隔（例如T+1）計(jì)算的原因是，通常日志都會(huì)配置輪轉(zhuǎn)和清理。如果間隔過(guò)大，計(jì)算出有丟失的日志可能因?yàn)檩嗈D(zhuǎn)和清理被刪除了，那就失去了補(bǔ)數(shù)據(jù)的機(jī)會(huì)。

• 計(jì)算邏輯：日志行首o(hù)ffset+日志size=下一行日志行首o(hù)ffset
• 補(bǔ)數(shù)據(jù)：通過(guò)調(diào)用loggie原生的文件數(shù)據(jù)讀取接口獲?。ㄖ付╫ffset和讀取的size）。

計(jì)算需要的所有metric都附帶在loggie采集的的日志元數(shù)據(jù)中。

成果： 簡(jiǎn)單易用的平臺(tái)化展示與補(bǔ)數(shù)據(jù)。

（3）日志延遲

我們計(jì)算了日志在整個(gè)鏈路環(huán)節(jié)中的延遲情況，重點(diǎn)日志還會(huì)根據(jù)延遲情況及時(shí)的報(bào)警：

端到端的延遲計(jì)算意義：

• 幫助我們審視分析鏈路機(jī)器資源瓶頸。
• 指導(dǎo)大促期間的合理擴(kuò)縮容。
• 規(guī)劃未來(lái)增長(zhǎng)的日志所需的容量。

（4）日志質(zhì)量

由于日志采集后，可能被后續(xù)的業(yè)務(wù)監(jiān)控報(bào)警以及大數(shù)據(jù)數(shù)倉(cāng)處理分析計(jì)算應(yīng)用，因此日志的質(zhì)量變得愈發(fā)重要。那如何衡量日志質(zhì)量呢？本質(zhì)上，日志從非結(jié)構(gòu)化數(shù)據(jù)被采集后經(jīng)過(guò)一系列處理計(jì)算變成了結(jié)構(gòu)化數(shù)據(jù)，因此我們?cè)谌罩窘Y(jié)構(gòu)化的過(guò)程中定義了日志質(zhì)量分的計(jì)算：

• 日志切分（字段提取）處理：切分失敗扣1分
• 字段不存在扣1分
• 類型轉(zhuǎn)換處理：轉(zhuǎn)換失敗扣1分
• 字段約束失敗扣1分

效果：

日志質(zhì)量治理的意義：

• 量化日志質(zhì)量，持續(xù)推動(dòng)服務(wù)進(jìn)化。
• 為下游日志的處理極大提高效率。
• 提高了關(guān)鍵日志的準(zhǔn)確數(shù)。

（5）分析應(yīng)用

基于采集的日志數(shù)據(jù)我們做2個(gè)重量級(jí)的應(yīng)用，使得日志的重要程度上升了一個(gè)維度，讓日志真正擁有強(qiáng)烈的業(yè)務(wù)含義。

業(yè)務(wù)實(shí)時(shí)監(jiān)控

考慮以下需求：

• 實(shí)時(shí)監(jiān)控主站交易是否下跌
• 實(shí)時(shí)監(jiān)控主站UV訪問(wèn)
• 實(shí)時(shí)監(jiān)控主站的加購(gòu)、下單情況
• 實(shí)時(shí)監(jiān)控風(fēng)控的攔截情況
• 實(shí)時(shí)監(jiān)控服務(wù)的qps、異常情況
• …

通常實(shí)現(xiàn)這些需求需要不小的開(kāi)發(fā)周期，但是基于業(yè)務(wù)實(shí)時(shí)監(jiān)控，只需要花5-10分鐘的時(shí)間在平臺(tái)上配置即可展示與報(bào)警：

核心原理：

• 打印對(duì)應(yīng)的業(yè)務(wù)日志
• 在平臺(tái)配置采集對(duì)應(yīng)的日志
• 在平臺(tái)配置對(duì)應(yīng)日志的數(shù)據(jù)模型以及對(duì)應(yīng)指標(biāo)的計(jì)算邏輯（支持明細(xì)、聚合等豐富計(jì)算）
• 配置報(bào)警規(guī)則

成果：

大大降低了業(yè)務(wù)服務(wù)對(duì)關(guān)鍵業(yè)務(wù)過(guò)程的監(jiān)控報(bào)警的開(kāi)發(fā)成本，通過(guò)配置即可擁有業(yè)務(wù)實(shí)時(shí)監(jiān)控報(bào)警的能力。

業(yè)務(wù)全鏈路監(jiān)控

當(dāng)前微服務(wù)盛行，用戶的一個(gè)操作可能涉及底下多個(gè)微服務(wù)調(diào)用，考慮以下問(wèn)題：

• 如何從業(yè)務(wù)全局視角觀察對(duì)應(yīng)服務(wù)的運(yùn)行情況？
• 如何從業(yè)務(wù)鏈路視角發(fā)現(xiàn)上下游占用比例和依賴？

業(yè)務(wù)全鏈路監(jiān)控應(yīng)運(yùn)而生：

以交易鏈路為例，從首頁(yè)->搜索&推薦->商詳->加購(gòu)->下單->支付這個(gè)主鏈路以及輻射出來(lái)的幾條支鏈路，整體的流量是怎么樣的？調(diào)用qps是怎么樣的？平均rt是什么樣的？錯(cuò)誤情況如何？通過(guò)業(yè)務(wù)全鏈路監(jiān)控一目了然。

核心實(shí)現(xiàn)原理：

• 嚴(yán)選所有服務(wù)默認(rèn)開(kāi)啟訪問(wèn)日志，默認(rèn)采集所有服務(wù)的訪問(wèn)日志
• 在平臺(tái)配置業(yè)務(wù)鏈路流程對(duì)應(yīng)的服務(wù)以及接口
• 配置關(guān)鍵鏈路節(jié)點(diǎn)的監(jiān)控報(bào)警規(guī)則
• 平臺(tái)一鍵生成全鏈路實(shí)時(shí)監(jiān)控報(bào)警

業(yè)務(wù)全鏈路實(shí)時(shí)監(jiān)控的意義非凡，使得我們能夠站在更高的維度，以全局視角審視整個(gè)業(yè)務(wù)流程下的服務(wù)調(diào)用情況，及時(shí)發(fā)現(xiàn)鏈路中的薄弱環(huán)節(jié)以及異常情況，幫助我們優(yōu)化服務(wù)依賴，提升服務(wù)穩(wěn)定性。

5、結(jié)語(yǔ)

嚴(yán)選基于loggie的日志平臺(tái)化建設(shè)，我們一方面在滿足基于日志的問(wèn)題分析診斷這一基礎(chǔ)需求之余，進(jìn)一步了提升日志質(zhì)量、問(wèn)題排查效率、全鏈路可觀測(cè)可運(yùn)維能力。另一方面，我們擴(kuò)展能力與豐富應(yīng)用場(chǎng)景，只需要簡(jiǎn)單配置就使得日志擁有強(qiáng)烈的業(yè)務(wù)含義與監(jiān)控語(yǔ)義，使得我們能夠站在更高的維度審視&監(jiān)控業(yè)務(wù)鏈路中的異常，提前發(fā)現(xiàn)鏈路服務(wù)與資源問(wèn)題。

??想了解更多關(guān)于開(kāi)源的內(nèi)容，請(qǐng)?jiān)L問(wèn)：??

??51CTO 開(kāi)源基礎(chǔ)軟件社區(qū)??

??https://ost.51cto.com??