java OpenTelemetry日志體系及缺陷解決方案
前言
OpenTelemetry為了實(shí)現(xiàn)其可觀測性有三大體系:Trace,Metrics和Log。本文將對于OpenTelemetry實(shí)現(xiàn)的日志體系進(jìn)行詳細(xì)的講述。
日志
說到日志相比大家都能侃侃而談:幫助快速定位出現(xiàn)的問題,數(shù)據(jù)追蹤,性能分析等等。日志可以說是與開發(fā)者們緊密關(guān)聯(lián)常常使用到的東西。經(jīng)過了多年的發(fā)展迭代,日志的體系也在不斷變化,涌現(xiàn)了elk這種分布式日志的體系,能夠便捷的幫助進(jìn)行日志的管理和查詢。
OpenTelemetry Log
在OpenTelemetry中,不屬于Trace或Metrics的部分都可以視為日志。例如,event可以被認(rèn)為是一種特殊的日志。
OpenTelemetry Log并沒有單獨(dú)拉出來組建一套日志的體系,而是全面擁抱現(xiàn)有的解決方案,在當(dāng)前的眾多日志類庫的基礎(chǔ)上進(jìn)行對于可觀測性的改進(jìn)和整合。
OpenTelemetry Log的意義
傳統(tǒng)日志的缺陷
現(xiàn)有的日志解決方案沒有辦法很好的和可觀測性解決方案進(jìn)行集成。日志對于追蹤和監(jiān)控的支持非常有限,通常是通過link的形式。而這種形式往往有部分?jǐn)?shù)據(jù)不夠完整。并且日志沒有一個標(biāo)準(zhǔn)化的傳播和記錄上下文的解決方案,在分布式的系統(tǒng)中往往會導(dǎo)致從系統(tǒng)的不同組件收集到無法關(guān)聯(lián)起來的日志。

像上圖這樣不同的庫有不同的采集協(xié)議采集方式,后端的服務(wù)很難將這種沒有統(tǒng)一規(guī)范的雜亂數(shù)據(jù)進(jìn)行統(tǒng)一,因此OpenTelemetry日志的統(tǒng)一規(guī)范就很有必要了。
OpenTelemetry日志的解決方案
本質(zhì)上來說OpenTelemetry Log其實(shí)也就是應(yīng)用的日志,和當(dāng)前大家使用的日志體系并沒有本質(zhì)的區(qū)別。在Trace中廣泛使用到的上下文傳播的能力可以在日志中進(jìn)行應(yīng)用,這樣可以豐富日志的關(guān)聯(lián)能力,并且可以將日志與同是OpenTelemetry體系的metrics和trace關(guān)聯(lián)到一起,遇到故障的排查會更加的便利。
假設(shè)這么一個場景:生產(chǎn)環(huán)境突發(fā)告警,然后排查到調(diào)用鏈路異常漫長需要排查原因,這個時(shí)候單純的日志排查就顯得很慢了,往往需要具體的報(bào)錯信息或者是固定的時(shí)間點(diǎn)來進(jìn)行定位。但是OpenTelemetry Log則可以通過異常鏈路的排查直接從鏈路定位到關(guān)聯(lián)的日志之中,使得排查的難度大大降低。

對于Trace和Merics,OpenTelemetry提供了新的API,而日志則比較特殊,當(dāng)前的各個編程語言已經(jīng)有了非常成熟的日志苦,例如Java的Logback和Log4j等等。
為了解決這些問題,OpenTelemetry做了如下的努力:
- 定義了一個日志數(shù)據(jù)模型。數(shù)據(jù)模型的目的是對
LogRecord的定義,日志系統(tǒng)的記錄、傳輸、存儲和解釋等等有一個標(biāo)準(zhǔn)的規(guī)范。 - 將現(xiàn)有的日志格式與
OpenTelemetry定義的日志數(shù)據(jù)模型進(jìn)行對應(yīng),并且collector將支持此種數(shù)據(jù)格式的轉(zhuǎn)換。 - 提供
LogRecord的API給庫的開發(fā)者提供豐富的能力。 - 提供SDK來對
LogRecord進(jìn)行配置處理和導(dǎo)出。
上述的種種使得OpenTelemetry能夠讀取現(xiàn)有系統(tǒng)的應(yīng)用程序日志,并且可以將其轉(zhuǎn)化為OpenTelemetry定義的數(shù)據(jù)格式,以此來實(shí)現(xiàn)統(tǒng)一。
OpenTelemetry Log的使用
日志的關(guān)聯(lián)
我們之前一直在說OpenTelemetry日志的特點(diǎn)是可以和其他數(shù)據(jù)進(jìn)行更好的關(guān)聯(lián),那么關(guān)聯(lián)的方式是什么呢?
OpenTelemetry為日志提供了如下的集中關(guān)聯(lián)方式:
- 時(shí)間維度:這個是最基礎(chǔ)的關(guān)聯(lián)方式,
Trace,Metrics和Log都能夠記錄發(fā)生的時(shí)刻或者是時(shí)間范圍,因此可以從時(shí)間的維度直接進(jìn)行關(guān)聯(lián)。 - 請求上下文:
OpenTelemetry可以在LogRecord中包含TraceId和SpanId,同樣的Trace也是一樣,并且這些信息是可以通過上下文進(jìn)行傳遞的,憑借此信息,日志就能夠互相進(jìn)行串聯(lián),并且也可以和Trace一起進(jìn)行整合。 - 資源上下文:即在
LogRecord中包含Resource的信息,以此來與其他數(shù)據(jù)關(guān)聯(lián)。
Event
event也是一種特殊的日志,他的使用我們在前面的OpenTelemetry系列中有介紹過,就不在此贅述了。
OpenTelemetry Log的采集
OpenTelemetry Collector支持對于OpenTelemetry日志的采集和處理。
- 目前的
collector支持otlp協(xié)議的push式日志傳輸,但是此方式的問題在于當(dāng)日志的量極其的大的時(shí)候會影響客戶端服務(wù)的性能,并且對于collector本身的性能也是一個極大的挑戰(zhàn)。 - 除此之外
collector也支持從日志文件pull的方式來自行獲取數(shù)據(jù)。目前支持日志文件的讀取,日志格式的解析等等,在collector中進(jìn)行類似如下配置即可開啟:
receivers:
filelog:
include: [ /var/log/myservice/*.json ]
operators:
- type: json_parser
timestamp:
parse_from: attributes.time
layout: '%Y-%m-%d %H:%M:%S'
- 目前
collector對于fluent forward方式有額外的支持,配置監(jiān)聽的端點(diǎn)即可直接以此方式采集數(shù)據(jù)。
如果是使用的pull模式,TraceId,SpanId等信息需要你自行在日志文件中進(jìn)行輸出,并且在采集后進(jìn)行解析,不然日志就沒辦法和Trace等進(jìn)行關(guān)聯(lián)。
總結(jié)
在當(dāng)前OpenTelemetry的日志體系可以說是已經(jīng)初步完成并且接近于GA了,但是從個人的觀感上來說距離生產(chǎn)可用還是有一定的距離的。
首先目前廣泛使用的日志采集器Filebeat和Logstash本質(zhì)上來說和OpenTelemetry Collector是二者取其一的關(guān)系,如果要完整啟用OpenTelemetry日志體系,需要使用OpenTelemetry Collector來替換掉Filebeat和Logstash。這對于絕大多數(shù)的公司來說是一個極其艱難的過程,拋棄掉一個完善的體系來使用一個剛剛1.0的應(yīng)用不是一件很容易的事情。
其次OpenTelemetry Collector的性能未必能有一定的保證。相對于久經(jīng)考驗(yàn)的Filebeat和Logstash,OpenTelemetry Collector還很年輕,盡管他在Trace的采集上已經(jīng)有過證明,但是日志的處理上還不太能給人信心。
其三由于OpenTelemetry體系會將Trace,Metrics,Log進(jìn)行關(guān)聯(lián),因此其數(shù)據(jù)的存儲也是需要考量的問題。一般來說使用Elasticsearch是能夠兼容所有的完美策略,但是面對其巨大的數(shù)據(jù)量以及不同數(shù)據(jù)格式的處理時(shí),需要仔細(xì)思考這樣的存儲體系是不是一定是最佳的方案。
總的來說從功能側(cè)OpenTelemetry日志體系已經(jīng)是一個較為完善的狀態(tài)了,但是他在生產(chǎn)環(huán)境的運(yùn)用到底如何還暫時(shí)需要打個問號。我們期待他的不斷迭代,以及先行者在生產(chǎn)環(huán)境的使用結(jié)果。
以上就是java OpenTelemetry日志體系及缺陷解決方案的詳細(xì)內(nèi)容,更多關(guān)于java OpenTelemetry日志體系的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
@Resource和@Autowired兩個注解的區(qū)別及說明
這篇文章主要介紹了@Resource和@Autowired兩個注解的區(qū)別及說明,具有很好的參考價(jià)值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-06-06
Java匿名內(nèi)部類和Lambda(->) 的多種寫法總結(jié)
這篇文章主要和大家分享一下Java匿名內(nèi)部類和Lambda(->) 的多種寫法,文中的示例代碼講解詳細(xì),對我們學(xué)習(xí)Java有一定幫助,需要的可以先看一下2022-07-07
【Java IO流】字節(jié)流和字符流的實(shí)例講解
下面小編就為大家?guī)硪黄綣ava IO流】字節(jié)流和字符流的實(shí)例講解。小編覺得挺不錯的,現(xiàn)在就分享給大家,也給大家做個參考。一起跟隨小編過來看看吧2017-09-09
Java反轉(zhuǎn)字符串和相關(guān)字符編碼的問題解決
反轉(zhuǎn)字符串一直被當(dāng)作是簡單問題,大家的思想主要就是利用遍歷,首尾交換字符實(shí)現(xiàn)字符串的反轉(zhuǎn)。例如下面的代碼,就可以簡單實(shí)現(xiàn)反轉(zhuǎn)。2013-05-05
SpringBoot SSE服務(wù)端主動推送事件的實(shí)現(xiàn)
本文主要介紹了SpringBoot SSE服務(wù)端主動推送事件的實(shí)現(xiàn),文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-06-06

