云原生可观测洞察及openEuler社区实践

openEuler2024-01-18eBPF

应用可观测性可以对企业运营产生的实际数据进行分析，可观测性将成为企业数据驱动决策的最强支撑。云原生时代的基础设施更复杂，也暴露出可观测性存在一些问题，包括基础设施观测能力不足，缺乏应用视角的基础设施观测数据等，这些都为下一代云原生可观测提供了机会与挑战。

openEuler社区项目gala-gopher[1] 基于 eBPF 技术完成一系列全栈可观测实践工作。

eBPF及其对可观测的意义

eBPF是一个能够在内核运行沙箱程序的技术，提供了一种在内核事件和用户程序事件发生时安全注入代码的机制，使得非内核开发人员也可以对内核进行控制。随着内核的发展，eBPF 逐步从最初的数据包过滤扩展到了网络、内核、安全、跟踪等。

原理：eBPF 由事件驱动，通过 Hook 方式在数据流中执行 eBPF 程序。Linux 内核中预定义了一系列常用的 Hook 点（用户态也有 uprobe、USDT 的动静态 Hook 点）。eBPF利用 Just-in-Time (JIT) 技术可以使eBPF代码的运行效率媲美内核原生代码和内核模块；Verification 机制可以保障eBPF 代码安全地运行，不会导致内核崩溃或进入死循环；eBPF Helper机制使 eBPF代码可以访问内核、应用的运行态数据、状态。

可观测性：通过Hook内核、用户态程序，由数据流、系统事件等驱动 eBPF 沙箱内观测程序，可以灵活、按需的观测业务、系统状态，同时给可观测带来低负载、高安全、无侵入等技术特点。

云原生场景运维带来的变化与挑战

云原生场景运维带来的变化与挑战：

变化1：虚拟化单一架构中"一刀切"分层运维（基础设施、应用分层）向云原生场景融合式运维发展，需要提供全栈观测、运维能力；
变化2：云原生多技术体系（Linux、CNCF 等）、快速演进等特点，要求可观测性解决方案与其应用/基础设施技术栈解耦，提供非侵入观测能力；
变化3：云原生高密度、分布式部署方式，要求具备集群运维视角，从业务集群视角逐层/级定界、定位至具体问题根因。

云原生上述技术特征使得可观测能力的构筑**，天然应下沉至基础软件之内**，而 eBPF 技术在基础软件（尤其是内核）的可观测性方面尤为突出。因为其技术特征天然与云原生可观测要求完美吻合：

无侵入：通过 eBPF 字节注入技术可以快速地进行可编程无侵入式观测逻辑注入，轻松应对云原生场景快速迭代的场景特征。
可移植&跨平台：通过标准eBPF ISA、CO-RE 等技术可以实现不同 Linux 版本、不同 ISA 架构、不同平台之间兼容相同 eBPF Program，可以轻松应对云原生场景中不同平台、系统混合部署的场景。
全栈：通过 eBPF + USDT、eBPF + Tracepoint、eBPF + kprobe 等技术，可以覆盖内核、运行时、基础库等大部分基础软件，轻松应对云原生多语言、多网络协议、厚重软件栈的场景特征。

业界洞察

可观测性在 K8S 场景逐渐重要，2023年云原生报告显示[2]，云原生集群内辅助类应用工作负载上升至 63%，其中近 80% 的企业部署可观测性方案（同比增长 29%）。

下面介绍几款业界较成熟的云原生运维系统：

Deepflow

以网络为中心展开云原生场景运维工作，围绕 eBPF 构建可观测技术，在此基础上构建四大能力特性[3]：

Universal Map：非侵入方式实时构建集群拓扑，全链路时延观测。
Continuous Profiling：在线持续性代码性能剖析能力。
Distributed Tracing：非侵入全链路分布式跟踪，覆盖ServiceMesh、数据库、DNS、NIC 等基础设施。
无缝集成：数据存储可以无缝与Prometheus、Skywalking 等生态软件对接；数据采集侧可以无缝接入生态采集探针（OLTP等）；观测数据携带 K8S、VPC等云平台上下文信息。

Pixie

Pixie 围绕 Kubernetes应用程序可观测性工具[4]，基于 eBPF 技术构建，可以查看K8S集群运行状态（ServiceMap、集群资源、应用流量），还可以深入查看更详细的视图（pod 状态、火焰图、单个应用请求）。主要特性包括：

网络监控：K8S集群内网络流量监控，DNS 监控，TCP质量监控（丢包、重传、拥塞等）。
基础设施监控：Pod、Node、Namespace 等不同维度的资源（CPU、内存、网络、存储等）监控。
Service Performance：K8S Service 拓扑构建，Service 性能（覆盖 HTTP1.X，PGSQL，gRPC，Redis 等）监控，性能包括时延、吞吐量、错误率等。
应用性能Profiling应用性能持续性能剖析，支持多语言栈的性能火焰图分析能力。
中间件监控（DB、Kafka 等）：提供中间件关键数据流的观测能力，包括 DB 访问过程的观测，Kafka topic 生产/消费过程的观测等。

eBPF的局限性及解决方案

在一些有独立运行时的高级语言场景中（尤其是 java），eBPF 的可观测性存在一些局限性，主要表现在：

加密流（由JSSE 类库完成加减密）的可观测无法通过 eBPF + uprobe 方式完成观测，导致无法完成加密场景的网络可观测；
语言堆栈信息不完整，比如无法有效获取JVM 堆内的软件栈信息，导致在性能Profiling时，堆栈信息不完整，不利于问题定位。
解决方案：针对java场景的特殊性，结合java agent + eBPF技术，综合完成非侵入的可观测能力。例如 java 应用性能 Profiling 的解决思路如下：

**openEuler的实践情况介绍** ---------------------------

openEuler社区项目gala-gopher[1]围绕eBPF 技术，并充分考虑多种观测技术的结合，采取探针式架构，通过集成探针快速构建观测能力，其观测全景图如下：

关键特性

探针框架：：提供 eBPF 探针框架，负责管理探针生命周期，以及探针任务管理、数据上报等工作。
性能观测：：以火焰图、timeline 图表形式辅助定位应用/系统的内存泄漏、死锁、CPU 调度等疑难故障。
**应用观测：**提供进程粒度全栈性能观测能力，覆盖应用、容器、基础库/中间件、内核等。
**网络流量观测：**提供云原生场景全流程跟踪能力，具备网络流拓扑构建能力（覆盖各种云原生网络场景），提供L4、L7 层流量各种指标采集能力。

架构及关键技术特征

扩展性：探针式架构，按需开启采集范围&能力，亦可快速对接第三方探针。
非侵入&多语言：应用/容器镜像零修改，无需重启；支持对多语言应用的观测，覆盖C/C++、Go、Java、Python 等主流语言。
生态：支持OpenTelemetry生态接口，支持对接多种开源运维软件（Prometheus、ES等）。
丰富的上下文：提供自动化标签能力，所有数据数据应用标签（进程信息、容器信息等）、Node 标签（IP、Machine ID等）、K8S 标签（POD 信息、Namespace 信息）等。

详细能力可以参考社区文档[5]。

欢迎加入

欢迎感兴趣的朋友们参与到 openEuler eBPF SIG，探讨 eBPF 领域技术，也可以添加小助手微信，加入 gala-gopher交流微信群。欢迎您的围观和加入！

扫码添加小助手

【免责声明】本文仅代表作者本人观点，与本网站无关。本网站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文仅供读者参考，由此产生的所有法律责任均由读者本人承担。