imtoken钱包安卓版手机下载|deepflow

作者： imtoken钱包安卓版手机下载

2024-03-07 18:08:42

DeepFlow 产品 | 云原生-可观测性-零侵扰采集-全栈可观测-分布式追踪-eBPF-Wasm-DeepFlow可观测性平台

***

简体中文English 产品 eBPF 文档博客 Star

***

立即体验企业版体验社区版体验简体中文English 关于 DeepFlow DeepFlow 简介DeepFlow 架构DeepFlow 关键特性DeepFlow 路标DeepFlow 产品社区版（Community Edition）企业版（Enterprise Edition）云服务（Cloud Edition）版本功能对比DeepFlow 用户文章安装社区版简介All-in-One 快速部署监控单个 K8s 集群监控多个 K8s 集群监控传统服务器监控云服务器监控托管 K8s 集群监控 Serverless PodDeepFlow 升级安装企业版联系我们最佳实践 Agent 高级配置Server 高级配置特殊环境 Agent 部署降低存储压力生产环境部署建议企业版生产部署联系我们核心特性服务全景图 AutoMetrics应用性能指标应用调用日志网络性能指标网络流日志应用协议列表指标和算子的计算逻辑分布式追踪 AutoTracingSpring Boot DemoIstio Bookinfo Demo 持续性能剖析 AutoProfiling AutoTagging 消除数据孤岛SmartEncoding基础资源标签自定义资源标签可选的进程信息标签额外的云资源标签CMDB 中的业务标签企业版使用帮助租户页面数据查询搜索服务搜索框路径搜索框日志搜索框指标搜索框搜索快照左侧快速过滤视图概述视图列表视图详情添加子视图模板变量子视图概述流量拓扑调用链追踪折线图柱状图饼状图分布图表格趋势分析图指标指标查看指标摘要事件概述资源变更文件读写告警全景图概述业务定义服务列表服务拓扑应用概述指标统计路径统计路径拓扑调用日志调用链追踪持续剖析右滑框网络概述服务统计网络路径网络拓扑流日志NAT 追踪资源盘点PCAP 策略PCAP下载基础设施概述主机容器告警告警策略告警事件推送端点资源概述摘要资源池计算资源网络资源网络服务存储服务容器资源进程资源其他资源报表报表管理员页面联系我们开发与集成数据处理 Wasm plugin 数据输入导入 Metrics AutoTagging集成 Prometheus 数据集成 Telegraf 数据导入 Tracing 全栈分布式追踪AutoTagging调用 APM 的 Trace API导入 OpenTelemetry 数据导入 SkyWalking 数据导入 Profile 导入 Profile 数据数据输出查询 API SQL APIPromQL APITrace Completion API 导出输出 OpenTelemetry ExporterPrometheus Remote Write 企业版开发联系我们故障处理 FAQGrafana 查询慢Agent 常见故障Server 性能调优企业版维护联系我们发行注记 DeepFlow 版本规则版本发布时间线v6.5 CE Release Notesv6.5 EE Release Notesv6.4 CE Release Notesv6.4 EE Release Notesv6.3 CE Release Notesv6.3 EE Release Notesv6.2 CE Release Notesv6.2 EE Release Notesv6.1 CE Release Notesv6.1 EE Release Notes 关于 DeepFlow DeepFlow 产品 # 1. 社区版（Community Edition） DeepFlow 社区版是一个开源版本，是一个高度自动化的可观测性数据平台。

它的核心采用 Apache 2.0 许可证，前端页面完全基于 Grafana，因此采用 AGPL 许可证。

它具备高效建设可观测性所需要的的常用功能，包括： Universal Map（AutoMetrics）

基于 eBPF/cBPF，自动采集应用、网络、系统全栈性能指标基于 eBPF/cBPF，自动采集 TCP/UDP 流日志基于 eBPF/cBPF，自动采集 HTTP1/2、HTTPS（Golang/openssl）、Dubbo、gRPC、SOFARPC、FastCGI、MySQL、PostgreSQL、Redis、MongoDB、Kafka、MQTT、DNS 等应用调用日志 Distributed Tracing（AutoTracing）

基于 eBPF/cBPF，自动追踪微服务分布式调用链 Integration

集成 Prometheus/Telegraf 等指标数据，解决数据孤岛和高基数问题集成 OpenTelemetry/SkyWalking 等追踪数据，实现全栈分布式追踪 AutoTagging

支持同步公有云资源标签，并自动注入到所有观测数据中支持同步容器资源标签和自定义 Label，并自动注入到所有观测数据中支持 SmartEncoding 高性能数据标签存储集成和管理

支持使用 Grafana 展示指标、追踪数据支持统一监控多个 K8s 集群及普通云服务器采集 Agent 支持运行于 K8s 节点、Serverless Pod、Linux Host 环境中支持在 X86、ARM 体系架构下部署 # 2. 企业版（Enterprise Edition） DeepFlow 企业版是一个高度自动化的一站式可观测性分析平台，

它拥有企业级的可视化及管理界面、具备完整的数据分析能力和增强的数据治理能力。

除社区版所有功能之外，它还有如下功能：更丰富的 AutoMetrics 和 AutoTracing 数据

Agent 支持运行于多租户 Serverless K8s 节点、Windows Host 上 Agent 支持运行于 KVM/HyperV/ESXi/Xen 宿主机环境中 Agent 支持运行于使用 DPDK 数据面的宿主机和物理服务器上 Agent 支持运行于专属服务器上以收集和分析物理交换机的镜像流量，分析传统四七层网关、专有云四七层网关的性能 Agent 支持运行于专属服务器上以收集物理交换机的 NetFlow、sFlow 数据 Continuous Profiling（AutoProfiling）

支持基于 eBPF 的零侵扰持续性能剖析支持基于 cBPF 的 TCP 逐包时序图、原始 Packet 等 Network Profiling 能力 AutoTagging

与专有云产品深度适配，包括阿里云、腾讯云、华为云等主流云平台分析能力

支持指标、追踪、日志数据的关联查询、自动跳转支持一站式的告警、报表、自定义视图等多团队协同功能高级特性

支持按需配置流量过滤策略，向安全、网络、审计等流量消费工具分发流量支持为多租户提供服务，支持数据权限隔离支持 Agent 与 Server 之间的加密数据传输支持统一监控多个 Region 的专有云、公有云、容器资源企业级服务

提供完善的金融、能源、运营商（IT、5GC）、车联网等行业的云原生可观测性建设解决方案提供企业级的售后支持服务，包括故障排查、性能调优、版本升级、可观测性最佳实践落地等 # 3. 云服务（Cloud Edition） DeepFlow 云服务版是一个完全托管的一站式可观测性平台，

它拥有与企业版一致的功能，目前处于测试试用阶段。 # 4. 版本功能对比模块支持能力社区版企业版 Universal Map eBPF/cBPF AutoMetrics ✔ ✔ 应用性能指标 - 进程/容器/云服务器 ✔ ✔ 应用性能指标 - 宿主机/专有云网关/网络设备 ✔ 网络性能指标 - 进程/容器/云服务器 ✔ ✔ 网络性能指标 - 宿主机/专有云网关/网络设备 ✔ 网络性能指标 - NetFlow/sFlow ✔ 存储性能指标 - 进程/容器/服务器 ✔ ✔ 存储性能指标 - 宿主机/专有云网关 ✔ 应用调用日志 - 进程/容器/服务器 ✔ ✔ 应用调用日志 - 宿主机/专有云网关/网络设备 ✔ 网络流日志 - 进程/容器/服务器 ✔ ✔ 网络流日志 - 宿主机/专有云网关/网络设备 ✔ 网络流日志 - NetFlow/sFlow ✔ 内置应用协议解析 - 开放标准协议 ✔ ✔ 内置应用协议解析 - 封闭标准协议 ✔ 基于 TCP 流重组的增强协议解析能力 ✔ Wasm/so 协议解析插件 SDK ✔ ✔ Distributed Tracing eBPF/cBPF AutoTracing ✔ ✔ 利用 X-Request-ID 增强 AutoTracing ✔ ✔ 利用 MySQL Comment 增强 AutoTracing ✔ ✔ 利用已有 TraceID 增强 AutoTracing ✔ ✔ Wasm/so AutoTracing 增强插件 SDK ✔ ✔ 集成 APM Span - OpenTelemetry/SkyWalking ✔ ✔ eBPF Span - kprobe/uprobe ✔ ✔ cBPF Span - 容器/云服务器 ✔ ✔ cBPF Span - 宿主机/专有云网关/网络设备 ✔ 智能 NAT 追踪 ✔ Continuous Profiling eBPF AutoProfiling ✔ 无符号表 eBPF Profiling ✔ TCP 逐包时序图（Network Profiling） ✔ Packet 回溯（Network Profiling） ✔ AutoTagging SmartEncoding ✔ ✔ K8s 容器资源、自定义 Label 标签 ✔ ✔ K8s 自定义 Annotation/Env 标签 ✔ 公有云资源标签 ✔ ✔ 公有云自定义业务标签 ✔ 私有云/专有云资源标签 ✔ 私有云/专有云自定义业务标签 ✔ 提供 API 支持注入 CMDB 业务标签 ✔ ✔ 提供插件机制支持注入进程业务标签 ✔ ✔ Integration 集成 Prometheus/Telegraf 指标数据 ✔ ✔ 集成 OpenTelemetry/SkyWalking 追踪数据 ✔ ✔ 集成 Pyroscope 持续性能剖析数据 ✔ 提供 SQL、PromQL API ✔ ✔ 提供 OpenTelemetry OTLP Exporter API ✔ ✔ 提供 Grafana Datasource 和 Panel ✔ 使用 Grafana Tempo 展示分布式追踪数据 ✔ 追踪数据输出至 SkyWalking ✔ ✔ Analytics 企业级可观测性分析平台 ✔ 自定义视图管理 ✔ 告警管理 ✔ 报表管理 ✔ Compatibility Agent/Server 运行于 X86/ARM 服务器 ✔ ✔ Agent 运行于专有 K8s 节点 ✔ ✔ Agent 运行于 Serverless K8s Pod 内 ✔ ✔ Agent 运行于 Serverless K8s 节点 ✔ Agent 运行于 Linux 服务器 ✔ ✔ Agent 运行于 Windows 服务器 ✔ Agent 运行于 Android 终端 ✔ Agent 运行于 KVM/HyperV/ESXi/Xen ✔ Agent 运行于 DPDK 数据面环境 ✔ Agent 运行于专属服务器采集镜像流量 ✔ Advanced Feature 云网流量分发（NPB） ✔ 多 Region 统一管理 ✔ 多租户及权限隔离 ✔ 加密传输 ✔ Agent 注册安全确认 ✔ Advanced Service 行业可观测性解决方案 ✔ 企业级售后服务支持 ✔ 产品 DeepFlow Enterprise DeepFlow Cloud DeepFlow Enterprise 解决方案 NPB 混合云全网流量采集与分发 NPMD 混合云网络监控诊断 5G核心网网络功能服务监控容器化微服务可观测性方案 DeepFlow Enterprise 案例学习客户案例阿里混合云网络监控实践腾讯金融行业云监控实践关于关于我们创始人投资者云杉历程联系我们

产品 DeepFlow Enterprise DeepFlow Cloud DeepFlow Enterprise 解决方案 NPB 混合云全网流量采集与分发 NPMD 混合云网络监控诊断 5G核心网网络功能服务监控容器化微服务可观测性方案 DeepFlow Enterprise 案例学习客户案例阿里混合云网络监控实践腾讯金融行业云监控实践关于关于我们创始人投资者云杉历程联系我们

https://cloud.deepflow.yunshan.net 温馨提示请切换到PC端，登录DeepFlow 复制网址复制成功！

产品

eBPF

文档

博客

DeepFlow 简介 | 云原生-可观测性-零侵扰采集-全栈可观测-分布式追踪-eBPF-Wasm-DeepFlow可观测性平台

***

简体中文English 产品 eBPF 文档博客 Star

***

立即体验企业版体验社区版体验简体中文English 关于 DeepFlow DeepFlow 简介什么是 DeepFlow核心特性解决两大痛点使用 eBPF 技术使命和愿景DeepFlow 架构DeepFlow 关键特性DeepFlow 路标DeepFlow 产品DeepFlow 用户文章安装社区版简介All-in-One 快速部署监控单个 K8s 集群监控多个 K8s 集群监控传统服务器监控云服务器监控托管 K8s 集群监控 Serverless PodDeepFlow 升级安装企业版联系我们最佳实践 Agent 高级配置Server 高级配置特殊环境 Agent 部署降低存储压力生产环境部署建议企业版生产部署联系我们核心特性服务全景图 AutoMetrics应用性能指标应用调用日志网络性能指标网络流日志应用协议列表指标和算子的计算逻辑分布式追踪 AutoTracingSpring Boot DemoIstio Bookinfo Demo 持续性能剖析 AutoProfiling AutoTagging 消除数据孤岛SmartEncoding基础资源标签自定义资源标签可选的进程信息标签额外的云资源标签CMDB 中的业务标签企业版使用帮助租户页面数据查询搜索服务搜索框路径搜索框日志搜索框指标搜索框搜索快照左侧快速过滤视图概述视图列表视图详情添加子视图模板变量子视图概述流量拓扑调用链追踪折线图柱状图饼状图分布图表格趋势分析图指标指标查看指标摘要事件概述资源变更文件读写告警全景图概述业务定义服务列表服务拓扑应用概述指标统计路径统计路径拓扑调用日志调用链追踪持续剖析右滑框网络概述服务统计网络路径网络拓扑流日志NAT 追踪资源盘点PCAP 策略PCAP下载基础设施概述主机容器告警告警策略告警事件推送端点资源概述摘要资源池计算资源网络资源网络服务存储服务容器资源进程资源其他资源报表报表管理员页面联系我们开发与集成数据处理 Wasm plugin 数据输入导入 Metrics AutoTagging集成 Prometheus 数据集成 Telegraf 数据导入 Tracing 全栈分布式追踪AutoTagging调用 APM 的 Trace API导入 OpenTelemetry 数据导入 SkyWalking 数据导入 Profile 导入 Profile 数据数据输出查询 API SQL APIPromQL APITrace Completion API 导出输出 OpenTelemetry ExporterPrometheus Remote Write 企业版开发联系我们故障处理 FAQGrafana 查询慢Agent 常见故障Server 性能调优企业版维护联系我们发行注记 DeepFlow 版本规则版本发布时间线v6.5 CE Release Notesv6.5 EE Release Notesv6.4 CE Release Notesv6.4 EE Release Notesv6.3 CE Release Notesv6.3 EE Release Notesv6.2 CE Release Notesv6.2 EE Release Notesv6.1 CE Release Notesv6.1 EE Release Notes 关于 DeepFlow DeepFlow 简介 # 1. 什么是 DeepFlow DeepFlow 是云杉网络 (opens new window)开发的一款可观测性产品，旨在为复杂的云基础设施及云原生应用提供深度可观测性。DeepFlow 基于 eBPF 实现了应用性能指标、分布式追踪、持续性能剖析等观测信号的零侵扰（Zero Code）采集，并结合智能标签（SmartEncoding）技术实现了所有观测信号的全栈（Full Stack）关联和高效存取。使用 DeepFlow，可以让云原生应用自动具有深度可观测性，从而消除开发者不断插桩的沉重负担，并为 DevOps/SRE 团队提供从代码到基础设施的监控及诊断能力。为了鼓励全球可观测性领域的开发者和研究者能做出更多的创新和贡献，DeepFlow 核心模块已使用 Apache 2.0 License 开源 (opens new window)，并在网络通信领域国际顶级会议 ACM SIGCOMM 2023 上正式发表了学术论文 (opens new window)《Network-Centric Distributed Tracing with DeepFlow: Troubleshooting Your Microservices in Zero Code》。 # 2. 核心特性任意 Service 的全景图：基于领先的 AutoMetrics 机制，利用 eBPF 技术零侵扰绘制生产环境的服务全景图，包括任意语言开发的服务、未知代码的第三方服务、所有的云原生基础设施服务。内置大量应用协议解析能力，并提供 Wasm 插件机制扩展解析任意私有协议。零侵扰计算每一次调用在应用程序和基础设施中的全栈黄金指标，快速定界性能瓶颈。任意 Request 的分布式追踪：基于领先的 AutoTracing 机制，利用 eBPF 和 Wasm 技术零侵扰实现分布式追踪，支持任意语言的应用程序，并完整覆盖网关、服务网格、数据库、消息队列、DNS、网卡等各类基础设施，不留下任何追踪盲点。全栈，自动采集每个 Span 关联的网络性能指标和文件读写事件。从此，分布式追踪进入零插桩的新时代。任意 Function 的持续性能剖析：基于领先的 AutoProfiling 机制，利用 eBPF 技术以低于 1% 的开销零侵扰采集生产环境进程的性能剖析数据，绘制函数粒度的 OnCPU、OffCPU 火焰图，快速定位应用函数、库函数、内核函数的全栈性能瓶颈，并自动关联至分布式追踪数据。即使在 2.6+ 内核版本下，仍然可提供网络性能剖析能力，洞察代码性能瓶颈。无缝集成流行的可观测性技术栈：可作为 Prometheus、OpenTelemetry、SkyWalking、Pyroscope 的存储后端，亦可提供 SQL、PromQL、OTLP 等数据接口作为流行技术栈的数据源。基于领先的 AutoTagging 机制，自动为所有观测信号注入统一标签，包括云资源、K8s 容器资源、K8s Label/Annotation、CMDB 中的业务属性等，消除数据孤岛。存储性能 10x ClickHouse：基于领先的 SmartEncoding 机制，向所有观测信号注入标准化的、预编码的元标签，相比 ClickHouse 的 String 或 LowCard 方案均可将存储开销降低 10x。自定义标签与观测数据分离存储，从此你可安心注入近乎无限维度和基数的标签，且可获得像 BigTable 一样的轻松查询体验。 # 3. 解决两大痛点传统方案中，APM 希望通过代码插桩（Instrumentation）的方式来实现应用程序的可观测性。利用插桩，应用程序可以暴露非常丰富的观测信号，包括指标、追踪、日志、函数性能剖析等。然而插桩的行为实际上改变了原始程序的内部状态，从逻辑上并不符合可观测性「从外部数据确定内部状态」的要求。在金融、电信等重要行业的核心业务系统中，APM Agent 落地非常困难。进入到云原生时代，这个传统方法也面临着更加严峻的挑战。总的来讲，APM 的问题主要体现在两个方面：Agent 的侵扰性导致难以落地，观测盲点导致无法定界。第一，探针侵扰性导致难以落地。插桩的过程需要对应用程序的源代码进行修改，重新发布上线。即使例如 Java Agent 这类字节码增强技术，也需要修改应用程序的启动参数并重新发版。然而，对应用代码的改造还只是第一道关卡，通常落地过程中还会碰到很多其他方面的问题：代码冲突：当你为了分布式追踪、性能剖析、日志甚至服务网格等目的注入了多个 Java Agent 时，是否经常遇到不同 Agent 之间产生的运行时冲突？当你引入一个可观测性的 SDK 时，是否遇到过依赖库版本冲突导致无法编译成功？业务团队数量越多时，这类兼容性问题的爆发会越为明显。维护困难：如果你负责维护公司的 Java Agent 或 SDK，你的更新频率能有多高？就在此时，你们公司的生产环境中有多少个版本的探针程序？让他们更新到同一个版本需要花多长时间？你需要同时维护多少种语言的探针程序？当企业的微服务框架、RPC 框架无法统一时，这类维护问题还将会更加严重。边界模糊：所有的插桩代码严丝合缝的进入了业务代码的运行逻辑中，不分你我、不受控制。这导致当出现性能衰减或运行错误时，插桩代码往往难辞其咎。即使探针已经经过了长时间的实战打磨，遇到问题时也免不了要求排除嫌疑。实际上，这也是为什么侵扰性的插桩方案少见于成功的商业产品，更多见于活跃的开源社区。OpenTelemetry、SkyWalking 等社区的活跃正是佐证。而在部门分工明确的大型企业中，克服协作上的困难是一个技术方案能够成功落地永远也绕不开的坎。特别是在金融、电信、电力等承载国计民生的关键行业中，部门之间的职责区分和利益冲突往往会使得落地插桩式的解决方案成为「不可能」。即使是在开放协作的互联网企业中，也少不了开发人员对插桩的不情愿、运维人员在出现性能故障时的背锅等问题。在经历了长久的努力之后人们已经发现，侵入性的解决方案仅仅适合于每个业务开发团队自己主动引入、自己维护各类 Agent 和 SDK 的版本、自己对性能隐患和运行故障的风险负责。第二，观测盲点导致无法定界。即使 APM 已经在企业内落地，我们还是会发现排障边界依然难以界定，特别是在云原生基础设施中。这是因为开发和运维往往使用不同的语言在对话，例如当调用时延过高时开发会怀疑网络慢、网关慢、数据库慢、服务端慢，但由于全栈可观测性的缺乏，网络、网关、数据库给出的应答通常是网卡没丢包、进程 CPU 不高、DB 没有慢日志、服务端时延很低等一大堆毫无关联的指标，仍然解决不了问题。定界是整个故障处理流程中最关键的一环，它的效率至关重要。如果你是一个业务开发工程师，除了业务本身以外，还应该关心系统调用和网络传输过程；如果你是一个 Serverless 租户，你可能还需要关注服务网格边车及其网络传输；如果你直接使用虚拟机或自建 K8s 集群，那么容器网络是需要重点关注的问题点，特别还需注意 K8s 中的 CoreDNS、Ingress Gateway 等基础服务；如果你是私有云的计算服务管理员，应该关心 KVM 宿主机上的网络性能；如果你是私有云的网关、存储、安全团队，也需要关注服务节点上的系统调用和网络传输性能。实际上更为重要的是，用于故障定界的数据应该使用类似的语言进行陈述：一次应用调用在整个全栈路径中，每一跳到底消耗了多长时间。我们发现，开发者通过插桩提供的观测数据，可能只占了整个全栈路径的 1/4。在云原生时代，单纯依靠 APM 来解决故障定界，本身就是妄念。 # 4. 使用 eBPF 技术假设你对 eBPF 有了基础的了解，它是一项安全、高效的通过在沙箱中运行程序以实现内核功能扩展的技术，是对传统的修改内核源代码和编写内核模块方式的革命性创新。eBPF 程序是事件驱动的，当内核或用户程序经过一个 eBPF Hook 时，对应 Hook 点上加载的 eBPF 程序就会被执行。Linux 内核中预定义了一系列常用的 Hook 点，你也可以利用 kprobe 和 uprobe 技术动态增加内核和应用程序的自定义 Hook 点。得益于 Just-in-Time (JIT) 技术，eBPF 代码的运行效率可媲美内核原生代码和内核模块。得益于 Verification 机制，eBPF 代码将会安全的运行，不会导致内核崩溃或进入死循环。 https://ebpf.io/what-is-ebpf/#hook-overview 沙箱机制是 eBPF 有别于 APM 插桩机制的核心所在，「沙箱」在 eBPF 代码和应用程序的代码之间划上了一道清晰的界限，使得我们能在不对应用程序做任何修改的前提下，通过获取外部数据就能确定其内部状态。我们来分析下为何 eBPF 是解决 APM 代码插桩缺陷的绝佳解决方案：第一，零侵扰解决落地难的问题。由于 eBPF 程序无需修改应用程序代码，因此不会有类似 Java Agent 的运行时冲突和 SDK 的编译时冲突，解决了代码冲突问题；由于运行 eBPF 程序无需改变和重启应用进程，不需要应用程序重新发版，不会有 Java Agent 和 SDK 的版本维护痛苦，解决了维护困难问题；由于 eBPF 在 JIT 技术和 Verification 机制的保障下高效安全的运行，因此不用担心会引发应用进程预期之外的性能衰减或运行时错误，解决了边界模糊问题。另外从管理层面，由于只需要在每个主机上运行一个独立的 eBPF Agent 进程，使得我们可以对它的 CPU 等资源消耗进行单独的、精确的控制。第二，全栈能力解决故障定界难的问题。eBPF 的能力覆盖了从内核到用户程序的每一个层面，因此我们得以跟踪一个请求从应用程序出发，经过系统调用、网络传输、网关服务、安全服务，到达数据库服务或对端微服务的全栈路径，提供充足的中立观测数据，快速完成故障的定界。关于这方面更详细的分析，请参考我们的文章《eBPF 是实现可观测性的关键技术》 (opens new window)。需要强调的是，这并不意味着 DeepFlow 只使用 eBPF 技术。相反，DeepFlow 支持无缝集成流行的可观测性技术栈，例如它可作为 Prometheus、OpenTelemetry、SkyWalking、Pyroscope 等观测信号的的存储后端。 # 5. 使命和愿景使命：让观测更简单。愿景：成为云原生应用实现可观测性的首选。产品 DeepFlow Enterprise DeepFlow Cloud DeepFlow Enterprise 解决方案 NPB 混合云全网流量采集与分发 NPMD 混合云网络监控诊断 5G核心网网络功能服务监控容器化微服务可观测性方案 DeepFlow Enterprise 案例学习客户案例阿里混合云网络监控实践腾讯金融行业云监控实践关于关于我们创始人投资者云杉历程联系我们

https://cloud.deepflow.yunshan.net 温馨提示请切换到PC端，登录DeepFlow 复制网址复制成功！

产品

eBPF

文档

博客

GitHub - deepflowio/deepflow: :honeybee: eBPF-Powered Observability & Zero-Code Distributed Tracing :sparkles:

Toggle navigation

Product

Actions

Automate any workflow

Packages

Host and manage packages

Security

Find and fix vulnerabilities

Codespaces

Instant dev environments

Copilot

Write better code with AI

Code review

Manage code changes

Issues

Plan and track work

Discussions

Collaborate outside of code

Explore

All features

Documentation

GitHub Skills

Blog

Solutions

For

Enterprise

Teams

Startups

Education

By Solution

CI/CD & Automation

DevOps

DevSecOps

Resources

Learning Pathways

White papers, Ebooks, Webinars

Customer Stories

Partners

Open Source

GitHub Sponsors

Fund open source developers

The ReadME Project

GitHub community articles

Repositories

Topics

Trending

Collections

Pricing

Search or jump to...

Search code, repositories, users, issues, pull requests...

Clear

Search syntax tips

Provide feedback

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

Cancel

Submit feedback

Saved searches

Use saved searches to filter your results more quickly

Name

Query

To see all available qualifiers, see our documentation.

Cancel

Create saved search

You signed in with another tab or window. Reload to refresh your session.

You signed out in another tab or window. Reload to refresh your session.

You switched accounts on another tab or window. Reload to refresh your session.

Dismiss alert

deepflowio

deepflow

Public

Notifications

Fork

239

Star

2.2k

eBPF-Powered Observability & Zero-Code Distributed Tracing ✨

deepflow.io

License

Apache-2.0 license

2.2k

stars

239

forks

Branches

DeepFlow 基于 eBPF 的高度自动化可观测性实践 - 知乎

DeepFlow 基于 eBPF 的高度自动化可观测性实践 - 知乎切换模式写文章登录/注册DeepFlow 基于 eBPF 的高度自动化可观测性实践云杉网络已认证账号本文为 DeepFlow 在首届中国 eBPF 大会上的在线演讲实录。大家好！我是来自云杉网络的向阳，负责公司的云原生可观测性产品 DeepFlow。今天很高兴能给大家分享我们基于 eBPF 的一些创新实践，我们的产品已经有六年历史，今年七月份刚开源，希望能为云原生应用开发者实现可观测性带来高度自动化的全新体验。01｜历史和现状最近可观测性是一个很火的名词，这里我也想稍微介绍一下它的历史。追溯历史我们会发现，实际上可观测性是作为保障复杂系统可控的必要条件。61 年前，美国提出载人登月的豪言壮语，但届时如何将高度复杂的载人飞船平稳地送到月球还只是人类的一个梦想。8 年之后，受益于 Rudolf Kalman 教授开创的可观测性理论，人类终于完成了登月壮举。Kalman 教授指出，一切系统具有可观测性当且仅当：针对所有的状态向量及控制向量，都可以在有限时间内，只根据输出信号来识别当前的状态。注意这里面的关键：外部输出、内部状态、有限时间。可观测性的历史时间回到 2022 年，现在的云原生应用正是一个复杂度急剧增长的 IT 系统。随着微服务的拆分，单个服务变得越来越简单，服务发布越来越快速，业务中的通用逻辑逐渐卸载至服务网格等基础设施，开发语言和框架越来越自由。这些趋势使得一方面服务的数据急剧增长，但更棘手的问题是连接服务的基础设施路径变得越来越长，路径数量越来越多。开发者们发现，用于采集指标、追踪、日志三大支柱信号的已有方案几乎都聚焦在业务代码和框架代码层面，而对于 N^2 复杂度的进程、Sidecar、节点、宿主机、网关、数据库、消息队列就像黑盒一样，虽然能暴露一些有限的指标和日志，但是和应用是割裂的，应用开发者越来越难以观测 IT 系统的运行状况，其中面临的挑战也正是可观测性理论所指出的：1）微服务的动态性对实时性提出的高要求；2）路径的复杂性对多维度提出的高要求；3）服务实现的复杂性对零侵扰的提出的高要求。云原生应用是一个复杂系统DeepFlow 就是希望来解决云原生应用可观测性问题的，希望能让开发者轻松实现全栈可观测性。下图左上角是一个非常“简单”的复杂云原生业务系统，它是 OpenTelemetry 项目的官方 Demo，是一个用数十种语言实现的高速迭代的电商应用。DeepFlow 使用 OpenTelemetry、Prometheus 等标准化的采集方式，实现应用代码层面的可观测性，同时使用 eBPF 技术，创新的实现了云原生环境中高度自动化的全栈可观测性，得益于 eBPF 的零侵扰特性，不需要开发人员插码、重启进程、修改配置。今天我的分享主要聚焦在 eBPF 的部分，主要介绍 DeepFlow 三个方面的能力：从 cBPF 到 eBPF 的 AutoMetrics 能力，实现面向微服务的动态应用拓扑；从 InProcess 到 Distributed 的 AutoTracing 能力，实现面向用户请求的零侵扰分布式追踪；从 kprobe 到 uprobe 的 AutoLogging 能力，实现面向事件的细粒度回溯日志。02｜AutoMetrics首先我们来看一下 DeepFlow 是如何使用 eBPF 的。下面这张图描述了云原生应用的运行环境，应用进程运行在 Pod 内，可能伴随着例如 Envoy 之类的 Service Mesh Sidecar，通过 iptables、ipvs 等组件接入到虚拟机 Overlay 网络中，继续通过 OvS、Linux Bridge 等组件接入到宿主机 Underlay 网络中，还可能会由一系列四七层网关为其服务。DeepFlow 同时用到了 cBPF 和 eBPF 的能力，使得能覆盖逐跳路径实现全栈可观测性。第一步是采集，我们会从 cBPF 采集网卡流量、eBPF kprobe/tracepoint 采集 Syscall 数据、eBPF uprobe/USDT 采集 Function 数据。拿到这些数据后，第二步是聚合，从 Raw Data 中聚合得到网络流和应用会话，以降低数据量。第三步继续从 Flow 和 Session 聚合生成全栈性能指标。第四步会从网络流和应用会话中提取结构化日志，包括 FlowLog 和 RequestLog，其中后者可认为就是我们常说的 Span。最后第五步，利用一系列算法将 Span 关联生成分布式追踪，这一步也是 DeepFlow 中一项颠覆性的创新。DeepFlow 如何使用 eBPF那么下面我来介绍 DeepFlow 的第一部分能力：从 cBPF 到 eBPF 的 AutoMetrics 能力，实现面向微服务的动态应用拓扑。也就是上图中的第三步。我们来看一下效果，AutoMetrics 能力能做什么呢？我们用户大量反馈的第一个价值是自动绘制微服务动态应用拓扑，知晓任意微服务的上下游访问关系。云原生环境下业务混部共享一个服务器、容器 SNAT 等是普遍现象，以往我们需要靠业务插码解决的事情，现在通过 DeepFlow 可以很快速完成。比如我们一个互联网用户，使用 DeepFlow 从数万个 Pod 中快速定位了对它的 RDS 造成最大访问量的 Pod、服务乃至开发团队。就算在应用代码中插码，有些问题也难以回答，比如我们的金融用户信用卡核心业务上云受阻，使用 DeepFlow 快速发现了两个服务之间 API 网关是性能瓶颈，而这个“透明”的服务通常是被开发者所忽略的。我在访问谁、谁在访问我除了拓扑本身之外，DeepFlow 对拓扑中每一条路径的全栈观测能力是另一个亮点。下图左下角是两个 Pod 之间最普通的访问路径，这里面的进程、Pod、Node、KVM 宿主机都可能引发应用性能问题。DeepFlow 由于全栈覆盖了服务之间的全路径，能够提供沿途每一跳的丰富性能指标。例如应用性能的请求/时延/异常，即我们常说的 RED 三大黄金指标；系统性能的新建/活跃/建连异常；网络性能的建连时延/系统时延/数据时延/吞吐/零窗/重传/载荷长度等。我们支持对主流的应用协议进行识别，包括 HTTP/HTTPS、Dubbo/gRPC、MySQL/PostgreSQL/Redis、Kafka/MQTT、DNS 等。使用这个能力，DeepFlow 的用户能快速定位应用请求在哪里出问题了。例如我们一个互联网用户，快速定位了两个服务之间 K8s 网络性能瓶颈造成的应用时延；一个金融用户，快速定位了 ARP 异常导致的 Pod 概率性长时间无法 Ready；一个系统软件用户，快速定位了客户端没有及时收包导致的 gRPC 超时。得益于 eBPF 的零侵扰特性，这些定位过程不需要对线上应用做任何改变。DeepFlow 中的全栈访问路径刚才还只是最简单的场景，而在专有云网络中，访问路径会更加复杂，DeepFlow 的能力也更加丰富。DeepFlow 与阿里专有云、腾讯 TCE、华为 HCS 已经合作超过三年，进行了深度的适配。云网络中最复杂的就是 NFV 区域，可能存在十余种云网关、四五种种隧道封装协议、十余种通信端点，组合起来形成上百种穿越 NFV 区的路径。以往大家在排查应用问题时只能逐个抓包确认，过程非常痛苦，技能养成靠着老师傅传帮带。基于网关区 cBPF 获取到的流量，DeepFlow 将应用访问穿越网关区的整个路径智能推导出来，无论中间经历过多少次 SNAT、DNAT、FULLNAT，都能关联至上一页我讲到的云原生应用访问路径中。这里的路径追踪方法，等会在第二部分的分布式追踪中会做一个介绍。下图右下角是我们基于 NAT 追踪能力绘制的流量拓扑和链路拓扑。利用这个能力我们也有很多用户案例，我们一个金融用户，使用 DeepFlow 解决了困扰云厂商工程师多日的路由环路，它造成了某个服务上云下云时延周期性飙升；另一个金融用户快速定位了一个 NFV 网关实例对一组服务流量丢包，导致的客户端频繁重试。追踪专有云中 NFV 网关区域的访问路径03｜AutoTracing刚才介绍的是指标方面的能力，下面来介绍一下从 InProcess 到 Distributed 的 AutoTracing 能力，实现面向用户请求的零侵扰分布式追踪。这是 DeepFlow 中一项颠覆性的创新。我们以一个 Demo 为例，左下角是 Istio 官方的 Bookinfo Demo，包含五种语言实现的微服务和 Sidecar，服务存在多个版本体现了迭代速度之快，所有服务使用 Service Mesh 连接。以往为了实现这样一个简单应用的分布式追踪，我们不得不在各种语言和框架中进行打桩和插码，利用 OpenTelemetry、SkyWalking 技术绘制分布式追踪火焰图。而现在大家看到的这张火焰图是 DeepFlow 完全基于 eBPF 的 AutoTracing 能力得到的，覆盖了一次用户请求的整个生命周期，以及每一个微服务调用从客户端进程到服务端进程的全路径，而所有这些结果不依赖对应用做任何插码、重启、配置。相信云原生开发者看到这个结果时是非常兴奋的。对 Istio Bookinfo Demo 的零侵扰分布式追踪基于这个火焰图，我们来详细的展示一下 DeepFlow 的 AutoTracing 能力。首先 AutoTracing 是零插码的，它不需要修改应用代码，不需要向 HTTP Header 中注入 TraceID、SpanID。这张火焰图共由 38 个 Span 组成，包括 24 个 eBPF Span 和 14 个 cBPF Span，覆盖了一次应用请求的全链路。火焰图中覆盖了 Java、Python、Ruby、Node.js、C、C++ 六种语言实现的微服务和网关，全部都能自动呈现在火焰图中。对于我们一直提到的全栈能力，这里也放大两个区域看看。我们看到一个调用从客户端进程，经过 Pod 网卡、Node 网卡，甚至是 KVM、NFVGW 等到达服务端进程的全过程，无论中间路径如何复杂，添加过几层隧道、做过几次 NAT，都能清晰的展现在火焰图中，快速判断服务之间的性能问题是由哪个环节导致，并且结合之前介绍的 DeepFlow 指标体系，火焰图可以快速关联到应用、系统、网络各个层面的指标。再来看看另一个区域，我们看到一个调用从进入 Pod 被 Envoy 劫持，到被微服务接收，到微服务继续请求下游并被 Envoy 劫持，在一个 Pod 内的全栈路径也能非常清晰的体现出来。除此之外，我们也能发现以往应用代码插桩难以覆盖的一些基础服务，例如微服务对 DNS 解析、磁盘 IO 等过程在这个火焰图中也体现了出来。基于这样的全栈分布式追踪能力我们也有很多用户案例，例如一个互联网用户快速定位客户端慢而服务端不慢的经典扯皮问题。DeepFlow AutoTracingAutoTracing 是 DeepFlow 中一个开创性的能力，这个能力基于 eBPF，它与大家所熟知的一个进程内部的 Trace 不同，解决的是微服务分布式调用的追踪问题。这里我尝试简单的介绍一下我们的方法。实际上我们只需要解决两个子问题：如何追踪一个服务前后的入出请求；如何追踪两个服务之间的网络路径。对于第一个问题，又分为线程内追踪、跨线程追踪、跨协程追踪。DeepFlow 利用 ThreadID ，以及为每个 Request 生成的 SyscallTraceID 关联一个线程内的入向和出向请求，完美的解决了同线程的追踪问题；跨线程有些复杂，基于为每个会话生成的 SessionID 和包头中提取的 X-Request-ID，我们目前解决了一部分场景，相信未来能搞定越来越多的异步调用；对于 Golang/Erlang 等协程语言同样也非常困难，我们追踪了 CoroutineID 之间的关系，这部分代码也正在合入中，预计在我们的 v6.2.0 版本中和大家见面。那么接下来如何追踪两个服务之间的网络路径呢，简单来讲使用了 TCP Seq 序列号，并结合时间窗口等信息。虽然原理简单，但其中有很多细节的工程问题需要处理，以实现用户函数调用、系统函数调用、网络流量的关联。时间关系没法展开，如果大家感兴趣欢迎到 DeepFlow 社区群中交流。DeepFlow 如何实现分布式追踪04｜AutoLogging最后我们来介绍一下 DeepFlow 中的日志能力，从 kprobe 到 uprobe 的 AutoLogging 能力，实现面向事件的细粒度回溯日志。由于我们已经从 cBPF 和 eBPF 中拿到了所有微服务沿途的全栈数据，通过 Flow 和 Session 聚合，我们能提取出标准化、结构化的回溯日志。例如对应用调用日志我们能提取请求域名、Endpoint、请求 ID、响应码、响应结果，也能提取 HTTP Header 中常见的客户端真实 IP、UserAgent、Referer 等字段。对于已经在应用内插码追踪的场景，也能从 cBPF 和 eBPF 数据中提取出 TraceID、SpanID 等字段以关联应用 Span。协议解析和字段提取的能力我们也正在开发通过 WASM 和 LUA 提供插件式的扩展能力，使得用户可以解析和提取私有协议字段。除了调用日志以外，我们也采集了网络流日志。在企业版中我们还支持以 1/10 的存储代价压缩存储所有 TCP 包头，以及压缩存储全包 PCAP 文件。这方面也有很多我们的用户案例，例如政府用户使用 DeepFlow 流日志替代全包存储，回溯查询的速度和存储时长都实现了数量级的提升；金融用户使用 TCP 包头时序图快速发现了云网关转发 SYN 报文时延大导致的应用性能衰减。DeepFlow AutoLogging下图是 DeepFlow 当前的所有 eBPF hook 点，GitHub 上直接搜索 DeepFlow 即可找到我们的仓库，这里也列出了几条命令帮助大家查看 DeepFlow 目前使用到的主要 uprobe、kprobe、tracepoint hook 点。DeepFlow eBPF Hook 点05｜数据的标准化好了，讲完了指标、追踪、日志，最后来给大家介绍一下 DeepFlow 中的标签注入能力。大家可能也关注到了前面我所讲的内容中，DeepFlow 能以非常丰富的维度展现数据，我们通过 AutoTagging 机制为所有的可观测性信号注入丰富的标签，包括资源池、云资源、网络资源、容器服务、应用等相关的标准标签，和 K8s Label、Annotation、ENV 等开发者自定义的标签。依靠这些标签我们能快速的在不同类型的可观测性信号之间切换，无论是 eBPF 采集到的数据，还是通过 Prometheus、OpenTelemetry 采集到的数据，完全消除不同数据源之间的孤岛。数据的标准化也有助于进一步的消费，DeepFlow 的用户消费这些数据时，不再需要考虑复杂的标准化过程，我相信这也是实现智能化的前提。DeepFlow AutoTagging 及 SmartEncoding大家可能会比较好奇，插入这么多标签是否会造成大量的资源消耗，这里就要介绍 DeepFlow 的 SmartEncoding 机制了，简单来讲通过标签和数据的分离采集、标签的数值编码、以及自定义标签的读时关联，我们能将标签写入的资源消耗降低 10~50 倍。这里有一些数据可以看一下，DeepFlow 默认使用 ClickHouse 存储数据，在 SmartEncoding 的加持下，标注 Tag 的 CPU 和磁盘消耗相比 LowCard 存储或直接存储有一个数量级的优化，而由于自定义 Tag 不会随数据写入，在通常的场景下整体写入资源消耗可降低 50 倍。因此实际上 DeepFlow 实现了 Tag without Limit，可以让开发者尽情的注入丰富的标签，充分挖掘数据的价值。最后，简单介绍一下 DeepFlow 的软件架构。DeepFlow 希望让云原生开发者能够轻松实现全栈可观测性，这个产品我们做了六年，今年七月份正式开源，目前已经是 CNCF Cloud Native Landscape Project 和 eBPF Landscape Project。从下图中可以看到 DeepFlow 社区版的架构非常精炼，主要包括 Agent 和 Server 两个进程，前者是 Rust 实现的，后者是 Golang 实现的。Agent 使用 eBPF 的能力实现 AutoMetrics、AutoTracing、AutoLogging 能力，并基于 WASM 提供可编程性。Server 使用 AutoTagging 和 SmartEncoding，基于 Agent 采集到的元数据，向所有可观测性信号中高性能的注入标准化的标签。除了 eBPF 之外，DeepFlow 还使用 Prometheus、OpenTelemetry、SkyWalking 等开放 Agent 采集数据，并且和 eBPF 的数据进行关联。向上我们提供了易于使用的 SQL API、Grafana Datasource 和 Query Editor，未来也会支持 PromQL 等流行的查询语言。如果大家对 DeepFlow 感兴趣，可以扫码加入我们的开源社区微信群，希望能给你带来全新的可观测性体验。谢谢大家！06｜什么是 DeepFlowDeepFlow[1] 是一款开源的高度自动化的可观测性平台，是为云原生应用开发者建设可观测性能力而量身打造的全栈、全链路、高性能数据引擎。DeepFlow 使用 eBPF、WASM、OpenTelemetry 等新技术，创新的实现了 AutoTracing、AutoMetrics、AutoTagging、SmartEncoding 等核心机制，帮助开发者提升埋点插码的自动化水平，降低可观测性平台的运维复杂度。利用 DeepFlow 的可编程能力和开放接口，开发者可以快速将其融入到自己的可观测性技术栈中。GitHub 地址：https://github.com/deepflowys/deepflow访问 DeepFlow Demo[2]，体验高度自动化的可观测性新时代。参考资料[1] DeepFlow: https://github.com/deepflowys/deepflow[2] DeepFlow Demo: https://deepflow.yunshan.net/docs/zh/install/overview/发布于 2022-11-23 17:42・IP 属地北京Cilium（网络）云监控网络运维赞同 41 条评论分享喜欢收藏申请

一文读懂基于 eBPF 自动化可观测平台 - DeepFlow-阿里云开发者社区

产品解决方案文档与社区权益中心定价云市场合作伙伴支持与服务了解阿里云售前咨询 95187-1 在线服务售后咨询 4008013260 在线服务其他服务我要建议我要投诉更多联系方式备案控制台开发者社区首页探索云世界探索云世界云上快速入门，热门云上应用快速查找了解更多问产品动手实践考认证TIANCHI大赛活动广场活动广场丰富的线上&线下活动，深入探索云世界任务中心做任务，得社区积分和周边高校计划让每位学生受益于普惠算力训练营资深技术专家手把手带教话题畅聊无限，分享你的技术见解开发者评测最真实的开发者用云体验乘风者计划让创作激发创新阿里云MVP遇见技术追梦人直播技术交流，直击现场下载下载海量开发者使用工具、手册，免费下载镜像站极速、全面、稳定、安全的开源镜像技术资料开发手册、白皮书、案例集等实战精华插件为开发者定制的Chrome浏览器插件探索云世界新手上云云上应用构建云上数据管理云上探索人工智能云计算弹性计算无影存储网络倚天云原生容器serverless中间件微服务可观测消息队列数据库关系型数据库NoSQL数据库数据仓库数据管理工具PolarDB开源向量数据库热门Modelscope模型即服务弹性计算云原生数据库物联网云效DevOps龙蜥操作系统平头哥钉钉开放平台大数据大数据计算实时数仓Hologres实时计算FlinkE-MapReduceDataWorksElasticsearch机器学习平台PAI智能搜索推荐人工智能机器学习平台PAI视觉智能开放平台智能语音交互自然语言处理多模态模型pythonsdk通用模型开发与运维云效DevOps钉钉宜搭支持服务镜像站码上公益

开发者社区

开发与运维

文章

正文

一文读懂基于 eBPF 自动化可观测平台 - DeepFlow

2023-07-17

900

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《

阿里云开发者社区用户服务协议》和

《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写

侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介：

Hello folks，我是 Luga，今天我们来聊一下云原生生态核心技术——基于 eBPF 全链路自动化可观测性。当我们真正融入到云原生生态场景中时，我们将会深切地体会到：“全链路可观测性”的价值所在～

架构驿站

DeepFlow: 高度自动化的可观测性平台避免手工插码，消除追踪盲点，简化平台维护。使用 eBPF、OTel、WASM 等技术，让观测更自动。

DeepFlow: 高度自动化的可观测性平台

避免手工插码，消除追踪盲点，简化平台维护。

使用 eBPF、OTel、WASM 等技术，让观测更自动。

开源

企业版

高校版

搜索

帮助中心

使用条款

关于我们

开源

企业版

高校版

私有云

Gitee AI

NEW

我知道了

查看详情

代码拉取完成，页面将自动刷新

捐赠

捐赠前请先登录

取消

前往登录

扫描微信二维码支付

取消

支付完成

支付提示

将跳转至支付宝完成支付

确定

取消

Watch

不关注

关注所有动态

仅关注版本发行动态

关注但不提醒动态

Star

Fork

OPLG / DeepFlow

代码

Issues

Pull Requests

Wiki

统计

流水线

服务

Gitee Pages

JavaDoc

PHPDoc

质量分析

Jenkins for Gitee

腾讯云托管

腾讯云 Serverless

悬镜安全

阿里云 SAE

Codeblitz

我知道了，不再自动展开

加入 Gitee

与超过 1200万开发者一起发现、参与优秀开源项目，私有仓库也完全免费：）

免费加入

已有帐号？

立即登录

main

管理

分支 (279)

标签 (35)

main

feature-modify-data-source

feature-otlp-no-clickhouse

remove-cache-hardcoded-as-u32

feature-profile-flame-update63

querier-m_profile

add-alarm-uid-name

feature_endpoint_main

ydx-fix-custom-rrt

feature-update-profile-storage

container-network

AEC

v6.2

v6.1

feature-add-pod-service

ydx-tcp-reassemble

ydx-add-fastcgi

feature_proemtheus_config_main

feature-fix-tap-side

feature-reget-target-id-when-change

v6.3.4

v6.3.3

v6.3.2

v6.3.1

v6.2.6.6

v6.3.0

v6.2.6.5

v6.2.6.4

v6.1.8.9

v6.2.6.3

v6.2.6.2

v6.2.6.1

v6.1.8.8

v6.2.6

v6.1.8.7

v6.2.5

v6.2.4

v6.2.3

v6.1.8.6

v6.2.2

克隆/下载

HTTPS

SSH

SVN

SVN+SSH

下载ZIP

登录提示

该操作需登录 Gitee 帐号，请先登录后再操作。

立即登录

没有帐号，去注册

提示

下载代码请复制以下命令到终端执行

为确保你提交的代码身份被 Gitee 正确识别，请执行以下命令完成配置

git config --global user.name userName

git config --global user.email userEmail

初次使用 SSH 协议进行代码克隆、推送等操作时，需按下述提示完成 SSH 配置

生成 RSA 密钥

获取 RSA 公钥内容，并配置到 SSH公钥中

在 Gitee 上使用 SVN，请访问使用指南

使用 HTTPS 协议时，命令行会出现如下账号密码验证步骤。基于安全考虑，Gitee 建议配置并使用私人令牌替代登录密码进行克隆、推送等操作

Username for 'https://gitee.com': userName

Password for 'https://userName@gitee.com':

私人令牌

新建文件

新建 Diagram 文件

新建子模块

上传文件

分支 279

标签 35

贡献代码

同步代码

创建 Pull Request

了解更多

对比差异

通过 Pull Request 同步

同步更新到分支

通过 Pull Request 同步

将会在向当前分支创建一个 Pull Request，合入后将完成同步

kangxiang

[Controller] del verification between pod ...

f726362

8711 次提交

提交

取消

提示:

由于 Git 不支持空文件夾，创建文件夹后会生成空的 .keep 文件

.github

保存

取消

agent

保存

取消

cli

保存

取消

docs

保存

取消

manifests/charts

保存

取消

message

保存

取消

server

保存

取消

.cirun.yml

保存

取消

.gitignore

保存

取消

.gitmodules

保存

取消

CODE_OF_CONDUCT.md

保存

取消

LICENSE

保存

取消

README-CN.md

保存

取消

README.md

保存

取消

commit-template

保存

取消

README

Apache-2.0

DeepFlow is an automated observability platform for cloud-native developers.

简体中文 | English

什么是 DeepFlow

DeepFlow 是一款面向云原生开发者的高度自动化的可观测性平台。使用 eBPF、WASM、OpenTelemetry 等新技术，DeepFlow 创新的实现了 AutoTracing、AutoMetrics、AutoTagging、SmartEncoding 等核心机制，极大的避免了埋点插码，显著的降低了后端数仓的资源开销。基于 DeepFlow 的可编程性和开放接口，开发者可以快速将其融入到自己的可观测性技术栈中。

六大主要特性

全栈：DeepFlow 使用 eBPF 和 cBPF 技术实现的 AutoMetrics 机制，可以自动采集任何应用的 RED（Request、Error、Delay）性能指标，精细至每一次应用调用，覆盖从应用到基础设施的所有软件技术栈。在云原生环境中，DeepFlow 的 AutoTagging 机制自动发现服务、实例、API 的属性信息，自动为每个观测数据注入丰富的标签，从而消除数据孤岛，并释放数据的下钻能力。

全链路：DeepFlow 使用 eBPF 技术创新的实现了 AutoTracing 机制，在云原生环境中自动追踪任意微服务、基础设施服务的分布式调用链。在此基础上，通过集成并自动关联来自 OpenTelemetry 的数据，DeepFlow 实现了完整的全栈、全链路分布式追踪，消除了所有盲点。

高性能：DeepFlow 创新的 SmartEncoding 标签注入机制，能够将数据存储性能提升 10 倍，从此告别高基数和采样的焦虑。DeepFlow 使用 Rust 实现 Agent，拥有极致处理性能的同时保证内存安全。DeepFlow 使用 Golang 实现 Server，重写了 Golang 的 map、pool 基础库，数据查询和内存 GC 均有近 10 倍的性能提升。

可编程：DeepFlow 目前支持了对 HTTP(S)、Dubbo、MySQL、PostgreSQL、Redis、Kafka、MQTT、DNS 协议的解析，并将保持迭代增加更多的应用协议支持。除此之外，DeepFlow 基于 WASM 技术提供了可编程接口，让开发者可以快速具备对私有协议的解析能力，并可用于构建特定场景的业务分析能力，例如 5GC 信令分析、金融交易分析、车机通信分析等。

开放接口：DeepFlow 拥抱开源社区，支持接收广泛的可观测数据源，并利用 AutoTagging 和 SmartEncoding 提供高性能、统一的标签注入能力。DeepFlow 支持插件式的数据库接口，开发者可自由增加和替换最合适的数据库。DeepFlow 为所有观测数据提供统一的标准 SQL 查询能力，便于使用者快速集成到自己的可观测性平台中。

易于维护：DeepFlow 的内核仅由 Agent、Server 两个组件构成，将复杂度隐藏在进程内部，将维护难度降低至极致。DeepFlow Server 集群可对多个 Kubernetes 集群、传统服务器集群、云服务器集群进行统一监控，且无需依赖任何外部组件即可实现水平扩展与负载均衡。

文档

详细信息请访问文档站点。

快速上手

DeepFlow 共有三种版本：

DeepFlow Community：DeepFlow 社区版，面向开发人员

DeepFlow Enterprise：DeepFlow 企业版，面向组织、解决团队协作的问题

DeepFlow Cloud：DeepFlow SaaS 服务，目前处于测试阶段

DeepFlow 社区版由企业版的核心组件构成。通过开源，我们希望让观测更自动，让全世界的开发者更自由。

部署 DeepFlow Community

请参考文档部署 DeepFlow Community。

同时我们也搭建了一个完整的 DeepFlow Community Demo，欢迎体验。登录账号 / 密码：deepflow / deepflow。

体验 DeepFlow Cloud

DeepFlow Cloud 是 DeepFlow 的全托管 SaaS 服务，目前处于测试阶段，仅支持中文。

体验 DeepFlow Enterprise

DeepFlow Enterprise 支持对混合云的全栈、全链路监控，覆盖容器、云服务器、宿主机、NFV网关，目前仅支持中文，欢迎联系我们进行体验。

从源码编译 DeepFlow

编译 deepflow-agent

软件架构

DeepFlow Community 版本主要由 Agent 和 Server 两个进程组成。每个 K8s 容器节点、传统服务器或云服务器中运行一个 Agent ，负责该服务器上所有应用进程的 AutoMetrics 和 AutoTracing 数据采集。Server 运行在一个 K8s 集群中，提供 Agent 管理、标签注入、数据写入、数据查询服务。

里程碑

这里有我们未来的 Feature 规划。欢迎 Issue 和 Pull Request。

联系我们

Discord：点击此链接加入 Discord 频道.

Twitter：DeepFlow

微信群：

致谢

感谢 eBPF，革命性的 Linux 内核技术

感谢 OpenTelemetry，提供了采集应用可观测性数据的标准 API

Landscapes

DeepFlow 已加入 CNCF CLOUD NATIVE Landscape

DeepFlow 已加入 eBPF Project Landscape

Apache License

Version 2.0, January 2004

http://www.apache.org/licenses/

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

1. Definitions.

"License" shall mean the terms and conditions for use, reproduction,

and distribution as defined by Sections 1 through 9 of this document.

"Licensor" shall mean the copyright owner or entity authorized by

the copyright owner that is granting the License.

"Legal Entity" shall mean the union of the acting entity and all

other entities that control, are controlled by, or are under common

control with that entity. For the purposes of this definition,

"control" means (i) the power, direct or indirect, to cause the

direction or management of such entity, whether by contract or

otherwise, or (ii) ownership of fifty percent (50%) or more of the

outstanding shares, or (iii) beneficial ownership of such entity.

"You" (or "Your") shall mean an individual or Legal Entity

exercising permissions granted by this License.

"Source" form shall mean the preferred form for making modifications,

including but not limited to software source code, documentation

source, and configuration files.

"Object" form shall mean any form resulting from mechanical

transformation or translation of a Source form, including but

not limited to compiled object code, generated documentation,

and conversions to other media types.

"Work" shall mean the work of authorship, whether in Source or

Object form, made available under the License, as indicated by a

(an example is provided in the Appendix below).

"Derivative Works" shall mean any work, whether in Source or Object

form, that is based on (or derived from) the Work and for which the

editorial revisions, annotations, elaborations, or other modifications

represent, as a whole, an original work of authorship. For the purposes

of this License, Derivative Works shall not include works that remain

separable from, or merely link (or bind by name) to the interfaces of,

the Work and Derivative Works thereof.

"Contribution" shall mean any work of authorship, including

the original version of the Work and any modifications or additions

to that Work or Derivative Works thereof, that is intentionally

submitted to Licensor for inclusion in the Work by the copyright owner

or by an individual or Legal Entity authorized to submit on behalf of

the copyright owner. For the purposes of this definition, "submitted"

means any form of electronic, verbal, or written communication sent

to the Licensor or its representatives, including but not limited to

communication on electronic mailing lists, source code control systems,

and issue tracking systems that are managed by, or on behalf of, the

Licensor for the purpose of discussing and improving the Work, but

excluding communication that is conspicuously marked or otherwise

designated in writing by the copyright owner as "Not a Contribution."

"Contributor" shall mean Licensor and any individual or Legal Entity

on behalf of whom a Contribution has been received by Licensor and

subsequently incorporated within the Work.

2. Grant of Copyright License. Subject to the terms and conditions of

this License, each Contributor hereby grants to You a perpetual,

worldwide, non-exclusive, no-charge, royalty-free, irrevocable

publicly display, publicly perform, sublicense, and distribute the

Work and such Derivative Works in Source or Object form.

3. Grant of Patent License. Subject to the terms and conditions of

this License, each Contributor hereby grants to You a perpetual,

worldwide, non-exclusive, no-charge, royalty-free, irrevocable

(except as stated in this section) patent license to make, have made,

use, offer to sell, sell, import, and otherwise transfer the Work,

where such license applies only to those patent claims licensable

by such Contributor that are necessarily infringed by their

Contribution(s) alone or by combination of their Contribution(s)

with the Work to which such Contribution(s) was submitted. If You

institute patent litigation against any entity (including a

cross-claim or counterclaim in a lawsuit) alleging that the Work

or a Contribution incorporated within the Work constitutes direct

or contributory patent infringement, then any patent licenses

granted to You under this License for that Work shall terminate

as of the date such litigation is filed.

4. Redistribution. You may reproduce and distribute copies of the

Work or Derivative Works thereof in any medium, with or without

modifications, and in Source or Object form, provided that You

meet the following conditions:

(a) You must give any other recipients of the Work or

Derivative Works a copy of this License; and

(b) You must cause any modified files to carry prominent notices

stating that You changed the files; and

that You distribute, all copyright, patent, trademark, and

attribution notices from the Source form of the Work,

excluding those notices that do not pertain to any part of

the Derivative Works; and

(d) If the Work includes a "NOTICE" text file as part of its

distribution, then any Derivative Works that You distribute must

include a readable copy of the attribution notices contained

within such NOTICE file, excluding those notices that do not

pertain to any part of the Derivative Works, in at least one

of the following places: within a NOTICE text file distributed

as part of the Derivative Works; within the Source form or

documentation, if provided along with the Derivative Works; or,

within a display generated by the Derivative Works, if and

wherever such third-party notices normally appear. The contents

of the NOTICE file are for informational purposes only and

do not modify the License. You may add Your own attribution

notices within Derivative Works that You distribute, alongside

or as an addendum to the NOTICE text from the Work, provided

that such additional attribution notices cannot be construed

as modifying the License.

You may add Your own copyright statement to Your modifications and

may provide additional or different license terms and conditions

for use, reproduction, or distribution of Your modifications, or

for any such Derivative Works as a whole, provided Your use,

reproduction, and distribution of the Work otherwise complies with

the conditions stated in this License.

5. Submission of Contributions. Unless You explicitly state otherwise,

any Contribution intentionally submitted for inclusion in the Work

by You to the Licensor shall be under the terms and conditions of

this License, without any additional terms or conditions.

Notwithstanding the above, nothing herein shall supersede or modify

the terms of any separate license agreement you may have executed

with Licensor regarding such Contributions.

6. Trademarks. This License does not grant permission to use the trade

names, trademarks, service marks, or product names of the Licensor,

except as required for reasonable and customary use in describing the

origin of the Work and reproducing the content of the NOTICE file.

7. Disclaimer of Warranty. Unless required by applicable law or

agreed to in writing, Licensor provides the Work (and each

Contributor provides its Contributions) on an "AS IS" BASIS,

WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or

implied, including, without limitation, any warranties or conditions

of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A

PARTICULAR PURPOSE. You are solely responsible for determining the

appropriateness of using or redistributing the Work and assume any

risks associated with Your exercise of permissions under this License.

8. Limitation of Liability. In no event and under no legal theory,

whether in tort (including negligence), contract, or otherwise,

unless required by applicable law (such as deliberate and grossly

negligent acts) or agreed to in writing, shall any Contributor be

liable to You for damages, including any direct, indirect, special,

incidental, or consequential damages of any character arising as a

result of this License or out of the use or inability to use the

Work (including but not limited to damages for loss of goodwill,

work stoppage, computer failure or malfunction, or any and all

other commercial damages or losses), even if such Contributor

has been advised of the possibility of such damages.

9. Accepting Warranty or Additional Liability. While redistributing

the Work or Derivative Works thereof, You may choose to offer,

and charge a fee for, acceptance of support, warranty, indemnity,

or other liability obligations and/or rights consistent with this

License. However, in accepting such obligations, You may act only

on Your own behalf and on Your sole responsibility, not on behalf

of any other Contributor, and only if You agree to indemnify,

defend, and hold each Contributor harmless for any liability

incurred by, or claims asserted against, such Contributor by reason

of your accepting any such warranty or additional liability.

END OF TERMS AND CONDITIONS

APPENDIX: How to apply the Apache License to your work.

To apply the Apache License to your work, attach the following

boilerplate notice, with the fields enclosed by brackets "[]"

replaced with your own identifying information. (Don't include

the brackets!) The text should be enclosed in the appropriate

comment syntax for the file format. We also recommend that a

file or class name and description of purpose be included on the

same "printed page" as the copyright notice for easier

identification within third-party archives.

Licensed under the Apache License, Version 2.0 (the "License");

you may not use this file except in compliance with the License.

You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software

distributed under the License is distributed on an "AS IS" BASIS,

WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

See the License for the specific language governing permissions and

limitations under the License.

Starred

Star

Fork

捐赠

0 人次

举报成功

我们将于2个工作日内通过站内信反馈结果给你！

请认真填写举报原因，尽可能描述详细。

举报类型

请选择举报类型

举报原因

取消

发送

误判申诉

此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。

如您确认内容无涉及不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。

取消

提交

简介

高度自动化的可观测性平台

避免手工插码，消除追踪盲点，简化平台维护。

使用 eBPF、OTel、WASM 等技术，让观测更自动。

展开

收起

暂无标签

https://deepflow.yunshan.net/zh/community.html

等 6 种语言

60.1%

Rust

30.0%

7.7%

xBase

1.0%

C++

0.7%

Other

0.5%

Apache-2.0

使用 Apache-2.0 开源许可协议

Code of conduct

保存更改

取消

发行版

暂无发行版

贡献者

全部

近期动态

加载更多

不能加载更多了

编辑仓库简介

简介内容

高度自动化的可观测性平台

避免手工插码，消除追踪盲点，简化平台维护。

使用 eBPF、OTel、WASM 等技术，让观测更自动。

主页

取消

保存更改

https://gitee.com/oplg/deepflow.git

git@gitee.com:oplg/deepflow.git

oplg

deepflow

DeepFlow

main

Git 大全

Git 命令学习

CopyCat 代码克隆检测

APP与插件下载

Gitee Reward

Gitee 封面人物

GVP 项目

Gitee 博客

Gitee 公益计划

Gitee 持续集成

OpenAPI

帮助文档

在线自助服务

更新日志

关于我们

加入我们

使用条款

意见建议

合作伙伴

售前咨询客服

技术交流QQ群

微信服务号

client#oschina.cn

企业版在线使用：400-606-0201

专业版私有部署：

13670252304

13352947997

开放原子开源基金会

合作代码托管平台

违法和不良信息举报中心

粤ICP备12009483号

简体

繁體

English

点此查找更多帮助

搜索帮助

Git 命令在线学习

如何在 Gitee 导入 GitHub 仓库

Git 仓库基础操作

企业版和社区版功能对比

SSH 公钥设置

如何处理代码冲突

仓库体积过大，如何减小？

如何找回被删除的仓库数据

Gitee 产品配额说明

GitHub仓库快速导入Gitee及同步更新

什么是 Release（发行版）

将 PHP 项目自动发布到 packagist.org

仓库举报

回到顶部

登录提示

该操作需登录 Gitee 帐号，请先登录后再操作。

立即登录

没有帐号，去注册

Introduction to DeepFlow | Instant Observability for Cloud-Native Applications

***

简体中文English Product eBPF Docs Blog Star

***

简体中文English About DeepFlow Introduction to DeepFlowWhat is DeepFlowCore FeaturesSolving Two Major Pain PointseBPF TechnologyMission and VisionDeepFlow ArchitectureKey Features of DeepFlowDeepFlow MilestonesDeepFlow ProductDeepFlow User Articles Install (Community Edition) OverviewAll-in-One Quick DeploymentMonitoring a Single K8s ClusterMonitoring Multiple K8s ClustersMonitoring Traditional ServersMonitoring Cloud ServersMonitoring Managed K8s ClustersMonitoring Serverless PodDeepFlow Upgrade Install (Enterprise Edition) Contact Us Best Practice Advanced Configuration of AgentAdvanced Server ConfigurationSpecial Environment DeploymentSuggestions for Production Environment Deployment Enterprise Edition Contact Us Features Universal Map AutoMetricsApplication Performance MetricsApplication Request LogNetwork Performance MetricsNetwork Flow LogList of Application ProtocolsCalculation Logic of Metrics and Operators Distributed Tracing AutoTracingSpring Boot DemoIstio Bookinfo Demo Continuous Profiling AutoProfiling AutoTagging Eliminate Data SilosSmartEncodingBasic Resource TagsCustom Resource TagsOptional Process Information TagsAdditional Cloud Resource TagsBusiness Tags in CMDB User Guide (Enterprise Edition) Tenant Data Query SearchService Search BoxPath Search BoxLog Search BoxMetric Search BoxSearch SnapshotLeft Side Quick Filter Dashboard OverviewView ListView DetailsAdding SubviewsTemplate Variables Panel OverviewTraffic TopologyDistributed TracingLine ChartBar ChartPie ChartHistogramTableTrend Analysis Chart Metrics Metric ViewingMetric Summary Events OverviewResource ChangesFile Reading and WritingAlert Universal Map OverviewBusiness DefinitionService ListService Topology Application OverviewMetrics StatisticsPath StatisticsPath TopologyCall LogDistributed TracingContinuous ProfilingRight Sliding Box Network OverviewService StatisticsNetwork PathNetwork TopologyFlow LogNAT TracingResource InventoryPCAP StrategyPCAP DownloadTraffic Distribution Infrastructure OverviewHostContainers Alert Alert PolicyAlert EventsPush Endpoint Resources OverviewSummaryResource PoolComputing ResourcesNetwork ResourcesNetwork ServicesStorage ServicesContainer ResourcesProcess ResourcesOther Resources Report Report Administrator Contact us Integration Process Wasm plugin Input Metrics Collector AutoTaggingIntegrate Prometheus DataIntegrating Telegraf Data Tracing Collector Full Stack Distributed TracingAutoTaggingCalling APM's Trace APIImporting OpenTelemetry DataSkyWalking Data Import Output Query API SQL APIPromQL APITrace Completion API Exporter OpenTelemetry Exporter Enterprise Edition Contact Us Diagnose FAQGrafana Slow QueryCommon Issues with AgentServer Performance Optimization Enterprise Edition Contact Us Release Notes DeepFlow Versioning RulesVersion Release Timelinev6.3 CE Release Notesv6.3 EE Release Notesv6.2 CE Release Notesv6.2 EE Release Notesv6.1 CE Release Notesv6.1 EE Release Notes About DeepFlow Introduction to DeepFlow This document was translated by GPT-4 # 1. What is DeepFlow DeepFlow is an observability product developed by Yunshan Networks (opens new window), designed to provide in-depth observability for complex cloud infrastructure and cloud-native applications. Based on eBPF, DeepFlow implements application performance metrics, distributed tracing, continuous profiling, and other observation signals with zero-disturbance (Zero Code) collection, integrating intelligent tags (SmartEncoding) technology to achieve a full stack (Full Stack) correlation. By using DeepFlow, cloud-native applications automatically attain deep observability, alleviating the burden on developers and providing monitoring and diagnostic capabilities from code to infrastructure for DevOps/SRE teams. To encourage global developers and researchers in the observability field to innovate and contribute, DeepFlow's core modules have been open-sourced using the Apache 2.0 License (opens new window) and officially published at the international top networking conference ACM SIGCOMM in 2023 (opens new window) with the academic paper "Network-Centric Distributed Tracing with DeepFlow: Troubleshooting Your Microservices in Zero Code". # 2. Core Features Universal map of any Service: Based on the leading AutoMetrics mechanism, eBPF is used to capture a universal service map of a production environment without disruption, including services developed in any language, unknown third-party services, and all cloud-native infrastructure services. It provides interpretation abilities for a large number of application protocols and offers a Wasm plug-in mechanism to extend the interpretation of any private protocol. Zero-disturbance in calculating the full-stack golden metrics for each call in the application and infrascructure quickly identifies performance bottlenecks. Distributed tracing of any Request: Based on the leading AutoTracing mechanism, using eBPF and Wasm technology to achieve distributed tracing without disruption, it supports applications in any language and completely covers gateways, service mesh, databases, message queues, DNS, network cards and other infrastructure, leaving no blind spots. Full stack - automatically collects network performance metrics and file read/write events associated with each Span. Starting from here, distributed tracing enters a new era of zero instrumentation. Continuous profiling of any Function: Based on advanced AutoProfiling mechanism, it leverages eBPF to collect production environment process profiling data with less than 1% overhead zero-disturbance, creates function level OnCPU and OffCPU FlameGraphs, and quickly locates full-stack performance bottlenecks in application functions, library functions, and kernel functions, automatically associating them with distributed tracing data. Even under kernel version 2.6+, network performance profiling capabilities can still be provided to gain insight into code performance bottlenecks. Seamless integration with popular observability technology stacks: Can serve as a storage backend for Prometheus, OpenTelemetry, SkyWalking, Pyroscope, and also provide SQL, PromQL, OTLP data interfaces as data sources for popular technology stacks. Based on the leading AutoTagging mechanism, it automatically injects unified tags for all observation signals, including cloud resources, K8s container resources, K8s Label/Annotation, business properties in CMDB, etc., to eliminate data islands. Storage performance 10x ClickHouse: Based on the leading SmartEncoding mechanism, it injects standardized, pre-encoded meta tags into all observation signals, reducing storage overhead by 10x compared to ClickHouse's String or LowCard solution. Custom tags are stored separately from observation data, so you can safely inject nearly infinite dimensions and cardinality of tags and enjoy an easy querying experience similar to BigTable. # 3. Solving Two Major Pain Points In traditional solutions, APM aims to achieve application observability through code instrumentation. Through instrumentation, applications can expose a wealth of observation signals, including metrics, traces, logs, function performance profiling, etc. However, the act of instrumentation actually changes the internal state of the original program, which does not logically conform to the requirement of observability to "determine internal state from external data". In key business systems in important industries such as finance and telecommunications, the landing of APM Agent is very difficult. With the advent of the cloud-native era, this traditional method also faces more severe challenges. In general, the problems with APM are mainly reflected in two aspects: the invasiveness of the agent makes it difficult to land, and the observation blind spots make it impossible to triage. Firstly, probe invasiveness makes it difficult to implement. The process of instrumentation requires modifying the source code of the application and redeploying it. Even technologies like Java Agent, which enhance bytecode, still need to modify the startup parameters of the application program and redeploy it. However, modifying the application code is just the first barrier, and there are usually many other problems encountered during the landing process: Code conflict: Do you often encounter runtime conflicts between different Agents when you inject multiple Java Agents for distributed tracing, performance profiling, logs, and even service meshes? When you introduce an observability SDK, have you ever encountered a dependency library version conflict that prevented successful compilation? The conflict is more apparent when there are more business teams. Difficult to maintain: If you are responsible for maintaining the company's Java Agent or SDK, how frequently can you update it? Right now, how many versions of the probe program are in your company's production environment? How long would it take to update them all to the same version? How many different languages of probe programs do you need to maintain at the same time? When the microservice framework and RPC framework of a company cannot be unified, these maintenance problems will become more serious. Blurred boundaries: All instrumentation code seamlessly enters the running logic of the business code, not distinguishing between you and me, and not being controlled. This makes it often difficult to escape blame when performance degradation or running errors occur. Even if the probe has been through a long period of practical honing, it is inevitable to ask for suspicion when problems occur. This is also why invasive instrumentation solutions are rarely seen in successful commercial products and more often seen in active open source communities. The activity of communities such as OpenTelemetry and SkyWalking prove this. In large corporations where division of labor is clear, overcoming collaboration difficulties is an obstacle that a technological solution cannot bypass for successful implementation. Especially in key industries such as finance, telecommunications, and power that bear the national economy and people's livelihood, the distinction of responsibilities and conflicts of interest between departments often make it "impossible" to implement an invasive solution. Even in open collaborating Internet companies, there are still problems such as developers' reluctance to implement instrumentation and the blame from operation and maintenance personnel when performance failures occur. After enduring a long period of effort, people have realized that intrusive solutions are only suitable for each business development team to actively introduce, maintain their versions of various Agents and SDKs, and be responsible for the risks of performance hiding and operation failure. Secondly, the observation blind spot makes it impossible to triage. Even though APM has landed in the enterprise, we still find that it is hard to define the fault boundary, especially in cloud-native infrastructure. This is because development and operation often use different languages to talk, for instance, when the call delay is too high the development will suspect the network is slow, the gateway is slow, the database is slow, the server is slow, but due to the lack of full-stack observability, the network, gateway, database give answers like the network card has not dropped any packets, the process CPU is not high, there are no slow logs in the DB, the server latency is very low, and a bunch of unrelated indicators still can't solve the problem. Triage is the most critical part of the fault handling process, and its efficiency is extremely important. If you are a business development engineer, in addition to business itself, you should also be concerned about system calls and network transmission processes; if you are a Serverless tenant, you may also need to pay attention to the service mesh sidecar and its network transmission; if you directly use virtual machines or build your own K8s cluster, then container networking is a critical issue to pay attention to, especially paying attention to CoreDNS, Ingress Gateway and other basic services in K8s; if you are a private cloud computing service administrator, you should be concerned about the network performance on the KVM host; if you are a private cloud gateway, storage, security team, you also need to pay attention to the system calls and network transmission performance on the service nodes. What is more important, in fact, is that the data used for error triage should be described in a similar language: how long each hop in the whole stack path takes for a single application call. We found that the observational data provided by developers through instrumentation may account for only 1/4 of the entire complete stack path. In the cloud-native era, relying solely on APM to solve fault boundaries is itself a misconception. # 4. eBPF Technology Suppose you have a basic understanding of eBPF, it is a secure and efficient technology to extend kernel functionality by running programs in a sandbox, it is a revolutionary innovation for traditional methods of modifying kernel source code and writing kernel modules. eBPF programs are event-driven, when the kernel or user program passes an eBPF Hook, the eBPF program loaded on the corresponding Hook point will be executed. The Linux kernel predefines a series of common Hook points, and you can also use kprobe and uprobe technology to dynamically add custom Hook points to the kernel and application programs. Thanks to Just-in-Time (JIT) technology, the operation efficiency of eBPF code can be as good as native kernel code and kernel modules. Thanks to the Verification mechanism, eBPF code will run safely and will not cause kernel crashes or enter dead loops. https://ebpf.io/what-is-ebpf/#hook-overview The sandbox mechanism is where eBPF differs from the APM instrumentation mechanism. The "sandbox" delineates a clear boundary between eBPF code and application code, enabling us to ascertain its internal state by obtaining external data without making any modifications to the application. Let's analyze why eBPF is an excellent solution to the defects of APM code instrumentation: First, zero-disturbance solves the problem of difficult implementation. Because eBPF programs don't need to modify the application program code, therefore, there are no runtime conflicts like Java Agent and SDK compilation conflicts, solving the problem of code conflict; running eBPF programs doesn't require changing and restarting application processes, doesn't require application program redeployment, it won't have the pain of maintaining Java Agent and SDK versions, solving the difficulty of maintenance problem; because eBPF runs efficiently and safely under the guarantee of JIT technology and Verification mechanism, you don't have to worry about causing unexpected performance degradation or runtime errors of application processes, solving the blurred boundary problem. In addition, from a management perspective, since only one independent eBPF Agent process needs to be run on each host, you can control its CPU and other resource consumption separately and accurately. Secondly, full-stack capabilities solve the problem of hard fault boundary definition. The capabilities of eBPF cover every layer from the kernel to the user program, thus we are able to trace the full-stack path of a request starting from the application program, going through system calls, network transmission, gateway services, security services, to the database service or peer microservice, ** it provides sufficient neutral observation data to quickly complete the fault boundary delineation**. For more detailed analysis on this aspect, please refer to our article "eBPF is the key technology for implementing observability" (opens new window). It is important to underline that this doesn't mean that DeepFlow only uses eBPF technology. Instead, DeepFlow supports seamless integration with popular observability technology stacks. For example, it can be used as the storage backend for observability signals from Prometheus, OpenTelemetry, SkyWalking, Pyroscope and others. # 5. Mission and Vision Mission: Make observation simpler. Vision: To be the first choice for realizing observability in cloud-native applications.

https://cloud.deepflow.yunshan.net 温馨提示请切换到PC端，登录DeepFlow 复制网址复制成功！

Product

eBPF

Docs

Blog

「直播回看」DeepFlow——开启高度自动化的可观测性新时代 - 知乎

「直播回看」DeepFlow——开启高度自动化的可观测性新时代 - 知乎切换模式写文章登录/注册「直播回看」DeepFlow——开启高度自动化的可观测性新时代云杉网络已认证账号第八期“原力释放云原生可观测性分享会”云杉网络研发VP 向阳分享《DeepFlow —— 开启高度自动化的可观测性新时代》， DeepFlow 第一个开源版本正式发布，它是一个高度自动化的可观测性平台，能够显著降低开发者的埋点、插码、维护负担。点击下方链接观看视频回放。【直播回看】DeepFlow —— 开启高度自动化的可观测性新时代01 认识DeepFlow直播间的朋友们大家好，很高兴能和大家分享DeepFlow 首个开源版本的正式发布。我相信通过我今天的介绍，大家能够感受到一个高度自动化的可观测性新时代，让我们一起来去见证和开启。下面是 DeepFlow 社区版的架构图，有些朋友对 DeepFlow 还不太了解，我简单介绍一下。DeepFlow 是云杉网络自研的可观测性平台，基于eBPF 等技术的一系列创新，使得它具备高度的自动化，为开发者构建可观测性显著降低工作负担。我们可以看到它能够自动同步资源、服务、K8s 自定义 Label 并作为标签统一注入到观测数据中（AutoTagging），它能够自动采集应用性能指标和追踪数据而无需插码（AutoMetrics、AutoTagging），它的 SmartEncoding 创新机制将标签存储的资源消耗降低了 10 倍。此外它还有很好的集成能力，能集成广泛的数据源，并基于 SQL 提供良好的北向接口。DeepFlow 的内核基于 Apache 2.0 License 开源，欢迎给我们Star（扫描下图二维码前往）！当我们在谈论高度自动化的时候，我们想传达哪些信息呢？今天的分享将会从四个方面展开：首先介绍 DeepFlow 自动化的指标数据采集能力 AutoMetrics，自动展示全栈性能指标和全景服务关系；接下来是自动化的 Prometheus、Telegraf 集成能力，汇集最全的指标数据，并解决数据孤岛和高基数烦恼；在此之后带你体验 DeepFlow 基于 eBPF 的创新的自动化分布式追踪能力 AutoTracing，相信这绝对是世界级的创新；最后是自动化的 OpenTelemetry、SkyWalking 集成能力，展示惊艳的无盲点的分布式追踪能力，解决追踪不全的痛苦。高度的自动化能让开发者有更多的时间进行业务开发，团队协同解决问题时也会更加丝滑自如。02 AutoMetrics那我们首先来看今天的第一弹吧，AutoMetrics。我们先热热身，部署一套完整的 DeepFlow。下图更清晰的展示了 DeepFlow 的软件架构：Rust 实现的 deepflow-agent 作为 frontend 采集数据，并与 K8s apiserver 同步资源和 Label 信息；Golang 实现的 deepflow-server 作为 backend 负责管理控制、负载均摊、存储查询。我们使用 MySQL 存储元数据，使用 ClickHouse 存储观测数据并支持扩展替换，使用 Grafana 展示观测数据。目前我们还有一个 Python 实现的 deepflow-app 进程用于提供分布式追踪的 API，后续将会使用 Golang 重写并逐步合并到 deepflow-server 中。deepflow-server 向上提供 SQL API，我们基于此开发了 Grafana 的 DeepFlow DataSource 和拓扑、分布式追踪等 Panel。deepflow-agent 可以运行在主机或 K8s 环境下，但 deepflow-server 必须运行在 K8s 中。下面我们猜想一下在一个 K8s 集群中部署 DeepFlow 需要几步？是的，只需要一步，复制粘贴这几条 helm 命名即可完成部署。如果你身边有电脑，可以现在就参考部署文档部署一下，期待在直播间或我们的微信群中反馈部署体验。1 helm repo add deepflow https://deepflowys.github.io/deepflow

2 helm repo update deepflow

3 helm install deepflow -n deepflow deepflow/deepflow --create-namespace刚才的部署只解决了一个 K8s 集群的监控问题，DeepFlow 的能力当然不仅限于此。参考部署文档，可以在各种场景下丝滑的部署 DeepFlow。我们支持快速的 All-in-One 单节点体验；支持监控多个 K8s 集群并为所有数据自动注入 K8s 资源和自定义 Label 标签；支持监控传统服务器和云服务器并为所有数据自动注入云资源标签；最后我们也支持监控托管 K8s 集群，自动注入 K8s 及云资源标签。所有这些场景下，DeepFlow 无需依赖任何外部组件就能做到水平扩展。部署完成，让我们开启高度自动化的可观测性之旅吧。我们最常谈论的黄金指标，一般是服务的Request、Error、Delay。下图是 DeepFlow 部署完成后就能展现的、任意微服务的应用性能 RED 指标，不管它是用什么语言实现的。我们目前支持采集 HTTP 1/2/S、Dubbo、MySQL、Redis、Kafka、MQTT、DNS 应用的指标数据，且支持列表还在持续增加中。我们会为所有的指标数据自动注入几十甚至上百个维度的标签字段，包括资源、服务、K8s 自定义 Label，这让使用者能随心聚合、灵活下钻。但这里我们希望着重强调的还是还是自动化的能力，这些指标开发团队再也不用发愁插码了、运维团队再也不用发愁总要推着让开发插码了。DeepFlow 的自动化，让每个团队生产力高一点，团队协作融洽一点。再来看另一张图，除了单个服务以外，DeepFlow也能呈现任意微服务之间的应用调用关系。同样，完全零插码。通过文档可登录我们的在线 Demo 环境实景体验。仅此而已了吗？远不止如此！在云原生环境下，网络的复杂性显著增加，成为故障排查的黑盒，定位问题通常靠猜。DeepFlow 拥有应用性能的全栈监控能力，能够自动化的采集任意微服务的吞吐、建连异常、建连时延、传输时延、零窗、重传、并发等上百个指标，同样也会自动注入几十甚至上百个维度的资源、服务、K8s 自定义 Label标签。同样，DeepFlow也能呈现任意微服务之间的网络调用关系。依然完全零插码。好了，相信大家已经开始更真切的感受到高度自动化的气息了。但它们能解决什么问题呢？依靠自动化的全景访问关系，DeepFlow 企业版的客户快速解决了大量的故障定位问题，常见的比如 RDS 运维用于定位哪个客户端造成了最大的访问负载。在 K8s 环境中由于 SNAT 的存在，没有办法知道哪些 Pod 在访问。传统的方法我们只能在客户端进行插码，但却很难做到全面覆盖。使用 DeepFlow 解决此类问题易如反掌，直接搜索 RDS 即可得知访问它的所有客户端的性能指标。那么全栈性能指标又能解决什么问题呢？一个故障可能是某个 API的时延过高，但这个时延究竟是哪个环节引起的，究竟应该由哪个团队上，你的团队解决这样的问题能有多快？DeepFlow的全栈能力能够快速回答一个访问关系在各个关键节点的性能状况，例如这张图里展示的，我们能精准区分瓶颈到底是在服务端 Pod、服务度 K8s 网络、云网络、客户端 K8s 网络、还是客户端自身。DeepFlow 让分布式环境下的排障如同单机一样简单，而这一切仍然是完全自动化的。DeepFlow 到底是怎么做到的呢？今天我们只能蜻蜓点水，后续会有更多的直播和文章分享底层机制。我们使用 eBPF、BPF 采集每一个请求（DeepFlow之名中的 Flow）在应用程序、系统调用、网络传输时的性能数据，并将他们自动关联起来。这样一来，一方面我们可以覆盖所有的通信端点（微服务），另一方面还能将每一跳的性能数据关联起来，快速定位问题到底出现在应用进程、Sidecar、Pod 虚拟网卡、Node网卡，DeepFlow 企业版还能继续定位宿主机网卡、NFV 网关网卡、物理网元端口等。这项工作仍然还有很多需要继续迭代的事情。我们知道 HTTP2/gRPC 的头部字段是压缩的，目前我们支持了基于静态压缩表的协议头解析，后续将会利用 eBPF uprobe 获取动态压缩表进行完整的头部解析。对于 HTTPS 我们目前支持 eBPF uprobe 对 Golang 应用的采集能力，后续会逐渐支持 C/C++/Java/Python 等多种语言。同时我们也理解实际业务环境中会存在大量的私有应用协议，我们希望通过 WebAssembly 技术提供给开发者灵活的可编程能力。03 Metrics Integration但仅仅这些指标还不够完善，可观测性需要尽量丰富的数据。接下来我们介绍 DeepFlow 自动化的指标数据集成能力。下图展示了 DeepFlow 和 Prometheus、Telegraf 的集成方法。我们通过 deepflow-agent 集成数据，作为 prometheus-server 的一个 remote-storage endpoint，或者作为 telegraf 的一个 output endpoint。整个流程比较简单，大家认为完成这样的部署需要几步呢？只需要两步，分别在prometheus/telegraf 和 deepflow-agent 侧修改一个配置即可。DeepFlow 这一侧的配置实际上只是个开关，我们没有默认开启，期望deepflow-agent 默认不会监听任何端口，对运行环境能够零侵扰。1 # prometheus-server config

2 remote_write:

3 - url: http://${DEEPFLOW_AGENT_SVC}/api/v1/prometheus

5 # telegraf config

6 [[outputs.http]]

7 url = "http://${DEEPFLOW_AGENT_SVC}/api/v1/telegraf"

8 data_format = "influx"

10 # deepflow config

11 vtap_group_id:

12 external_agent_http_proxy_enabled: 1这样简单的配置同样可以试用与各种复杂的场景，覆盖多 K8s 集群、云服务器，并且不需要任何外部组件协助即可做到水平扩展。为什么要将数据汇集到 DeepFlow 呢，我们先感受一下强大的 AutoTagging 能力。我们为 DeepFlow 的所有原生数据和集成数据都自动注入了大量的标签，使得数据关联不再有屏障、数据下钻不再有缺陷。这些标签来自云资源、K8s 资源、K8s 自定义 Label，我相信开发人员一定很喜欢这个能力，再也不用在业务代码里面插一大堆零散的 Tag 了。我们建议大家将所有需要自定义的标签在服务上线时通过 K8s Label 的方式注入，与业务代码完全解耦。至于和业务相关的动态标签，DeepFlow 也会以非常高效的方式完整的存储下来，支持检索和聚合。自动插入这么多标签，资源消耗怎样呢？DeepFlow的SmartEncoding 机制很好的解决了这一问题，我们提前将标签进行数值编码，指标数据在生成和传输时并不会携带这些标签，仅在存储之前统一插入已经编码后的数值化标签字段。对于K8s 自定义 Label 我们甚至不会随指标数据存储，仅在查询时进行关联。对比 ClickHouse 的 LowCard 或直接存储标签字段，SmartEncoding 机制使得我们在算力和存储消耗上可以有高达一个数量级的降低。因此，拒绝在业务代码中插标签不仅能偷懒，还很环保。我们更加希望的是，通过广泛的数据集成和关联来激活团队协同。DeepFlow 有自动化的网络、应用指标，Prometheus/Telegraf 有自动化的系统性能指标，再加上开发者通过 Exporter/StatsD 等暴露的业务指标。我们将这些丰富的指标沉淀到一个数据平台中，并进行高效的自动关联，希望能够促进运维、开发、运营团队的相互协同，提供所有团队的工作效率。在指标集成方面，我们也有一些计划中的工作。我们将会继续支持 Prometheus remote_read 接口，使得 DeepFlow 可以作为一个完整的 Prometheus remote-storage，这样能够不改变Prometheus 用户的使用习惯。我们计划将 DeepFlow 的自动化指标 Export 到 prometheus-server，使得熟悉 Prometheus 的开发团队可以轻松获取到更强大的全景、全栈指标告警能力。我们也在持续支持其他 Agent 的集成，我们坚信可观测性必须要对数据能广泛采集。另外，DeepFlow 也会支持同步服务注册中心中的信息，让应用运行时的丰富信息能够自动化的作为标签注入到观测数据中。04 AutoTracing下面我们进入一个新的议题 —— 追踪。我们首先来感受下 DeepFlow 自动化的 AutoTracing 能力。我们以一个 Istio 官方的 Bookinfo Demo 为例，和大家一起见证奇迹。这个 Demo 相信有不少朋友很熟悉，有 4 个各种语言的微服务，有 Envoy Sidecar。大家先猜测一下，完成对它的分布式追踪，我们需要做哪些事情？我们先来看看 OpenTelemetry + Jaeger 对这个 Demo 追踪效果怎样。你没有看错，由于这个 Demo 中没有做 instrumentation，Jaeger 看不到任何内容，空的。那么 DeepFlow 需要做什么呢？实际上什么都不用做，因为我们已经早早的通过一条 helm 命令将 DeepFlow 部署好了，无需再做任何操作。见证奇迹的时刻到了。什么代码都没有插入的情况下，我们完整的追踪到了这 4 个微服务之间的调用。依靠 eBPF 和 BPF 的能力，完全的自动化！下面我们带着大家详细感受一下这张朴素的火焰图深层次的魅力：零插码，是我们想传达的第一个感受。将火焰图的每个Span 绘制作为一个节点，我们得到了一个调用流程图，从图中可以清晰的看到这个简单应用的复杂调用过程。全链路，是我们想传达的第二个感受。4 个调用，我们追踪到了 24 个 eBPF Span、14 个 BPF Span，并构建出了他们的关系。多语言，是我们想传达的第三个感受。这里覆盖了Java、Python、Ruby、Node.js、C、C++ 实现的服务，DeepFlow 就这样悄无声息的追踪出来了。全栈，是我们想传达的第四个感受。我们可以看到，Pod 之间的逐跳网络访问路径清清楚楚，到底哪里是瓶颈明明白白。全栈，也体现在跨容器节点上，无论中间的网络路径是 IPIP 还是 VXLAN 隧道封装，都可以追踪的稳稳当当。全栈，还体现在 Pod 内部的流量路径上。当你使用 Envoy 时，是否被迷宫一样的流量路径所困扰？DeepFlow 能轻轻松松的打开 Pod 内部的流量路径黑盒，看的一清二楚。回顾一下上述六点，我相信他们都是非常酷的创新，我也相信大家也会同样相信。我们的文档中也对这个 Demo 进行了详细介绍，欢迎上手体验。既然这是一项创新的工作，初期大概率会有一些缺陷。目前我们已经能完美的解决阻塞式 IO（BIO）场景下的自动追踪，也能解决大部分负载均衡、API 网关（Nginx、HAProxy、Envoy 等）的自动追踪，他们往往都使用非阻塞式同步 IO（NIO）。但还没有搞定所有的异步 IO（AIO）场景，例如轻量级线程、协程等。我们的工作还在进行中，目前已经有了一些不错的进展。对深层次技术原理的拆解，我们计划在QCon 2022 上与大家分享。05 Tracing IntegrationAutoTracing 固然好，但能力发挥到极致也难以解决对应用程序内部指定函数之间调用的追踪。幸运的是，这方面整个开源社区已经有了 10 多年的积累，从 12 年前Google Dapper 的奠基开始，到 SkyWalking 的火热，再到今天 OpenTelemetry 的统一标准。那么 DeepFlow 和他们能产生怎样的结合呢。这一次，我们尝试以追踪一个 Spring Boot 应用为例来阐述 DeepFlow 的惊艳能力。这个Demo 比较简单，由 5 个微服务和 MySQL 组成。我们先来看看 OpenTelemetry + Jaeger 追踪效果，这回不是空的，页面上展示了 46 个Span。下面开始 DeepFlow 的表演了。我们推荐使用 otel-collector 的 agent 模式，将 trace 经由 deepflow-agent 发送给 deepflow-server。类似的，对 SkyWalking 数据的集成目前也通过 otel-collector 实现。大家现在可以猜想下我们需要几步完成我们的配置工作？直播进行到现在，相信已经没有悬念了，我们两步即可打通 OpenTelemetry 和 DeepFlow。1 # otel-agent config

2 otlphttp:

3 traces_endpoint: "http://${HOST_IP}:38086/api/v1/otel/trace"

4 tls:

5 insecure: true

6 retry_on_failure:

7 enabled: true

9 # deepflow config

10 vtap_group_id:

11 external_agent_http_proxy_enabled: 1 # 默认关闭，零端口监听a那么下面我们来感受一下 DeepFlow 的集成追踪能力，这张火焰图现在看起来平平淡淡，但却暗藏玄机，让我们一起慢慢揭开它神秘的面纱，感受无盲点追踪的震撼：全链路，是我们想传达出来的第一个感受。对比 Jaeger 显示的 46 个Span，DeepFlow 额外追踪到了 20 个 eBPF Span、30 个 BPF Span。我们先有一个数字上的感受，更多的玄机一层一层来看。全栈，是我们想传达出来的第二个感受。我们的网络路径追踪能力依然稳，清晰的展示了 Pod 之间的访问路径。全栈，此时同样也会展现在跨节点通信场景上，无论是否有隧道封装，无论采用何种隧道协议。全链路，我们还想继续传达。仔细看这个图最上方的6 个 Span。这是由于 loadgenerator 服务没有做插码，OpenTelemetry 不能给出它的追踪路径，但使用 DeepFlow 的追踪能力，自动补齐了 6 个 eBPF 及 BPF Span，整个过程不用手动做任何事情全链路，我们仍然想继续传达。再看图中这部分Span，eBPF 自动发现了在一系列 OTel Span 之前和之后的两组 eBPF Span，他们是 MySQL 事务的开始和结束，非常酷。我在想如果没有疫情，我们能通过线下活动来给大家分享这些能力，会得到什么样的现场反馈。无盲点，是我们想传达出来的第六个感受。我们看图中这段 Span，第一行的客户端调用和最后一行的服务端响应出现了显著的时差。这个时候一般上下游团队会去争吵，到底是谁的问题。DeepFlow 就像一个裁判，谈笑间回答了这里面的玄机。从图中我们能看到，靠近客户端的位置虽然 OpenTelemetry Span 的时延大，但 eBPF Span 时延明显降低了，云原生环境不再是一个黑盒，看的一清二楚。我相信大家此时应该也能感受到满满的团队协作感，再也不用争吵了。我们的文档中也对这个 Demo 进行了详细介绍，欢迎上手体验。另一方面，我们的 AutoTagging 能力也适用于追踪数据，我们会为所有的 Span 自动注入了大量标签。我们不再需要配置过多的 otel-collector processor 用于标签注入了，一切都是自动的、高性能的、环保的。那么 SkyWalking 呢。目前我们可以三步配置解决 SkyWalking 数据的集成，虽然多了一步，但相信对比上面的震撼，大家不会认为很麻烦。欢迎参考我们的文档上手体验。1 # otel-agent config

2 receivers:

3 # add the following config

4 skywalking:

5 protocols:

6 grpc:

7 endpoint: 0.0.0.0:11800

8 http:

9 endpoint: 0.0.0.0:12800

10 service:

11 pipelines:

12 traces:

13 # add receiver `skywalking`

14 receivers: [skywalking]

16 # otel-agent service yaml

17 spec:

18 ports:

19 - name: sw-http

20 port: 12800

21 protocol: TCP

22 targetPort: 12800

23 - name: sw-grpc

24 port: 11800

25 protocol: TCP

26 targetPort: 11800

28 # deepflow config

29 vtap_group_id:

30 external_agent_http_proxy_enabled: 1 # required同样，我们的多集群、异构环境监控能力在追踪场景下仍然是就绪的，整个数据平台仍然不需要外部组件就能水平扩展是的，我们也依然还有一系列未来的工作。包括不经过 otel-collector 直接集成 SkyWalking 数据，包括集成 Sentry 数据以解锁 RUM 能力。目前我们的追踪数据通过自己实现的 Grafana Panel 来展现，我想对接 Tempo 应该是一个不错的主意。06 展望未来最后，作为一个回顾，我们将今天提到的DeepFlow 关键词堆砌在这里，我不会在这里再去一个个强调这些乏力的关键词。现在我说DeepFlow 将可观测性从此带进了高度自动化的新时代，相信大家不会再有任何疑虑了。我们相信DeepFlow 是送给新时代开发人员、运维人员的一份礼物。我们希望开发人员能有更多的时间聚焦在业务上，将可观测性更多的交给自动化的 DeepFlow，让自己的代码更清晰整洁。这张图的下面我附带了 Tyler Treat 的演讲 —— The Future of Ops，Tyler在几年前很好的阐述了云原生时代 Ops 的挑战和机遇，我将它分享给运维同学们，在此也向 Tyler 致敬，也相信 DeepFlow 能被新时代 Ops 喜欢。可能大家会有疑问为什么我们今天没有谈论日志。DeepFlow在这方面已经做了一部分工作，但一直对这一领域保持敬畏，下个月我们和云原生社区、阿里云 iLogTail 一起，对 DeepFlow 在日志方面的现状和计划进行介绍，欢迎大家关注。我们希望打造一个世界级的开源可观测性平台。未来的路还有很长，就像攀登珠峰一样。如果将目前 DeepFlow 的版本号翻译成海拔，可能正好对应二号营地和三号营地之间。我们8848 封顶见！谢谢大家！发布于 2022-08-01 15:05自动化云原生（Cloud Native）开源赞同 1添加评论分享喜欢收藏申请

DeepFlow 在腾讯蓝鲸观测平台中的探索与实践 - 知乎

DeepFlow 在腾讯蓝鲸观测平台中的探索与实践 - 知乎切换模式写文章登录/注册DeepFlow 在腾讯蓝鲸观测平台中的探索与实践InfoQ已认证账号作者 | 刘文平策划 | 凌敏本文整理自腾讯 IEG 高级研发工程师刘文平在《蓝鲸 x DeepFlow 可观测性 Meetup》中的分享实录，详细阐述了蓝鲸可观测性平台如何有效地融合了 OpenTelemetry 的标准化数据接入能力及 DeepFlow 的无插桩、全面覆盖的数据收集能力，进而解决游戏业务在观测数据采集、数据孤岛、以及云原生基础设施观测等领域所面临的难题。并展望了通过 DeepFlow，构建适合腾讯游戏的专属观测场景。大家好，我是刘文平，很高兴能有机会参与本次有关 eBPF 的 meetup。我大概是在 2017 年加入腾讯，目前是专注于 APM、日志等相关领域，希望通过本次分享能够给大家带来在分布式链路追踪上不一样的观测方式。本次分享主要会从两个重点部分来展开，首先，我会介绍一下当前蓝鲸观测性平台上的一些实践，基于 OTel（OpenTelemetry）的一些方式。然后，我会给大家分享一个不一样的观测方式变化，也是我们基于最近一两年火起来的 eBPF 技术和 OTel 技术结合后，所带来的改变。蓝鲸观测平台整体架构首先，我先介绍一下蓝鲸以及蓝鲸观测平台。上图是蓝鲸整体架构图，包括底层的基础设施以及上层 SaaS 应用。在中间，我们构建了很多平台应用，包含了 aPaaS（开发者中心、前后台开发框架等）和 iPaaS（持续集成、CMDB、作业平台、容器管理、计算平台、AI 等原子平台）等模块，可以去帮助企业技术人员快速地构建他们自己的基础运营 Paas 平台。蓝鲸观测平台是在最上层，也就是在 CO 这个持续运营场景下所孵化出来的一个 SaaS 服务。上图是蓝鲸观测平台整体功能分层架构图。左边是监控平台部分，会专注于采集和上层应用场景。右边是计算平台和 AI 部分，专注于计算和数据分析。用户侧采集的数据只要是按监控平台协议要求接入的，可以直接使用监控平台所有的能力，但是对于数据有更复杂的统计需求或者是智能监控的场景，会按功能开关自动流入到计算平台和 AIOps 平台来实现，对于用户来说成本是相当低的。对于计算平台和 AIOps 平台来说，也是非常好的数据源，因为这些数据都是标准的有质量保障的数据。我们花费三年多的时间搭建了上图的这个“房子”。我们以整个蓝鲸体系为基石，以五种数据类型为支柱，开箱即用的观测场景作为"屋顶"。其中，Traces 数据也是拼图的重要一环，目前仍在不断打磨和探索中，往下，我会以 Traces 数据为重点，来展示我们的实践成果。基于 OTel 的实践与挑战OTel 可能已为熟悉可观测性平台的朋友所熟知。在 OTel 诞生之前，已有诸多分布式链路追踪相关的产品，如 Jaeger、Zipkin 等，蓝鲸观测平台也有自己的实现方案。然而，由于各种实现方案层出不穷，这对使用者来说意味着每换一个平台就需要重新检测代码、配置新的 SDK，甚至还需要关心新平台的数据协议，导致接入成本很高。OTel 的出现便是为解决这个问题，它统一了 Trace、Metric、Log 这三种数据协议，用户只需要加载一套 SDK，更改上报地址即可体验不同平台的功能。同时，数据标准化后不仅降低了用户维护 SDK 的负担，也提高了数据的可移植性。2021 年，蓝鲸观测平台也拥抱开源，我们将自己的实现方案统一转换成了 OTel 协议格式。下面，我将展示基于 OTel 的一些特性，帮助用户快速定位问题。首先，当用户有了一个具体问题后，这个时候往往用户已经有了一个明确的 traceid，或者说他已经有了明确的一个时间段，需要去定位具体是哪个服务出错了，是哪一个接口出错了，具体的这个出错内容是什么？那么可以带着 traceid 去到我们平台的检索页面，把这个 traceid 带入进去，直接快速的找到本次 trace 请求所经过的所有链路服务。如果更关心于这种服务与服务之间，或者说接口与接口之间的调用关系的话，那么可以切换到这个拓扑的视角；如果更关心于这种时间上的调用关系，想知道这些接口有没有按时间顺序去调的话，那么也可以切换到这种时序图的这种视角去从时序上看这个调用的关系；如果更喜欢用以往的这种火焰图的形式，更关心耗时分布，也可以切换到火焰图的视角，然后通过这种火焰图的形式去找到这个耗时最大的一个 span 是什么。其次，如果用户没有具体的问题，我们也会帮助他们挖掘更深层次的未知问题。为此我们提供了业务的全景视角，用户通过这个拓扑图，然后往下钻，通过观察这个拓扑图上的具体一个服务，然后下钻到里面可以看到每一个服务它的一些黄金指标，像请求数、错误数或者说请求耗时以及底下的这些像这种 Top 视角，包括耗时 Top 或者错误 Top。也可以切换接口的统计视角，这种视角去看到每一个接口的这种整体的一个情况。或者以错误统计的这种视角去查看错误次数最高是什么？然后我们也可以在右边的这个视图里面，直接展开看到它的这个错误的一些更详细的错误信息，堆栈信息。此外，我们还提供了其他视角，如主机视角、日志视角和实例视角，用户可以在这些关联视角中观测到更多的对象，以帮助他们更快地发现架构中更深层次的问题。在前两种情况中，用户会主动查看平台，通过平台发现问题。然而，即使用户没有查看平台，我们也会从 Trace 数据中提取出一些基础的黄金指标，并提供给用户配置告警，同时也提供了用户自定义的维度，以满足用户个性化的需求。将用户关心的关键指标通过告警的形式及时送达给用户。上图就是数据的联动。这里介绍关键的三个数据 Metric、Log、Trace 之间的关联关系，从任意一个数据视角都可以关联跳转到其他两个数据的视角，帮忙用户快速的发现定位问题。Trace 关联 Log 是以 service 来关联；Trace 关联 Metric 是以主机或目标维度来关联；Log 关联 Trace 是以 traceid 来关联；Log 和 Metric 之间是以主机目标维度互相关联；Metric 与 Trace 是以指标中通过 exemplars 机制打点的 traceid 来关联。以上就是蓝鲸观测平台上基于 OTel 所进行的实践。诚然我们做了这么多，但是在推广的过程中，还是会发现部分用户无法买账，不接受。主要的挑战有以下两个方面。第一，接入成本高。虽然 OTel 的出现已经将用户的接入成本降低了很多，SDK 中也提供了很多自动插码的逻辑，对于一些常见的库都有自动 hook 的逻辑，但也仅限于 Python 或者 Java 这种可注入的语言。但对于像 C、C++这种语言，接入成本就比较高了，几乎所有请求都需要自己手动插码。而在腾讯，游戏基本上都是基于 C、C++开发的。另外对于存量的游戏业务，或者代理的游戏业务，接受度就更低了，基本上不可能要求游戏研发方给运营加上这个插码逻辑。第二，数据的完整性。组件盲区：比如 Kafka 组件、存储组件，由于没办法上报 trace，那么这部分就无法观测系统层网络层盲区：另外对于系统和网络层的调用，也存在缺失，现有的 OTel 更倾向于开发者视角，对于运维视角不那么友好，我们需要打通开发者和运维视角，做到统一查看K8s 引入的复杂性：对于云原生，K8s 给开发者带来了便利的同时，也带来了不少挑战。开发者更专注业务逻辑的开发，而更少关注系统，部署等。当问题出现的时候，基于 OTel 的方式，很难完整的得到这部分的全景拓扑视图。基于 eBPF 的可观测性实践那么怎么去解决这些问题呢？前面讲了这么多，现在终于到今天的重点了：eBPF。eBPF（Extended Berkeley Packet Filter）是最近一两年兴起的技术，我们一直在关注这个领域。简单地说，eBPF 是对内核能力的扩展，它可以将用户的代码加载到内核中运行，这样我们就可以 hook 所有系统函数调用，捕获所有的系统请求和网络请求，然后分析用户程序的行为和网络数据的行为。目前，eBPF 的应用场景主要集中在网络、安全、和可观测性这三个领域。许多大公司已经在使用这项技术，这是从 http://ebpf.io 官网上截取的一张图片，上面列出了所有使用 eBPF 技术的优秀公司及产品。从这些公司中，我们可以大致了解到这些大牛公司的技术发展方向。我挑选出了所有应用了可观测性领域的公司，基本上有以下几家：Cillium 是基于 eBPF 的一层封装，提供了基础的数据抓取能力。它旗下两个产品，Hubble 和 Tetragon，分别专注于网络的可观测性以及安全可观测性。SysmonForLinux 是由微软开发的一个 Linux 命令行工具，可以监控和记录系统活动，包括进程生命周期、网络连接、文件系统写入等等。Pixie 是一款专注于应用可观测的产品，已经被 New Relic 收购，主要面向 K8s，但提供的工具不多，更多地提供一种脚本化操作能力。最后就是 DeepFlow，这是一个高度自动化的可观测性平台。在可观测性领域，DeepFlow 创新地实现了 AutoTracing、AutoMetrics、AutoTagging、SmartEncoding 等领先的技术，目前来看，应该是该领域最为前沿的产品。上图是 DeepFlow 在 GitHub 上的一个架构图，比较简单。由 Agent 和 Server 两个组件组成，Agent 负责采集，Server 负责管理 Agent、标签注入、数据的写入和查询。让我们先来感受一下，eBPF 和 OTel 数据结合后的一个效果。我们以一个自有的应用服务来进行演示，当前页面上的展示了 Trace 数据查询接口。该接口是通过页面请求 Web 服务，再由 Web 服务请求 API 服务。左侧图表展示了在未使用 eBPF 时的调用链视图，而右侧则揭示了整合后的效果。可以清晰地看到，从浏览器发起请求，到 Web 请求 API 服务的全过程，网络和系统的调用关系及耗时都被完整呈现。同时，我们还成功识别出了如 Nginx 等未插码的接入层服务。整个过程无需用户参与，也不必修改任何代码，就能完全追踪这些数据。技术挑战在实现这个功能的过程中，我们遇到了四个挑战：挑战一：数据如何打通？首先是 DeepFlow 数据跟我们观测平台的数据怎么去打通的一个问题。首先，我们需要解决的是如何将 DeepFlow 的数据和我们的观测平台的数据打通。其次，在数据打通后，如何将 OTel 数据与 eBPF 数据关联起来是个问题。OTel 数据是通过 traceid 来关联的，但网络数据、eBPF 数据并无 traceid，我们需要找到方法将它们关联。接下来，当数据关联成功后，我们需要将这些数据在页面上做出适当的展示，展示的顺序也需要精心安排。最后，基于 eBPF 的采集通常是基于主机或集群，我们需要将这部分数据精准路由到各个 OTel 应用下。下面我将逐一解析如何突破这些挑战。首先，我们要打通数据，有两个选择：或是观测平台将 OTel 数据提供给 DeepFlow，或是 DeepFlow 将数据导出到我们的接收端。尽管 DeepFlow 已具备前者的能力，但为了与观测平台后续数据的联动，并减少组件的维护，我们选择了后者。我们提出了此需求，希望 DeepFlow 能将数据导入我们的平台，DeepFlow 社区非常给力，很快就在 Server 上支持了数据导出的方式，且导出的数据仍为 OTel 格式。这样，我们接收端只需做少许微调，便可以复用已有的 OTel 接入流程，直接入库和查询。这样我们就打通了数据，那么，下一步应如何关联数据呢？挑战二：eBPF+OTel 数据如何关联？首先来看向下关联。对于一个 HTTP 请求，如果符合 W3C 标准，其实在 header 中存在一个名为 traceparent 的项，traceparent 本身包含了 traceid 和 spanid 的信息。当 DeepFlow Agent 读到 HTTP 的 header 中的这份数据后，会将此信息与下游所有的系统 Span 以及网络 Span 关联起来。也就是说，下游的系统 Span 和网络 Span 都会被标记上 traceid 和 spanid。因此，向下关联可以直接通过 traceid 和 spanid 实现。解决了向下关联的问题，我们再来看如何向上关联。向上关联的过程并没有像之前提到的 traceid 和 spanid 这种直接关联的方式，那怎么办呢？幸好我们有一个线索可以利用，就是在同一进程下的同一线程这个维度，相邻的系统调用会有一个叫做 syscalltraceid 的字段，用以记录相邻的系统调用。有了这个信息后，我们可以根据 traceid 和 spanid 先找到下游的 Span 信息，然后通过下游系统 Span 的 syscalltraceid 关联到上游的系统 Span。此外，系统 Span 和网络 Span 之间会被标记上相同的 TCP 序列号。因此，当我们找到上游的系统 Span 后，可以通过 TCP 序列号找到上游的网络 Span。通过这样不断地向上查找，我们就可以完整地补全上游的 Span 数据。挑战三：数据如何展示？然后我来探讨数据的展示问题，尤其是排序展示的挑战，有三种方式。第一种方式，我们可以根据开始时间排序，较早的时间排在前面，较晚的时间排在后面。然而，当两个系统主机存在时钟差异时，开始时间可能会混乱。因此，使用开始时间排序可能会引起混乱。第二种方式：是根据耗时进行排序。由于从上到下的调用，上层的耗时肯定比下层的耗时要长，我们可以将耗时较大的排在前面，耗时较小的排在后面，这样也可以得到良好的顺序。然而，也可能遇到一些极端情况，比如网络间的调用，其耗时差异本身就非常小，比如容器网络和主机网络之间的差异就非常小。如果我们的精度只到毫秒，那么这部分网络的耗时就会相同，在这种情况下，也可能出现混乱。第三种方式：是按系统调用的顺序进行排序，并针对具体问题进行具体分析。例如，在客户端，我们可以将应用 Span 放在第一位，然后是系统 Span，网络 Span 则按照容器网络、虚拟机网络、主机网络的顺序排列。当流程走到服务器端时，我们可以将这个顺序反过来。这样就可以很好地在页面上展示 Span。解决了上述问题后，还有根据用户的需求对原有的交互进行一些改进。因为系统 Span 和网络 Span 都加入了，会导致一次调用的 Span 数量至少增加了一倍，而一般开发者可能更关注业务逻辑的 Span 调用，只有在遇到基础组件问题时，他们才会关注系统的调用耗时以及网络的调用耗时。因此，我们采用了开关的方式，默认不开启，只有当用户打开了这个开关时，我们才会在页面上展示系统 Span 和网络 Span。这样，无论是从运维视角还是开发视角，我们都可以在同一个页面进行查看。挑战四：数据如何隔离？我们再看一下数据怎么去隔离，实际上是与 DeepFlow 团队一起探讨的一个方案。在容器环境下，POD 会有一些通用的标签，代表应用的归属信息。如果我们能获取这部分数据，就可以在我们的接收端进行良好的路由。在与 DeepFlow 一起探讨了这个需求之后，DeepFlow 很快就支持了这一部分数据的抓取，并将这些信息导出到我们接收端的数据中。从右边的图中可以看到，在 Span 详情中有 K8s 的所有标签信息。这样，我们就可以在接收端进行的应用路由，从而实现数据隔离的能力。在突破前面的这些挑战之后，我们实现了最初看到的那个效果图（基于 eBPF 和 OTel 的产品视图）。我们放大看一下 Web 到 API 的部分，可以看到基于 OTel 上报的 Span 只有两个，Web 端有一个主调的 Span，API 端有一个被调的 Span。通过 eBPF，我们零成本地关联出了 6 个系统 Span 和 10 个网络 Span，同时也发现了我们的接入层 Nginx 网关以及未插码的服务，找出了这些组件服务的盲区，同时也很好地覆盖了系统和网络的整体调用关系和耗时。对于容器层面，也直接展示出来，很好地缓解 K8s 及容器网络所带来的复杂性。基于 eBPF 的案例分析接下来，我将分享一个基于 eBPF 结合的产品案例，这是很久以前遇到的一个问题，用户反馈说有时候日志查询的耗时非常长。这个案例的架构与我之前所讲述的架构非常相似，用户通过浏览器查询日志，首先到达 Web 服务，然后 Web 服务会调用 API 服务，API 服务会请求 ES，然后将数据返回。从图中我们可以看到，Web 部分的 span 耗时大约 55 秒，基本上已经达到了不可接受的状态。最初，我们怀疑是不是 ES 出了问题，可能当时 ES 的负载较大，导致查询请求排队，从而造成了请求耗时过长。然而，通过抓包查看 API 层面的耗时，我们发现这一部分的耗时可能不到 3 秒，这就排除了存储问题。那么，这些消耗的时间都去哪了呢？在 web 和 api 之间又经过了哪些基础组件呢？当遇到非业务组件问题时，问题会变得棘手。在当时，我们的排查方式相当常规，首先找人，寻找 Web 和 API 之间到底经过了哪些基础组件，然后从请求的域名开始，逐步找到所有的服务，并检查这些服务的指标。如果某个服务没有指标，我们通常会采用 tcpdump 抓包的方式，然后使用 Wireshark 或者 Charles 这类工具进行分析，确定请求耗时长的原因在哪里。这个问题的发生的原因，非常隐蔽，其中一个服务在接收到 API 返回的数据后，会尝试猜测其编码。这是 Python 的 requests 库的一个特性，当遇到长文本时，这个猜测过程可能会非常耗时。由于此处是日志查询，所以文本长度恰好会很长。最后倒是解决方案非常简单了，即让 API 服务在返回数据时附带 charset 编码信息。这样，requests 库就不会去猜测编码了，从而解决了这个问题。但这里，我们需要注意的并非问题本身，而是整个排查过程的耗时。当问题出现在基础组件时，排查时间通常会非常长，过程非常痛苦。如前述案例，由于涉及到的基础组件较多，整体排查耗时可能会达到天级别。如果涉及到跨部门或跨团队，这个耗时可能会更长，一周甚至更久都有可能。如果我们有了 eBPF 技术，当类似的问题再次出现时，我们可以更加轻松地进行排查。例如，如左图所示，客户端请求耗时 1.32 秒，但 API 端只需要 400 毫秒。那么，这段时间的消耗在哪里呢？如果我们使用了 eBPF 技术，只需要在页面上勾选相关选项，我们就能快速查看从 Web 到 API 之间所有经过的服务以及中间系统网络的耗时。从图上可以看到，请求耗时最大的部分主要集中在某几个区域。通常，我们只需要花费大约 1 秒钟，就可以明确责任方。这种方式极大地减少了问题排查的时间，降低了人力成本。我们不再需要逐一询问各个服务的责任人，也无需对所有可能的服务进行 tcpdump 抓包分析，大大提高了效率。总结与展望在 eBPF 技术的加持下，我们未来主要工作是，有两个方向：第一个方向：打造游戏观测场景，全面覆盖自研业务以及代理业务。首先，对于自研业务，我们希望通过 eBPF 技术打通游戏自身的自研组件数据，无侵入式地覆盖所有游戏业务，提供全面的观测场景。其次，对于代理业务，也就是我们托管并运行的第三方开发的游戏，由于我们很难要求第三方通过插入代码的方式来获取观测数据，因此 eBPF 的零代码插入能力就显得尤为重要。通过 eBPF，我们可以快速、低成本地获取所需的观测数据。通过上述两个方面的覆盖，我们可以在很大程度上完善游戏业务的整体观测场景，进一步提升我们的服务质量和效率。第二个方向：将 eBPF 数据与更多的数据进行关联。例如，我们希望将 eBPF 数据与我们的蓝鲸配置平台以及蓝鲸容器管理平台的数据进行整合，从而为业务构建一个更全面的应用全景视图。这样，我们就能够不仅仅从应用层面，还能从逻辑架构层面，迅速地进行故障生成和根因定位。有了这个全景视图，我们也能反向推动所有对象的数据关联关系规范化。目前，蓝鲸社区官方已经推出了免费线上体验环境，大家可以以最低的成本和最快的方式来了解和使用蓝鲸的所有产品。此外，我们的 eBPF 能力也将在近期推出。本文转载来源：DeepFlow 在腾讯蓝鲸观测平台中的探索与实践_可观测_刘文平_InfoQ精选文章发布于 2023-06-20 15:22・IP 属地黑龙江Meetup腾讯蓝鲸赞同 2添加评论分享喜欢收藏申请

DeepFlow · GitHub

Toggle navigation

deepflowio

Product

Actions

Automate any workflow

Packages

Host and manage packages

Security

Find and fix vulnerabilities

Codespaces

Instant dev environments

Copilot

Write better code with AI

Code review

Manage code changes

Issues

Plan and track work

Discussions

Collaborate outside of code

Explore

All features

Documentation

GitHub Skills

Blog

Solutions

For

Enterprise

Teams

Startups

Education

By Solution

CI/CD & Automation

DevOps

DevSecOps

Resources

Learning Pathways

White papers, Ebooks, Webinars

Customer Stories

Partners

Open Source

GitHub Sponsors

Fund open source developers

The ReadME Project

GitHub community articles

Repositories

Topics

Trending

Collections

Pricing

Search or jump to...

Search code, repositories, users, issues, pull requests...

Clear

Search syntax tips

Provide feedback

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

Cancel

Submit feedback

Saved searches

Use saved searches to filter your results more quickly

Name

Query

To see all available qualifiers, see our documentation.

Cancel

Create saved search

You signed in with another tab or window. Reload to refresh your session.

You signed out in another tab or window. Reload to refresh your session.

You switched accounts on another tab or window. Reload to refresh your session.

Dismiss alert

DeepFlow

followers

China

https://deepflow.io/community.html

Overview

Repositories

Discussions

Projects

Packages

People

Overview

Repositories

Discussions

Projects

Packages

People

Pinned

deepflow

deepflow Public

eBPF-Powered Observability & Zero-Code Distributed Tracing ✨

2.2k

239

deepflow-gui-grafana

deepflow-gui-grafana Public

TypeScript

deepflow-dashboards

deepflow-dashboards Public

An automated observability platform for cloud-native developers.

Shell

docs

docs Public

DeepFlow Docs

Vue

deepflow-charts

deepflow-charts Public

An automated observability platform for cloud-native developers.

Smarty

deepflow-app

deepflow-app Public

Python

Repositories

Type

Select type

All

Public

Sources

Forks

Archived

Mirrors

Templates

Language

Select language

All

Java

JavaScript

Python

Rust

Shell

Smarty

TypeScript

Vue

Sort

Select order

Last updated

Name

Stars

Showing 10 of 26 repositories

deepflow

Public

eBPF-Powered Observability & Zero-Code Distributed Tracing ✨

2,176

Apache-2.0

239

(3 issues need help)

Updated Mar 7, 2024

deepflow-app

Public

Python

AGPL-3.0

Updated Mar 7, 2024

deepflow-auto-test

Public

automation test case of deepflow

Python

Apache-2.0

Updated Mar 7, 2024

deepflow-dashboards

Public

An automated observability platform for cloud-native developers.

Shell

Apache-2.0

Updated Mar 6, 2024

docs

Public

DeepFlow Docs

Vue

Updated Mar 6, 2024

deepflow-gui-grafana

Public

TypeScript

AGPL-3.0

Updated Mar 1, 2024

deepflow-wasm-go-sdk

Public

deepflow go wasm plugin sdk

Updated Feb 28, 2024

hpack-rs

Public

Forked from

mlalic/hpack-rs

An HPACK coder implementation in Rust

Rust

MIT

Updated Feb 18, 2024

deepflow-charts

Public

An automated observability platform for cloud-native developers.

Smarty

Apache-2.0

Updated Jan 19, 2024

deepflow-exporter-contrib

Public

Contrib repository for the DeepFlow Exporter

Apache-2.0

Updated Jan 4, 2024

View all repositories

People

Top languages

Rust

Python

Java

Most used topics

Loading…

Footer

Footer navigation

Terms

Privacy

Security

Status

Docs

Contact

Manage cookies

Do not share my personal information

You can’t perform that action at this time.

Follow

imtoken钱包安卓版手机下载|deepflow

imtoken钱包安卓版手机下载|deepflow

DeepFlow 产品 | 云原生-可观测性-零侵扰采集-全栈可观测-分布式追踪-eBPF-Wasm-DeepFlow可观测性平台

DeepFlow 简介 | 云原生-可观测性-零侵扰采集-全栈可观测-分布式追踪-eBPF-Wasm-DeepFlow可观测性平台

GitHub - deepflowio/deepflow: :honeybee: eBPF-Powered Observability & Zero-Code Distributed Tracing :sparkles:

DeepFlow 基于 eBPF 的高度自动化可观测性实践 - 知乎

一文读懂基于 eBPF 自动化可观测平台 - DeepFlow-阿里云开发者社区

DeepFlow: 高度自动化的可观测性平台 避免手工插码，消除追踪盲点，简化平台维护。 使用 eBPF、OTel、WASM 等技术，让观测更自动。

Introduction to DeepFlow | Instant Observability for Cloud-Native Applications

「直播回看」DeepFlow——开启高度自动化的可观测性新时代 - 知乎

DeepFlow 在腾讯蓝鲸观测平台中的探索与实践 - 知乎

DeepFlow · GitHub

最近的新闻

您可能喜欢的文章

tokenpocket钱包下载中文版安装|ctx

tp钱包安卓下载|dnf 70

币安可以给TP钱包转USDT吗

如何处理Tp钱包被盗的问题？

虚拟货币持币生息钱包：什么是持币生息钱包及

猫钱包：一站式虚拟货币管理工具

比特币钱包与地址如何关联

DeepFlow: 高度自动化的可观测性平台避免手工插码，消除追踪盲点，简化平台维护。使用 eBPF、OTel、WASM 等技术，让观测更自动。