云原生应用可观测架构设计（方案详解与实践分享）|云原生|元数据|客户端节点|应用程序|磁盘|调用|跟踪

来源：市场资讯

（来源：twt企业IT社区）

导读

云原生可观测性已从单纯的IT运维工具，发展为数字化转型的核心技术。本文系统性地介绍汽车制造业云原生应用可观测性架构的设计理念、关键技术选型，并分享了几个具体场景下的实践经验，具有实践价值和指导意义，对其他行业也很有参考性。

作者：杨承龙

某机械制造企业云平台架构师

一、引言

信息与通信、云计算、大数据、人工智能等数字化技术的进步，推动了企业数字化转型和汽车“新四化”的发展，传统汽车制造企业正面临前所未有的IT架构变革。现代汽车制造已不再是单纯的机械装配过程，而是融合了物联网、AI、大数据和云计算的复杂数字化生态系统。

在传统汽车制造环境中，监控主要关注PLC、机器人等工业设备的运行状态，数据采集频率以秒级甚至分钟级为主。而云原生架构下的汽车制造平台，需要处理从供应链管理、生产排程到质量控制的各类微服务，这些服务通常以容器化方式部署，具有动态调度、弹性伸缩等特性，传统的监控手段已无法满足需求。

汽车制造企业面临着特殊的可观测性（Observability）挑战：

1.混合架构复杂性：既有传统OT系统，又有新建云原生平台

2.数据多样性：时序数据、日志数据、追踪数据等多源异构

3.实时要求：核心生产系统需要毫秒级响应和故障检测

4.合规压力：汽车行业严格的质量追溯和合规要求

本文将系统性地探讨汽车制造业云原生应用可观测性架构的设计理念、关键技术选型和实践经验，帮助IT同行构建适应汽车行业特点的现代化可观测体系。

二、云原生可观测性架构设计原则

2.1 全栈覆盖：分层观测模型

针对汽车制造的多层IT架构，一般采用“四层观测模型”进行全栈可观测性，以云原生应用为中心，自上而下追踪用户体验层、业务流程层、应用服务层的各种监控对象性能指标数据，最终以应用为单位展示应用自身的健康程度。

用户体验层：MES操作界面响应、AGV调度效率等

业务流程层：订单处理、生产排程等业务流

应用服务层：微服务、服务网格等

基础设施层：物理服务器、虚拟机、容器平台、网络等

2.2 多维关联：业务指标与技术指标的融合

作为被监控观测的对象，云、容器以及云原生应用不应该被孤立看待，需要各类型层面的监控数据有效整体联动。特有的业务指标需要与技术指标深度关联融合，利于指标联动，故障快速定位：

业务视角：关注生产节拍、设备综合效率（ OEE ）、一次合格率等KPI

技术视角：追踪服务延迟、错误率、资源利用率等指标

例1- 业务指标联动：将生产节拍指标直接作为HPA伸缩依据，实现IT资源与生产需求的动态匹配。

例2- 信号关联定位：通过使用相同的元数据结构和标签关联数据，确保数据一致性。连续收集所有可观测性信号，标记时间戳，通过请求 ID 关联日志和跟踪数据，便于快速定位日志。

2.3 实时优先：平衡成本与时效性的设计

企业内部有各种类型的数据，全量高频采集成本和存储成本巨大，根据场景不同，数据采集设计原则如下：

关键路径：毫秒级采集（如焊装机器人电流波形，实时性要求极高）

重要业务：秒级聚合（如车身流转计数、检测台质量数据数据）

辅助系统：分钟级采样（如办公系统健康检查）

三、可观测性技术架构设计

可观测性是确保系统稳定性和高效运行的关键组成部分。涉及微服务的链路跟踪、日志采集、状态采集、资源监控、性能监控等多个方面。将Metrics、Logging、Tracing三类关键数据密切关联，实时监控和分析系统运行状态，全面呈现端到端的系统运行全貌，确保系统稳定性、性能和安全性。

指标Metrics：连续时间下的系统的值，常规的包含计数、计量两种类型

链路Tracing：业务运行各个模块的调用关系，监控数据的可靠链接纽带

日志Logging：系统或应用输出的时间相关的记录，方便定位应用系统错误

3.1 指标（Metrics）架构设计

指标是衡量系统性能和资源使用情况的关键量化数据。常见的指标包括CPU使用率、内存占用、网络流量、请求响应时间、吞吐量等。在云原生架构中，由于系统的动态性和分布式特性，实时监测这些指标对于掌握系统的运行状态至关重要。传统数据采集主要基于agent方式、snmp协议、日志分析等方式，存在侵入性、不灵活、兼容性差、数据采集不全面等问题，相比于传统监测数据采集与分析技术，基于eBPF技术的可观测系统在数据采集方面有着显著的优势，下面主要介绍基于eBPF技术的可观测实践探索。

3.1.1 基于eBPF构建云原生数据采集

随着云原生应用复杂度增加，eBPF技术因其独特性能有效应对传统可观测挑战。

基于eBPF云原生可观测性技术架构

eBPF是一种数据包过滤技术，从BPF(Berkeley Packet Filter) 技术扩展而来，它起源于 Linux 内核，可以在操作系统内核中运行沙盒程序。eBPF被用于安全有效地扩展内核的功能，而无需更改内核源代码或加载内核模块。

基于eBPF在操作系统内核特性优势，与OpenTelemetry结合实现云原生观测数据收集处理的架构，极大增强云原生环境可观测性能力。基于eBPF的可观测性架构如下图：

数据接收阶段：eBPF技术在用户空间和内核空间之间架起了“桥梁”，通过将eBPF程序加载到trace points、内核、及用户空间应用，经用户态eBPF程序预处理后，由 OpenTelemetry规范的Receiver 接收；

数据处理阶段：依据规范进行协议解析、指标处理和Kubernetes元信息填充。

数据导出阶段：通过Exporter将数据输出到可观测平台。

该架构具有采集全面、完全无侵入，对应用系统来说完全无感知、资源消耗小、灵活可伸缩和适应容器动态变化等优势。

3.1.2 指标可视化

利用Grafana创建各种直观、简洁的仪表盘，将Prometheus采集到的指标数据以直观的图表形式展示出来。例如，在动态网络性能监控中，eBPF 程序获取进程与地址关系、流量统计等数据，构造动态拓扑图；在HTTP黄金指标监控中，解析网络报文获取关键指标并关联服务标识；在性能剖析中，基于On-CPU事件绘制火焰图，分析CPU使用率高的问题。

通过设置不同的仪表盘面板和告警规则，能够实时监控系统的性能指标，并在指标超出正常范围时及时发出告警。

3.2 日志（Logging）架构设计

日志是记录系统运行过程中各类事件的重要载体。在云原生环境下，大量的微服务、容器以及分布式组件会产生海量的日志数据。这些日志包含了丰富的信息，如请求的处理过程、错误信息、系统状态变化等。通过对日志的收集、存储和分析，能够还原系统的运行轨迹，发现潜在的问题。

3.2.1 日志统一收集

采用边缘日志预处理+中心持久化存储的模式，通过日志标签实现多维度关联，统一的日志管理解决方案可保留事件上下文和相关性，自动执行相关性和分析等任务，便于访问和分析，使团队能够腾出时间执行故障排除和根因分析等任务，支持探索性分析、数据洞察力的安全协作，以及运营和应用程序的主动优化。

日志类型

应用日志：记录应用程序的运行情况，例如错误信息、用户操作、请求参数等。

系统日志：记录操作系统级别的事件，例如 CPU 负载、磁盘 I/O、进程状态等。

安全日志：记录访问控制、身份验证、异常请求等信息，确保系统安全性。

集中式日志管理

使用 ELK（Elasticsearch + Logstash + Kibana）、Graylog、Splunk进行日志存储、索引和可视化分析

ELK工作原理：常用 Logstash、 Fluentd、Filebeat等日志代理工具，实现多源日志的采集，数据源采集数据，并对数据进行过滤，格式化处理，然后交由Elasticsearch存储，kibana对日志进行可视化处理，查询数据生成图表。

3.2.2 日志智能解析与存储

日志可分为应用程序日志、安全日志、系统日志、审核日志和基础架构日志等不同类别。其记录的信息为自由格式文本，解析难度较大，但在故障分析中具有重要价值。通过解析、分段和分析日志文件获取信息，还可将日志数据转换为其他可观测性信号。根据数据获取颗粒度，日志可设置“错误”“警告”“信息”“调试”等不同级别。

实时解析：使用Grok模式提取设备报警代码

智能路由：关键日志实时告警，普通日志批量分析

长期归档：满足IATF 16949 、TISAX的质量记录要求，要求保留10年以上

在进行存储设计时，采用多层存储架构，热数据使用内存时序数据库，温数据使用压缩时序存储，冷数据转储到对象存储。设置合理的日志保留策略，避免存储成本过高，可采用S3对象存储和分布式文件存储归档旧日志。

3.2.3 日志可视化分析

基于日志的追踪将Trace、Span等信息输出到应用日志中，从日志中反推调用链拓扑关系，具有低侵入性和低性能影响的优点，但依赖日志归集，精准度有限。基于服务的追踪通过注入追踪探针获取服务调用信息并发送给链路追踪系统，资源消耗大、侵入性强，但精确性和稳定性较高，被 Zipkin、SkyWalking等广泛采用。

在Kibana中，通过创建各种查询和可视化报表，对存储在Elasticsearch中的日志数据进行深入分析。例如，使用Kibana的Discover功能，可以自由搜索和过滤日志数据，查看特定时间段内的日志记录；通过创建Timeline可视化报表，可以直观地了解系统在一段时间内的事件发生顺序和频率。

当应用程序出现异常时，通过查看相关的日志记录，详细了解异常发生的时间、相关的上下文信息，为快速定位问题提供有力支持。

3.3 链路追踪（Tracing）实践

链路追踪是可观测性的重要组成部分，用于记录请求在整个应用程序中的传播路径。在云原生应用中，一个请求往往会经过多个微服务的处理，涉及多个容器和网络节点。分布式追踪能够将这些分散的处理过程串联起来，形成完整的调用链。通过分析调用链，我们可以清晰地看到请求在各个环节的耗时情况，可以快速定位问题并进行优化。

3.3.1 链路追踪设计

一般通过开源产品SkyWalking、Jaeger、商业产品dynatrace、日志易等工具来跟踪微服务之间的调用链路，通过跟踪请求的完整路径，快速定位性能瓶颈和故障点。

常见的分布式追踪工具：

a. 基于 SDK 的工具，如Jaeger，可获取丰富数据但通用性差、部署成本高；

b. 基于探针的工具，如SkyWalking Java探针，无需修改源代码但获取数据有限；

c. 基于代理的Sidecar，无需修改代码但串联跨度数据困难；

d. 基于eBPF实现的方式，具备低侵入性、高性能和细粒度数据收集分析能力。

链路监控使用规范参考：

a.在接口服务调用中增加TRACE_ID信息

需要在接口服务调用的输入中增加TRACE_ID字段，作为服务链跟踪使角。

b.TRACEID组成说明

一个用于服务链监控的TRACEID的生成，由以下信息所构成。

概述：UUID+SPANID+SPANID+SPANID组成

说明：UUID为每一个服务调用链，生成一个独立唯一的UUID值

SPANID：SPANID为01、02顺序编码，服务调用每进一层增即增加一层SPANID

依据上述规则，生成的一个参考如下:

TRACE_ID: 550e8400-e29b-41d4-a716-446655440000.01.01.0 2

TRACE_ID设计参考

3.3.2 链路可视化

链路追踪工具UI界面一般会提供丰富的调用链可视化功能，能够以图形化的方式展示请求在各个微服务之间的调用路径和耗时情况，实现跨系统、跨协议的调用链可视化。通过分析调用链图，可以快速定位性能瓶颈所在的微服务和具体的调用环节，为优化系统性能提供有力依据。

3.4 告警（Alert）设计

从分级分类、告警集成、处理流程三个方面浅谈一下告警处理的相关实践方法，为开发和运维团队提供一套完整的告警处理思路。

3.4.1 告警分级分类

告警分级：将告警分为 warning（警告级别，起简单通知作用）、problem（问题级别，系统出现问题需及时修正）、critical（重要级别，系统严重错误导致线上大面积不可用）三个等级，不同等级有不同解决方式和处理流程，便于区分优先级处理问题。

故障分级：告警分级后，真正告警时，还有故障分级。不同的故障等级，会影响该故障的参与人数和处理流程，对应告警分级也分3个等级。

事件单：相对容易处理，对应warning级别；

问题单：事件单未处理会升级，problem级告警直接认定为问题单，通知开发人员；

故障单：问题未处理再次升级，系统严重错误，影响面广，需多人处理，对应critical级别，故障等级可能因未及时处理而升级。

3.4.2 告警集成

通知方式：根据故障分级选择不同通知方式。事件单通过企业沟通软件通知，如钉钉、企业微信、welink等；问题单可能用短信或电话通知；故障单电话联系负责人并拉群（war room）共同解决问题。若问题未及时处理，通知方式会升级。

通知内容：告警内容应简洁，包含发生时间、错误现象、错误详情（问题跟进链接），帮助人员快速了解故障情况并响应。

3.4.3 处置流程

非重要级别告警处置：确认告警原因，当天给出解决办法并跟进改进，记录问题原因、恢复方法和后续改进措施。

重要级别告警处置：相关人员聚集处理，明确事故负责人（把握故障进度、协调资源、汇总复盘）和问题处理团队（负责问题处理）的职责。处理步骤包括聚集参与者、紧急恢复并保留现场、发现原因、确认并实施解决方案、事故复盘，复盘形成的故障单需包含发生时间、发现时间、结束时间、处理流程、故障原因、影响范围、后续改进措施等内容。