导读 可观测性是近年来的热门话题之一。一个具备良好可观测性的系统可以提高企业的生产效率，提高产品的质量、用户满意度等。尤其是随着容器云原生微服务架构技术的广泛应用，系统组件越来越多，处理请求的链路越来越长，故障排查也面临着更高难度的挑战，这也是很多企业存在的普遍痛点。本文将分享炎凰数据如何通过新的可观测化能力平台来帮助企业对IT系统或者业务系统进行监控，对性能进行可视化监测。
今天的介绍会围绕下面四个部分展开：1. 如何建设系统的可观测体系
2. 企业建设可观测体系时的痛点
3. 关于炎凰数据公司及产品
4. 建设 YHP 自身可观测性的实践
分享嘉宾｜尤天 上海炎凰数据科技有限公司 平台应用研发经理
编辑整理｜蔡文思
内容校对｜李瑶
出品社区｜DataFun
为了提高企业系统运维时排查故障的效率，亟待引入新的可观测数据和能力。可观测性即通过系统输出的信号来度量和理解系统的状态。因此系统能够输出的信号的类型和质量就决定了系统可观测性的质量高低。有三个重要的可观测信号：Metrics（指标）、Traces（调用链）以及 Logs（日志）。这三种观测信号的应用已较为成熟，有着众多的开源工具可供选择。这三种数据类型通常被称为可观测性的“三大支柱”，但在 CNCF 最新的可观测性白皮书当中更倾向于将其称为“三个主要的信号”。原因是“三大支柱”，容易给人造成建设可观测体系三者缺一不可的错觉。但实际上信号的选择更应从用户的实际需求出发，对于有些用户而言，例如 Metrics 配合 Logs 即可满足系统的可观测性需求。然而，在使用容器云原生和微服务架构的情况下，要建设起具备高度可观测性的系统，这三类数据确实均有必要。故障诊断过程中，三者分别发挥了如下作用：Metrics 用于衡量关于系统整体行为和健康状况的数据，所以它可以监测系统是否存在问题；Traces，尤其是分布式调用链数据，可以快速定位发生问题的位置；Logs 则可以记录发生了什么问题。如果企业的可观测体系建设完备良好，将极大提升问题排查效率，对生产力的提高和产品的稳定性都会有很大帮助。除了这三种最重要的信号之外，还有其他一些信号，比如 dumps、profiles 和 events。这三种信号可能范围并不是很广，成熟度也不是很高。关于 dumps 在后面分享中将会被提及，因此先做个简要介绍。Dumps 是程序崩溃时产生的 core-dump 中的信息，一般会包含程序崩溃时的一些内部的状态，比如内存状态，所以有时能比 logs 更直接地定位问题。因此如果能把 dumps 数据纳入可观测体系，将有助于提升系统故障排查的效率。但在云原生微服务的架构下，定位和获取 dumps 数据的难度比以前更大。2. 三步走建设系统的可观测体系
首先需要明确需求。大多时候探讨可观测系统实现的情况，是在探讨如何实现及时观测系统的健康状态、快速发现和排查问题。实际上可观测系统也可以用来解决其他的问题，比如了解用户的行为习惯，进一步指导公司对产品和投入的规划等。
前面所述，并非一定要将所有重要的信号都纳入才能实现系统的可观测。因此，首先应明确希望通过提高系统的可观测性解决什么问题，需求明确之后方能进一步探讨需要采集何种数据来满足需求。提高系统的可观测性，不能期待建设一步到位，应从当前最重要的需求入手，循序渐进。因为建设起一个良好的可观测系统，需要考虑到的问题非常多。比如可以先纳入指标数据，之后再逐步纳入日志数据或者调用链数据，以及其他一些数据。这种方式也符合现在企业应用建设初期所采用的方法，即快速启动，快速试错，在得到正确反馈时再不断改进。
在明确了需求之后，需要了解数据来源有哪些，复杂程度可能不同。因为有些数据可能已经存在，只需要采集和分析；也有可能现在的系统还不具备输出某些数据的能力，需要进行部分系统改造以便输出观测数据。
例如 logs 应该是被普遍熟知的。在构建每个系统的时候，打 log 是必不可少的要求，log 一般会写到本地文件中，或者是通过网络发送到中心化的日志服务。值得注意的是，log 的格式目前并没有通用规范，所以当我们使用 log 数据来观测系统的时候，有可能需要对 log 的内容做格式化处理，这取决于需求和选用的日志分析工具的要求。
对于 metrics 而言，目前 Prometheus 应属于事实上的标准，大部分开源工具都内置了 Prometheus 的 exporter，用户只要简单地打开就可以使用。对于企业自研的系统，也有工具方便地实现 Prometheus exporter。
对于 traces 而言，或者 distributed
traces，一般需要在系统中通过埋点来实现。
在开源工具中比较普遍的是 OpenTelemetry 的标准，它为常见的技术栈提供了无侵入式埋点的方法。在炎凰数据平台中，也是使用了 OpenTelemetry 这种无侵入式的 instrumentation 来实现 traces 数据的生成。
明确了数据源之后，就该选择合适的工具了，包括数据采集、数据分析的工具。在 CNCF 的 landscape 中，专门开辟了关于可观测性的专题，并且从 logs、metrics 和 traces 角度进行了简单分类，是很好的参考。例如通常用于处理指标数据的工具是 Prometheus；处理日志，有 Fluentd、Elasticsearch；处理调用链的有 Jaeger、OpenTelemetry 等。每个工具处理数据类型时或在不同使用场景中都有所侧重。因此在基于它们建设一套完备的可观测体系时，往往需要通过多个工具的组合才能满足最终的需求。
企业建设可观测体系时的痛点
经过调研，当前建设可观测系统面临的挑战可以总结为以下几大方面：
如前面所言，metrics、traces 和 logs 数据可以从不同的维度提供系统的可观测性，因此在建设全面的可观测体系时，需要采用多种类型的数据，为不同类型的数据选择合适的工具。这将面临的问题是系统的复杂度将非常高。上图为 CNCF 在一年多以前的调研结果，数据显示被调查的大部分企业都面临着上述问题。例如其中的一个问题：“使用可观测性工具，你已经遇到或者感觉将要遇到的最大挑战是什么？”，结果显示排名第一的答案是：系统的复杂度太高，难以使用。排名第二的挑战是缺少相关文档的支持，其根本原因还是系统过于复杂，缺乏良好的可用性。体系的复杂度高意味着需要投入更多的资源，不论是开发工程师还是运维工程师都需要掌握更多的相关技术，最终体现在更高的建设成本和运维成本，这违背了建设可观测系统用以实现降本增效的目的和初衷。
第二个痛点是数据孤岛的问题。由于数据存储分析工具的不同，导致不能快速关联metrics 、traces 和 logs 进行综合分析。首先需要阐明的是，为什么把这些数据关联起来的能力很重要？如上图所示，左图显示的是 metrics、traces 和 logs 数据之间的关联性，首先三种数据均为时序数据，在发生的时间点上有相关性，因此可以通过一个时间窗口来过滤出相关数据。除了数据发生时间的维度之外，在每个可观测数据上还可以通过一些元数据进行绑定，把数据与目标来源绑定，例如来自同一台主机、同一个应用，或者是同一个用户的请求等。用时间窗口加上目标来源的元数据，便于找到来自特定目标的观测数据。一个简单的例子，调用链数据和日志数据可以通过元数据 trace ID 和 span ID 进行关联，当我们在 traces 数据中发现了一条慢的请求，而且定位到了导致问题的 span，那么可以通过 trace ID 和 span ID 的关联，快速定位到问题发生的 log。实际上，metrics 和其余两种数据之间也存在类似的关联方式。在低级别的范围内将它们关联起来，可以在我们通过多个信号或者视角来观测系统时更加灵活顺畅，可以通过在不同信号之间的快速转换大幅提升故障排查的效率。综上，若因数据存储分析工具的不同形成数据孤岛，会导致很难将多种数据类型关联，进而限制我们从可观测数据中挖掘更多价值的能力。
用户体验不佳其实是前面所提及的两个问题导致的。一个具有高复杂度的系统，且不具备数据关联的能力，不仅意味着对使用者的要求比较高，且有可能仍旧无法有效解决目标系统的可观测问题。这一问题也曾在 CNCF 的调查文件中体现。如上图所示，左图的问题是“下一年关于可观测性规划，你的优先级最高的事情是什么？”60% 的回答指明需要找到最佳实践，说明被调研者普遍对于现有的可观测系统满意度较低，认为仍有较大的改良空间。右图的问题是“如果需要你使用可观测系统，会有什么顾虑吗？”多数回答主要集中在使用的难度上，包括集成可观测系统的难度以及学习如何使用可观测系统的难度等。针对上述痛点，是否有好的解决方案，能够保持系统的复杂度可控，同时支持可观测数据之间的快速流转联通，并且对用户而言是易用且有效的？答案就是一体化可观测平台。
一体化可观测平台首先需要有统一的数据采集工具，支持不同类型的可观测数据的采集，并能够在采集端完成一些数据的处理，例如为数据附加元数据，或者对数据内容和格式进行处理，目的是便于后续数据的存储和分析。比如 OpenTelemetry 就是在向该方向努力，争取成为标准。但目前而言，可能在日志方面还不够完善。统一的数据和存储和分析平台，可以实现不同类型数据的查询和数据的高效关联。统一的用户接口，包括分析查询语言、可视化和告警等。用户使用统一接口查询数据时，系统可以快速地在不同类型的数据之间流转，通过一套统一的分析查询语言，统一的可视化和告警等功能，有效降低系统使用的复杂度。总体而言，统一的用户接口可极大降低用户的使用门槛。03
关于炎凰数据公司及产品
炎凰数据成立于 2020 年，是一家专注于研发云原生新一代异构大数据即时分析平台的公司，炎凰数据平台（YHP）是我们的产品。其中值得一提的是，平台核心的大数据分析引擎，是由我们自主研发，拥有全部知识产权。
在此数据平台上，支持将多种类型的数据源数据导入平台，通过存储引擎为数据建立索引，并存入文件系统。数据分析引擎则负责执行来自用户的查询任务。基于这套查询引擎，平台提供了丰富的用户接口，例如可视化的仪表板、告警、即席查询等功能，方便用户进行数据探索和数据知识的积累。用户可以基于上述平台功能和接口来应对不同的使用场景，包括IT 运维领域、可观测领域、生产领域等。
平台使用云原生微服务架构，使用 Kubernetes 编排服务，也支持 Kubernetes 的各种拓展方式和管理方式。其一，数据引擎方面，存算分离的架构，计算层和存储层可以独立拓展。其二，支持单机或者集群部署。例如单机部署时，平台的所有组件可以在同一台服务器上运行。当用户在做测试，或者是查询数据量不大且没有高可用数据需求时，只需要单台服务器即可满足用户的数据分析需求。当数据量增大，或者有了数据高可用的需求之后，再拓展到集群的部署方式。其三，支持标准的 Restful
API 接口，用于和外部系统的集成。对于特定的功能模块，还提供二次开发的框架。譬如，用户可以在我们的平台上拓展用户自己的 SQL 函数、可视化控件等。平台内置了多种数据导入的方式，较为常用的有 Syslog、Kafka 等。除此之外，对于边缘数据的采集，我们也提供了自研的数据采集器 DataScale。炎凰数据平台自身在采集可观测数据的时候，也是依赖于该自研数据采集器。关于数据引擎，首先需要特别指出的是，炎凰数据平台支持混合建模，即同时支持读时建模和写时建模。读时建模可以对非结构化或者半结构化的数据有更好的处理能力。在数据导入数据平台之前，不需要额外的处理，而是在查询阶段构建数据模型。第二，使用标准 SQL 作为查询语言。平台内的任何数据都可以通过标准的 SQL 进行查询，意味着对于很多用户而言使用门槛大幅降低。同时我们也提供了丰富的标量函数和表函数等，便于用户使用 SQL 完成各种数据计算任务。第三，平台还支持基于预计算的计算加速，比如实时物化视图等。平台内置丰富的图表，例如折线图，柱状图等。图表支持二次开发，用户可以按照需求，按照开发框架引入所需的图表。丰富的图表还可以构建成仪表板，即用户可以在仪表板中任意加入图表以及设置图表的大小和比例等。另外值得一提的是，仪表板支持动态参数引入，可以根据查询的结果动态显示图表中的内容，并且支持下钻以及数据的跳转关联等交互动作。另外，还有告警和即时分析功能，这在数据分析领域或者在可观测性场景下都是非常实用的功能。建设 YHP 自身可观测性的实践
接下来介绍炎凰数据平台（YHP）自身可观测性的实践。
炎凰数据平台对可观测性数据的采集，都是通过自研的数据采集器 DataScale 来完成的，支持 metrics、traces 和 logs 三种可观测数据的采集。在过去，用户采集不同类型的可观测数据通常需要使用不同的工具，比如通过 OpenTelemetry 的 collector 采集 trace 数据；使用 Prometheus 的 exporter 拉取日志数据。市面上有大量支持不同数据源的数据采集工具，但在我们的数据采集器里，将这些常见的数据采集方式统一集成在平台的数据采集器内部。不仅如此，数据采集器还可以配置数据源以及在对接数据源之后构建数据处理的逻辑。因此，OpenTelemetry 的 collector，或者是 Prometheus exporter 的 scraper，以及其他各种数据源，都可以作为数据采集器的 source 配置在内。数据被采集集中之后，会被流转至数据处理模块进行数据加工处理，例如给数据附加元数据信息，之后再将数据导入炎凰数据平台。使用统一的数据采集器的好处主要有两点：其一是所有数据源的接入能够被统一管理，并且提供了具有很好的用户体验的 UI，使用户能够以可视化的方式来管理数据的接入；其二是在数据存储到平台之前，可以在采集端对数据进行加工处理，比如补充元数据，处理数据的结构和格式，便于后续的存储和分析。
上图是炎凰数据平台中数据采集器的部署方式。数据采集通常有两种场景，一是在数据平台的各个节点上采集本地数据，另一个是使用中心节点采集服务数据。因此炎凰数据平台中的数据采集器有两种部署方式，一种是按 Kubernetes DaemonSet 的方式部署，在每个节点运行。这种数据采集器会采集本地的日志文件，从本地的 node exporter 上拉取主机的 metrics。另外一种方式是用 Kubernetes Deployment 的方式运行数据采集器。作为 aggregator，负责拉取平台中各个应用的指标数据，以及接收来自 Web 服务的 traces。上述两种方式保证了既不会漏掉任何数据，也不会出现数据的重复采集。
当可观测数据被采集到炎凰数据平台之后，metrics /
traces / logs 分别存在不同的数据集（相当于数据库中表的概念）里。主要的原因是为了性能上的优化调整，因为通常是按数据集查询，在查询某一类型数据时，性能不会受另外两种数据的数据量影响而下降。由在文章开头关于三个重要指标的图示中可见，不同类型的数据的数据量的量级是不同的，通常最多的是日志数据。对于 metrics 数据的查询，实际情况下都需要比较快的响应速度，因此使用上述存储方式，就不会因为 logs 或 traces 的大数据量而影响查询 metrics 的性能。使用多个数据集的另一个好处是可以为不同类型的数据设置不同的生命周期。不同类型的数据根据相应的使用场景和不同的特性，需要保存的周期也不同。例如 logs 和 traces 通常需要较长的保存周期；而指标数据，可能只需要保存近期的数据。所以从右图中可见，我们可以为每个数据集设置限制容量，或者利用数据的时间戳用时间窗口做限制。当然用户也可以特殊处理某些特定场景的数据。例如出于合规的原因，或者出于其他原因需要保留数据，但不希望影响到查询性能，也可以选择把数据归档到指定的路径去。
上图是数据被采集进来之后，数据的内容呈现形式。三个图分别显示的是调用链数据（traces）、指标数据（metrics）和日志数据（logs）。左上角的图是指标数据。带下划线开头的都是附加的元数据字段，非下划线开头的都是指标数据的原始字段。比如图中“counter.value”字段的值以及指标的名字都是原始字段。此外附加的信息，比如节点信息、类型信息、主机信息，这些元数据信息都是在后面做关联查询时使用。右边的图，是调用链的数据。元数据同样被附加在以下划线开头的字段，其中包括属于哪个服务、来自于哪个 Kubernetes 的 namespace 等等。下方的原始字段，也都是符合 OpenTelemetry 标准的 tag 字段。左下角的图，是一个普通的日志数据，其中高亮处为 trace ID。当我们打开了炎凰数据平台的可观测性相关功能时，会将日志中的调用链的 trace ID、span ID 写入 logs，便于依据 trace
ID 和 span ID 得到这个应用相关的日志信息。
上图是一个查询的例子：通过使用统一的 SQL 查询分别查询 traces 和 logs，以及通过 trace ID 关联数据进行查询。如图所示，左边的 yhp_monitoring_traces，是存储 traces 的数据集。可以通过解析出的字段进行过滤，得到目标的调用链记录。例如目标数据为 HTTP 返回值为大于等于 400 的异常的请求调用记录，且从 root span 开始的、kind=2 的 trace。得到了相关的 trace ID 之后，再用另外的查询，从 _internal 的数据集中把这个 trace 相关的所有日志筛选出来，查看请求究竟在服务里面发生了什么事情。这是一个手动去做关联查询的场景。炎凰数据平台的仪表板是支持下钻功能的，这意味着在仪表板上，用户可以设置通过点击仪表板上的相关查询得到 trace ID，直接跳转到日志查询的结果。
上图展示的是基于可观测数据构建的统一可视化仪表板和告警。基于指标数据和调用链数据去构建可视化看板，直观展示平台是否存在异常。另外告警功能体现在各组件的巡检功能上，即每隔几分钟定期检测平台有无异常出现。若有异常出现，则会在该仪表板中显示出异常状态，并且在下方的告警列表中会有相应的告警。同时也附加了针对 logs 中的已知问题的告警场景。中间的图展示的是基于 metrics 的仪表板，基于主机的 metrics 数据来展示主机当前的系统状态。右图则是基于 metrics 和 traces 来展示一个 Web 应用的健康状况。这些示例展示了利用一体化可观测平台构建可观测性的一个很大的优势就是避免了数据孤岛的问题。当需要观测一个应用的健康状况时，所有相关的观测性数据都可以被集中作为健康程度的指标数据进行可视化。
这里将简述为了提高系统可观测性，对更多可观测性相关数据类型的尝试。在自研的数据处理引擎开发过程中，发生 core-dump 的场景是比较常见的。若能够快速分析 core-dump 的信息，能够有效提高开发效率。但目前针对 dumps 信息的采集，尚未有成熟的方案。且因 Linux
kernel 的一些限制，尚未找到非常理想的采集方式。在 Docker 社区中有提到一些方案，例如允许每个 container 去设置 core-dump 文件的 pattern 等，但这种技术可能短期内还无法实现。当前，炎凰数据平台采集 dumps 信息的方式是使用共享的 Kubernetes
PV，用于存储各个服务的 core-dump 文件，每个服务都在自己的专属目录下生成 core-dump 文件。数据采集器从共享的 PV 中采集所有服务的 dumps 数据，再通过 core-dump 文件的路径或者文件名的信息来补充元信息标识，用以注明 core-dump 是发生在哪个服务的哪个模块。Dumps 数据被导入炎凰数据平台之后，同样可以创建仪表板，还有相关的告警。仪表板可以展示各个服务发生 core-dump 的历史，倘若 core-dump 文件能够被解析出来，在这个仪表板的下半部分，还可以直接展示出 core-dump 发生时刻的 backtrace，让开发人员可以快速了解发生异常的原因，节省自行寻找 core-dump 文件并解析所花费的时间。最后是关于 Kubernetes 健康监测。目前，在炎凰数据平台尚未建立一套关于 Kubernetes 的数据采集体系。但我们采用了一种类似于监测网络链路健康状况的方式，使用了一款名为 Kuberhealthy 的工具。它会主动执行 Kubernetes 的一些操作，例如拉取镜像、获取 Pod，并记录操作的结果，这些操作结果可以通过 Prometheus 的 exporter 输出。我们将该数据导入到炎凰数据平台中，再通过构建告警和仪表板来监测 Kubernetes 集群的健康状况。综上所述，一体化可观测平台的优势还是比较明显的。首先统一了数据的采集、分析、存储三大模块的过程，极大降低了系统的复杂度，减少了系统的运维成本和系统需要的资源等。同时一体化可观测平台提供了较强的、能够关联不同类型数据的能力，也提供了挖掘可观测数据更多价值的可能性。并且在用户体验上，统一的用户界面也提高了易用性。
炎凰数据平台最新的版本是 2.11（*此处的2.11版本具体指2023年8月5日DataFunSummit2023：云原生大数据峰会的分享版本），同时推出了企业版和社区版。社区版是完全免费的版本，用户可以在本地运行单机版，而且其中很多数据分析的核心功能与企业版并没有区别，企业版更多的是着力于一些与企业相关的、侧重企业运营的功能。欢迎大家关注和体验。