前言

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)文章！