关于后端:OpenTelemetry日志体系

前言

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 日志体系曾经是一个较为欠缺的状态了，然而他在生产环境的使用到底如何还临时须要打个问号。咱们期待他的一直迭代，以及先行者在生产环境的应用后果。