前言

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

日志

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

OpenTelemetry Log

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

OpenTelemetry Log并沒有單獨拉出來組建一套日志的體系，而是全面擁抱現(xiàn)有的解決方案，在當前的眾多日志類庫的基礎上進行對于可觀測性的改進和整合。

OpenTelemetry Log的意義

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

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

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

OpenTelemetry日志的解決方案

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

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

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

為了解決這些問題，OpenTelemetry做了如下的努力：

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

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

OpenTelemetry Log的使用

日志的關聯(lián)

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

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

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

Event

event也是一種特殊的日志，他的使用我們在前面的OpenTelemetry系列中有介紹過，就不在此贅述了。

OpenTelemetry Log的采集

OpenTelemetry Collector支持對于OpenTelemetry日志的采集和處理。

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

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)聽的端點即可直接以此方式采集數(shù)據(jù)。

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

總結

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

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

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

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

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

以上就是java OpenTelemetry日志體系及缺陷解決方案的詳細內容，更多關于java OpenTelemetry日志體系的資料請關注腳本之家其它相關文章！

最新評論