可观测未来OpenTelemertry-结构化数据价值

前言

开源软件和云供应商的软件开发模式已经改变了我们构建和部署软件的方式。集成开源软件，我们可以在很短时间内构建和部署一个应用程序。但这并不意味着使用和维护它们也变得更简单，随着应用程序的扩充，程序的调用变得更加复杂。对于问题的定位和分析变得更加困难，我们仍然需要用户的事务端到端的勘察工具来说明在处理这些事务的过程中资源是如何被消耗的。所以对观测性的需求是没有改变的，我们实时感测解决方案的方式需要改变。

可观测历史

早期我们观察系统时使用的是传统的筒仓式的工具，筒仓式也部分实现了实时监控和分析系统各个组件和节点的运行状态和性能指标。同时筒仓式大部分数据也是完全非结构化关联的，为了建立统一监控我们又对这些独立的结构工具进行了垂直整合。例如用户需要了解他们的应用正在执行的事务建立了一个独立的日志工具系统；为了监测应用程序运行时的资源建立一个指标监控系统；为了程序的一串执行中某些操作的关联又创建了追踪系统。然后一个被我们常用的独立的“三大支柱”观测性能力就建立了，以致于使用久了我们便不再会质疑它。但此方法也只是某些技术碰巧被实现的方式，可以说是观测一个探索过程的印记。

以往的排查过程?

让我们还原下运维人员在调查问题的真实经历，当注意到一个重要的指标时序出现"毛刺"就需要注意了。在这种情况下，在根据经验初步猜判断后，运维人员会始排查可能相关的日志、资源配置等。由于部分指标是完全相互独立的就会很难从监控系统中得到直接帮助。最常见的问题排查流程，是对日志执行一系列特别的查询和过滤，认真仔细的分析或者研发人员翻看相关的代码。当我们在程序调用复杂的今天，我们将如何排查？

OpenTelemetry 的模型

如果一个应用程序能够自动扫描和关联这些数据，那么运维人员能够专注于调查他们的系统是如何变化的，而不需要首先确定什么在变化，这就节省他们大量宝贵的时间。带着这样的设计OpenTelemetry把一些独立信息集中化，它以一种综合的方式生成追踪、日志和指标。所有这些连接的数据点以相同的协议一起传输，然后可以输入计算机程序，以确定整个数据集的相关性。让数据形成一股绳还不是独立的柱子。

OpenTelemetry的数据结构化

更完整的数据才能建筑更好的工具，对数据模型要满足2个要求：“所有的数据点都必须用适当的索引连接在一个图上”、“所有代表常见操作的数据点必须有明确的键和值”，下面介绍几个数据模型：

    a.    OT最基本数据结构是属性：由键值对组成的一种对所监测系统详细描述。

    b.    OT最基本对象是事件： 对于大部分非独特的事件的相同属性进行封装成上下文，然后把上下文的分为静态的（资源相关的，通常不改变）、动态的（一种跨度的span，每次调用其属性都会改变）

    c.   事件的聚合：为了统计观察事件出现的频率、超过某个阈值某个值如何随时间变化，这些需要对事件的聚合观察。这类聚合也会有一组属性和语义上的描述(也是我们的指标术语)。

    因为系统运行中的大多数问题都源于资源争夺，其中资源（静态上下文）描述了一个程序正在消费的物理和虚拟信息结构。比如服务、容器和区域都是资源。许多并发的事务需要在同一时间利用相同的资源，通过将事件放在它们所使用的资源的上下文中，就有可能自动检测出资源争夺。为了正确记录整个事务以及问题是由哪些操作触发的，需要记录跨度（动态上下文）描述计算机操作，当指标事件在跨度的范围内发生时问题时不需要猜测或寻找日志，OT明确地将追踪和指标联系在一起。

总结

事件、资源、跨度、指标和追踪：这些都被 OpenTelemetry 连接在一个图中，并且它们都被发送到同一个数据库，作为一个整体进行分析。这就是下一代的可观测性工具。