前言

OpenTelemetry为了实现其可观测性有三大体系：Trace，Metrics和Log。本文将对于OpenTelemetry实现的日志体系进行具体的讲述。

日志

说到日志相比大家都能娓娓而谈：帮忙疾速定位呈现的问题，数据追踪，性能剖析等等。日志能够说是与开发者们严密关联经常应用到的货色。通过了多年的倒退迭代，日志的体系也在一直变动，涌现了elk这种分布式日志的体系，可能便捷的帮忙进行日志的治理和查问。

OpenTelemetry Log

在OpenTelemetry中，不属于Trace或Metrics的局部都能够视为日志。例如，event能够被认为是一种非凡的日志。

OpenTelemetry Log并没有独自拉进去组建一套日志的体系，而是全面拥抱现有的解决方案，在以后的泛滥日志类库的根底上进行对于可观测性的改良和整合。

OpenTelemetry Log的意义

传统日志的缺点

现有的日志解决方案没有方法很好的和可观测性解决方案进行集成。日志对于追踪和监控的反对十分无限，通常是通过link的模式。而这种模式往往有局部数据不够残缺。并且日志没有一个标准化的流传和记录上下文的解决方案，在分布式的零碎中往往会导致从零碎的不同组件收集到无奈关联起来的日志。

像上图这样不同的库有不同的采集协定采集形式，后端的服务很难将这种没有对立标准的芜杂数据进行对立，因而OpenTelemetry日志的对立标准就很有必要了。

OpenTelemetry日志的解决方案

实质上来说OpenTelemetry Log其实也就是利用的日志，和以后大家应用的日志体系并没有实质的区别。在Trace中宽泛应用到的上下文流传的能力能够在日志中进行利用，这样能够丰盛日志的关联能力，并且能够将日志与同是OpenTelemetry体系的metrics和trace关联到一起，遇到故障的排查会更加的便当。

假如这么一个场景：生产环境突发告警，而后排查到调用链路异样漫长须要排查起因，这个时候单纯的日志排查就显得很慢了，往往须要具体的报错信息或者是固定的工夫点来进行定位。然而OpenTelemetry Log则能够通过异样链路的排查间接从链路定位到关联的日志之中，使得排查的难度大大降低。

对于Trace和Merics，OpenTelemetry提供了新的API，而日志则比拟非凡，以后的各个编程语言曾经有了十分成熟的日志苦，例如Java的Logback和Log4j等等。

为了解决这些问题，OpenTelemetry做了如下的致力：

  1. 定义了一个日志数据模型。数据模型的目标是对LogRecord的定义，日志零碎的记录、传输、存储和解释等等有一个规范的标准。
  2. 将现有的日志格局与OpenTelemetry定义的日志数据模型进行对应，并且collector将反对此种数据格式的转换。
  3. 提供LogRecord的API给库的开发者提供丰盛的能力。
  4. 提供SDK来对LogRecord进行配置解决和导出。

上述的种种使得OpenTelemetry可能读取现有零碎的应用程序日志，并且能够将其转化为OpenTelemetry定义的数据格式，以此来实现对立。

OpenTelemetry Log的应用

日志的关联

咱们之前始终在说OpenTelemetry日志的特点是能够和其余数据进行更好的关联，那么关联的形式是什么呢？

OpenTelemetry为日志提供了如下的集中关联形式：

  1. 工夫维度：这个是最根底的关联形式，Trace，Metrics和Log都可能记录产生的时刻或者是工夫范畴，因而能够从工夫的维度间接进行关联。
  2. 申请上下文：OpenTelemetry能够在LogRecord中蕴含TraceId和SpanId，同样的Trace也是一样，并且这些信息是能够通过上下文进行传递的，凭借此信息，日志就可能相互进行串联，并且也能够和Trace一起进行整合。
  3. 资源上下文：即在LogRecord中蕴含Resource的信息，以此来与其余数据关联。

Event

event也是一种非凡的日志，他的应用咱们在后面的OpenTelemetry系列中有介绍过，就不在此赘述了。

OpenTelemetry Log的采集

OpenTelemetry Collector反对对于OpenTelemetry日志的采集和解决。

  • 目前的collector反对otlp协定的push式日志传输，然而此形式的问题在于当日志的量极其的大的时候会影响客户端服务的性能，并且对于collector自身的性能也是一个极大的挑战。

  • 除此之外collector也反对从日志文件pull的形式来自行获取数据。目前反对日志文件的读取，日志格局的解析等等，在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形式有额定的反对，配置监听的端点即可间接以此形式采集数据。

如果是应用的pull模式，TraceId，SpanId等信息须要你自行在日志文件中进行输入，并且在采集后进行解析，不然日志就没方法和Trace等进行关联。

总结

在以后OpenTelemetry的日志体系能够说是曾经初步实现并且靠近于GA了，然而从集体的观感上来说间隔生产可用还是有肯定的间隔的。

首先目前宽泛应用的日志采集器Filebeat和Logstash实质上来说和OpenTelemetry Collector是二者取其一的关系，如果要残缺启用OpenTelemetry日志体系，须要应用OpenTelemetry Collector来替换掉Filebeat和Logstash。这对于绝大多数的公司来说是一个极其艰巨的过程，摈弃掉一个欠缺的体系来应用一个刚刚1.0的利用不是一件很容易的事件。

其次OpenTelemetry Collector的性能未必能有肯定的保障。绝对于久经考验的Filebeat和Logstash，OpenTelemetry Collector还很年老，只管他在Trace的采集上曾经有过证实，然而日志的解决上还不太能给人信念。

其三因为OpenTelemetry体系会将Trace，Metrics，Log进行关联，因而其数据的存储也是须要考量的问题。一般来说应用Elasticsearch是可能兼容所有的完满策略，然而面对其微小的数据量以及不同数据格式的解决时，须要认真思考这样的存储体系是不是肯定是最佳的计划。

总的来说从性能侧OpenTelemetry日志体系曾经是一个较为欠缺的状态了，然而他在生产环境的使用到底如何还临时须要打个问号。咱们期待他的一直迭代，以及先行者在生产环境的应用后果。