前言

OpenTelemetry為了實(shí)現(xiàn)其可觀(guān)測(cè)性有三大體系：Trace，Metrics和Log。本文將對(duì)于OpenTelemetry實(shí)現(xiàn)的日志體系進(jìn)行詳細(xì)的講述。

日志

說(shuō)到日志相比大家都能侃侃而談：幫助快速定位出現(xiàn)的問(wèn)題，數(shù)據(jù)追蹤，性能分析等等。日志可以說(shuō)是與開(kāi)發(fā)者們緊密關(guān)聯(lián)常常使用到的東西。經(jīng)過(guò)了多年的發(fā)展迭代，日志的體系也在不斷變化，涌現(xiàn)了elk這種分布式日志的體系，能夠便捷的幫助進(jìn)行日志的管理和查詢(xún)。

OpenTelemetry Log

在OpenTelemetry中，不屬于Trace或Metrics的部分都可以視為日志。例如，event可以被認(rèn)為是一種特殊的日志。

OpenTelemetry Log并沒(méi)有單獨(dú)拉出來(lái)組建一套日志的體系，而是全面擁抱現(xiàn)有的解決方案，在當(dāng)前的眾多日志類(lèi)庫(kù)的基礎(chǔ)上進(jìn)行對(duì)于可觀(guān)測(cè)性的改進(jìn)和整合。

OpenTelemetry Log的意義

傳統(tǒng)日志的缺陷

現(xiàn)有的日志解決方案沒(méi)有辦法很好的和可觀(guān)測(cè)性解決方案進(jìn)行集成。日志對(duì)于追蹤和監(jiān)控的支持非常有限，通常是通過(guò)link的形式。而這種形式往往有部分?jǐn)?shù)據(jù)不夠完整。并且日志沒(méi)有一個(gè)標(biāo)準(zhǔn)化的傳播和記錄上下文的解決方案，在分布式的系統(tǒng)中往往會(huì)導(dǎo)致從系統(tǒng)的不同組件收集到無(wú)法關(guān)聯(lián)起來(lái)的日志。

像上圖這樣不同的庫(kù)有不同的采集協(xié)議采集方式，后端的服務(wù)很難將這種沒(méi)有統(tǒng)一規(guī)范的雜亂數(shù)據(jù)進(jìn)行統(tǒng)一，因此OpenTelemetry日志的統(tǒng)一規(guī)范就很有必要了。

OpenTelemetry日志的解決方案

本質(zhì)上來(lái)說(shuō)OpenTelemetry Log其實(shí)也就是應(yīng)用的日志，和當(dāng)前大家使用的日志體系并沒(méi)有本質(zhì)的區(qū)別。在Trace中廣泛使用到的上下文傳播的能力可以在日志中進(jìn)行應(yīng)用，這樣可以豐富日志的關(guān)聯(lián)能力，并且可以將日志與同是OpenTelemetry體系的metrics和trace關(guān)聯(lián)到一起，遇到故障的排查會(huì)更加的便利。

假設(shè)這么一個(gè)場(chǎng)景：生產(chǎn)環(huán)境突發(fā)告警，然后排查到調(diào)用鏈路異常漫長(zhǎng)需要排查原因，這個(gè)時(shí)候單純的日志排查就顯得很慢了，往往需要具體的報(bào)錯(cuò)信息或者是固定的時(shí)間點(diǎn)來(lái)進(jìn)行定位。但是OpenTelemetry Log則可以通過(guò)異常鏈路的排查直接從鏈路定位到關(guān)聯(lián)的日志之中，使得排查的難度大大降低。

對(duì)于Trace和Merics，OpenTelemetry提供了新的API，而日志則比較特殊，當(dāng)前的各個(gè)編程語(yǔ)言已經(jīng)有了非常成熟的日志苦，例如Java的Logback和Log4j等等。

為了解決這些問(wèn)題，OpenTelemetry做了如下的努力：

• 定義了一個(gè)日志數(shù)據(jù)模型。數(shù)據(jù)模型的目的是對(duì)LogRecord的定義，日志系統(tǒng)的記錄、傳輸、存儲(chǔ)和解釋等等有一個(gè)標(biāo)準(zhǔn)的規(guī)范。
• 將現(xiàn)有的日志格式與OpenTelemetry定義的日志數(shù)據(jù)模型進(jìn)行對(duì)應(yīng)，并且collector將支持此種數(shù)據(jù)格式的轉(zhuǎn)換。
• 提供LogRecord的API給庫(kù)的開(kāi)發(fā)者提供豐富的能力。
• 提供SDK來(lái)對(duì)LogRecord進(jìn)行配置處理和導(dǎo)出。

上述的種種使得OpenTelemetry能夠讀取現(xiàn)有系統(tǒng)的應(yīng)用程序日志，并且可以將其轉(zhuǎn)化為OpenTelemetry定義的數(shù)據(jù)格式，以此來(lái)實(shí)現(xiàn)統(tǒng)一。

OpenTelemetry Log的使用

日志的關(guān)聯(lián)

我們之前一直在說(shuō)OpenTelemetry日志的特點(diǎn)是可以和其他數(shù)據(jù)進(jìn)行更好的關(guān)聯(lián)，那么關(guān)聯(lián)的方式是什么呢？

OpenTelemetry為日志提供了如下的集中關(guān)聯(lián)方式：

• 時(shí)間維度：這個(gè)是最基礎(chǔ)的關(guān)聯(lián)方式，Trace，Metrics和Log都能夠記錄發(fā)生的時(shí)刻或者是時(shí)間范圍，因此可以從時(shí)間的維度直接進(jìn)行關(guān)聯(lián)。
• 請(qǐng)求上下文：OpenTelemetry可以在LogRecord中包含TraceId和SpanId，同樣的Trace也是一樣，并且這些信息是可以通過(guò)上下文進(jìn)行傳遞的，憑借此信息，日志就能夠互相進(jìn)行串聯(lián)，并且也可以和Trace一起進(jìn)行整合。
• 資源上下文：即在LogRecord中包含Resource的信息，以此來(lái)與其他數(shù)據(jù)關(guān)聯(lián)。

Event

event也是一種特殊的日志，他的使用我們?cè)谇懊娴?code>OpenTelemetry系列中有介紹過(guò)，就不在此贅述了。

OpenTelemetry Log的采集

OpenTelemetry Collector支持對(duì)于OpenTelemetry日志的采集和處理。

• 目前的collector支持otlp協(xié)議的push式日志傳輸，但是此方式的問(wèn)題在于當(dāng)日志的量極其的大的時(shí)候會(huì)影響客戶(hù)端服務(wù)的性能，并且對(duì)于collector本身的性能也是一個(gè)極大的挑戰(zhàn)。
• 除此之外collector也支持從日志文件pull的方式來(lái)自行獲取數(shù)據(jù)。目前支持日志文件的讀取，日志格式的解析等等，在collector中進(jìn)行類(lèi)似如下配置即可開(kāi)啟：

receivers:
  filelog:
    include: [ /var/log/myservice/*.json ]
    operators:
      - type: json_parser
        timestamp:
          parse_from: attributes.time
          layout: '%Y-%m-%d %H:%M:%S'

• 目前collector對(duì)于fluent forward方式有額外的支持，配置監(jiān)聽(tīng)的端點(diǎn)即可直接以此方式采集數(shù)據(jù)。

如果是使用的pull模式，TraceId，SpanId等信息需要你自行在日志文件中進(jìn)行輸出，并且在采集后進(jìn)行解析，不然日志就沒(méi)辦法和Trace等進(jìn)行關(guān)聯(lián)。

總結(jié)

在當(dāng)前OpenTelemetry的日志體系可以說(shuō)是已經(jīng)初步完成并且接近于GA了，但是從個(gè)人的觀(guān)感上來(lái)說(shuō)距離生產(chǎn)可用還是有一定的距離的。

首先目前廣泛使用的日志采集器Filebeat和Logstash本質(zhì)上來(lái)說(shuō)和OpenTelemetry Collector是二者取其一的關(guān)系，如果要完整啟用OpenTelemetry日志體系，需要使用OpenTelemetry Collector來(lái)替換掉Filebeat和Logstash。這對(duì)于絕大多數(shù)的公司來(lái)說(shuō)是一個(gè)極其艱難的過(guò)程，拋棄掉一個(gè)完善的體系來(lái)使用一個(gè)剛剛1.0的應(yīng)用不是一件很容易的事情。

其次OpenTelemetry Collector的性能未必能有一定的保證。相對(duì)于久經(jīng)考驗(yàn)的Filebeat和Logstash，OpenTelemetry Collector還很年輕，盡管他在Trace的采集上已經(jīng)有過(guò)證明，但是日志的處理上還不太能給人信心。

其三由于OpenTelemetry體系會(huì)將Trace，Metrics，Log進(jìn)行關(guān)聯(lián)，因此其數(shù)據(jù)的存儲(chǔ)也是需要考量的問(wèn)題。一般來(lái)說(shuō)使用Elasticsearch是能夠兼容所有的完美策略，但是面對(duì)其巨大的數(shù)據(jù)量以及不同數(shù)據(jù)格式的處理時(shí)，需要仔細(xì)思考這樣的存儲(chǔ)體系是不是一定是最佳的方案。

總的來(lái)說(shuō)從功能側(cè)OpenTelemetry日志體系已經(jīng)是一個(gè)較為完善的狀態(tài)了，但是他在生產(chǎn)環(huán)境的運(yùn)用到底如何還暫時(shí)需要打個(gè)問(wèn)號(hào)。我們期待他的不斷迭代，以及先行者在生產(chǎn)環(huán)境的使用結(jié)果。

以上就是java OpenTelemetry日志體系及缺陷解決方案的詳細(xì)內(nèi)容，更多關(guān)于java OpenTelemetry日志體系的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論