DeepFlow 基于开源的全栈全链路可观测性建设实践

admin 2022年9月8日11:00:18评论121 views字数 10323阅读34分24秒阅读模式

DeepFlow 基于开源的全栈全链路可观测性建设实践

本文是作者在 2022 GOPS 全球运维大会深圳站的演讲实录。PPT 下载[1]

PPT下载地址:http://yunshan-guangzhou.oss-cn-beijing.aliyuncs.com/yunshan-ticket/pdf/ea0e4b6ebd97dda7b399f0197997358f_20220826140446.pdf

大家好,我是云杉网络向阳。我们刚刚开源了 DeepFlow,它是一个高度自动化的可观测性协作平台。DeepFlow 已经有六年历史了,基于我们的实战经验,今天我将围绕开源生态,和大家一起分享一种可观测性平台建设的成功之道。

首先我会从经常发生在大家工作中的典型故事出发,谈一谈可观测性建设面临的困难。之后,由于时间限制,今天我主要会从 Metrics 和 Tracing 两个方面来展开谈一谈,介绍怎样从自动化走向精细化,从首战告捷到节节胜利,一步步构建完整的可观测性能力。最后作为一个总结,我会分享 DeepFlow 在我们的客户以及社区中的落地案例,相信它会是在座各位成长为新一代运维人 —— NewOps 的一个趁手武器,使用它为自己的组织量身打造一个可观测性产品,为开发团队提供优质的可观测性自助服务。

DeepFlow 基于开源的全栈全链路可观测性建设实践

欢迎预约第十期云原生可观测性分享会 ▲

01

从心碎到希望

我相信这会是大家经常经历的一个心碎故事。由于业务团队需要响应大量的业务需求,通常会将业务稳定性保障的工作交给 SRE。两个团队的摩擦通常会从业务交接的那一刻开始,SRE 需要开发暴露完整的性能指标,但开发疲于应对业务需求总会打一些折扣。另一方面开发认为 SRE 只会接告警,就像一个透明管道,最终的排查还是要自己上,而且还会时不时被卡上线。而经常发生的故障也会让 SRE 失去耐心,认为开发没有做好测试,自己是擦屁股角色。两个团队的矛盾越积越深。因此,在 Google 的 SRE 理念提出 19 年之后的今天,我们也逐渐开始听到了一些思考的声音,大家开始讨论我们还需要 SRE 吗?[2]

我们还需要 SRE 吗?https://zhuanlan.zhihu.com/p/554118190

DeepFlow 基于开源的全栈全链路可观测性建设实践
DEV 与 SRE 之争

遇到这种问题时,我们希望引入 DevOps 理念将开发和运维团队打通,让开发自己负责服务的稳定性,解决跨团队协同问题。可惜世界上没有银弹,只要有人在的地方就会有情感有江湖,心碎的故事再次上演。在业务需求面前可观测性建设再一次让路,指标打折扣,追踪追不全。微服务是当前普遍的业务架构,于是我们会发现可观测性建设的妥协变成了 Service Owner 之间的甩锅,不完整的指标和追踪数据说不清楚到底是谁出了问题。另一方面,Infra 团队经常升级可观测性 SDK,也会让使用编译型语言的开发团队心生抱怨 —— 为什么又要让我们发版?

好消息是,我们的产品 DeepFlow 开源了,大量实战经验让我们相信它即将带给广大开源社区用户可观测性建设革命性的改变。DeepFlow 是一个高度自动化的可观测性协作平台。一方面它基于 eBPF 的 AutoMetrics 和 AutoTracing 能力,实现了指标和分布式追踪的自动采集;另一方面它通过 AutoTagging 机制和强大的可观测性数据集成能力,包括对 Prometheus、Telegraf、OpenTelemetry、SkyWalking 等优秀开放数据的集成和打通能力,激活团队协作,让开发、运维、业务运营团队能在一个频道上对话。下图右下角是我们的 GitHub 二维码,期待大家在我讲完之后扫码加星。

DeepFlow 基于开源的全栈全链路可观测性建设实践
DeepFlow 社区版架构

02

构建全栈 Metrics 体系

接下来,我来给大家分享一种从自动化走向精细化,从首战告捷到节节胜利的全栈指标体系建设之路。

我们到底需要哪些指标呢,相信大家已经都是专家。我们需要描述系统的CPU、内存、IO、网络等性能指标,以及描述应用的 RED(Request/Error/Delay)黄金指标,以及还需要重要的面向业务的指标。这些指标通常被不同的团队关注,DeepFlow 希望在一个平台上打通这些指标,并构建完整的关联性,充分释放团队之间的协同效用。

谈到从自动化走向精细化,那么首先给大家介绍一下 DeepFlow 的 AutoMetrics 能力。我们基于 eBPF 的零侵扰特性,利用 AF_PACKET 从网卡上采集流量,利用 kprobe/tracepoint 和 uprobe/USDT 从内核函数调用和用户函数调用中采集协议数据,为云原生应用自动生成全栈的系统和应用性能指标,覆盖每个应用请求(即 DeepFlow 中的 Flow)从应用进程、Sidecar、Pod 网卡、容器节点网卡、KVM 宿主机网卡、NFV 网关(其中 KVM、NFV 网关仅企业版支持)的全栈性能指标。所有这些能力不需要开发团队插入一行代码,不需要修改 Java 字节码,不需要重启应用进程,完全的自动化!

DeepFlow 基于开源的全栈全链路可观测性建设实践
eBPF/BPF 采集能力

我们来看一下 AutoMetrics 的效果。我们希望由此带给大家的第一个能力是全景。通过对协议数据的解析,我们能自动呈现 HTTP 1/2/S、Dubbo、MySQL、Redis、Kafka、MQTT、DNS 的 RED 黄金指标,并呈现任意微服务之间的调用关系,无论它使用什么样的编程语言(其中 HTTPS 使用 eBPF uprobe,目前仅支持 Golang,正在迭代支持其他语言)。在此之上,我们会给指标数据自动注入丰富的资源、服务、K8s 自定义 Label 作为标签,使得数据能随心过滤、随心聚合。而解锁所有这些指标能力,都不再需要 SRE 去 Push 开发团队了,我相信大家已经开始感受到了高度自动化的可观测性能力。

DeepFlow 基于开源的全栈全链路可观测性建设实践
全景指标

这还不够,我们希望由此带给大家的第二个能力是全栈。自动呈现任意服务之间的网络通信关系,以及吞吐、并发、建连时延、传输时延、建连异常、零窗、重传等网络性能指标。与此同时,利用 DeepFlow 的 AutoTagging 能力,我们为所有指标数据自动注入了统一的标签,使得网络指标和应用指标能够相互关联,并且 Pod、Node、Host 等不同位置的网络和应用指标也能够相互关联。同样,所有这些指标数据也是全自动获取的,不需要开发团队进行插码,也不需要 Infra 团队改造 K8s 基础设施。

这些能力能帮助我们解决什么问题呢,我相信大家心里已经有一些答案了。我们在实战中通常解决的问题之一是快速定位是谁,比如到底是谁在摧残我的 RDS。在 K8s 环境下,由于 SNAT 存在的缘故,我们以往无法快速定位到具体的 POD。另外在快速迭代的微服务场景下,我们通常也难以保证所有的客户端都进行了插码。因此这样一个简单的问题其实很难快速回答,通常我们可能需要靠猜来进行定位。现在基于 DeepFlow 的 AutoMetrics 能力,这样的问题能一键回答了。

DeepFlow 基于开源的全栈全链路可观测性建设实践
快速定位是谁

再一个常见的问题是快速定位在哪。任何两个微服务之间的性能指标,DeepFlow 完整的采集了访问路径沿途的逐跳路径,并将所有数据进行了关联。因此我们能快速的判断到底故障发生在客户端、客户端 K8s 节点、云网络、服务端 K8s 节点、还是服务端,也能进一步快速的判断问题是出现在网络建连时延、网络传输时延、还是应用时延。这样一来,再复杂的问题,也能直接交由相应的团队进行响应,所有的关联团队也能快速协同起来。

DeepFlow 基于开源的全栈全链路可观测性建设实践
快速定位在哪

好了,我相信大家已经开始尝到甜头了,SRE 更自由了,开发也更自由了。迎来首战告捷以后,我们继续向前从胜利走向胜利。接下来给大家介绍一下 DeepFlow 的指标集成能力,我们目前支持集成 PrometheusTelegraf 的指标数据,而且也支持集成多个 K8s 集群、传统服务器、云服务器等异构环境中的所有指标数据。

DeepFlow 基于开源的全栈全链路可观测性建设实践
DeepFlow + Prometheus/Telegraf

集成 Prometheus 特别简单,同样也体现了 DeepFlow 的高度自动化。仅仅两步,分别配置 Prometheus Server 和 DeepFlow,我们就能将所有的指标数据通过 remote_write 接口自动集成到 DeepFlow 中。同样对 Telegraf 的集成也很简单,也是两步,就能将所有指标数据通过 HTTP output 接口自动集成到 DeepFlow 中。集成方式可参考 DeepFlow 在线文档[3]

DeepFlow 在线文档:https://deepflow.yunshan.net/docs/zh/agent-integration/metrics/prometheus/

DeepFlow 的能力还不止如此,在集成的同时,它的 AutoTagging 能力会为所有指标数据自动注入标签,包括云资源标签、容器资源标签、K8s 自定义 Label 标签,毫无疑问也会保留原始指标中的所有标签。这意味着开发不再需要辛苦的插入一大堆标签了,现在已经插入的一些标签也可以通过 K8s Label 代替了,好多代码可以删除了。实际上有了 DeepFlow 以后,我们希望大家能够充分利用 CI/CD 等 DevOps 流程,利用 K8s Label 的标准化标记能力,让业务代码更干净。作为一个工程师我相信删除冗余代码的感觉最好了!

DeepFlow 基于开源的全栈全链路可观测性建设实践
AutoTagging

插入这么多标签资源消耗如何?DeepFlow 的 SmartEncoding 机制很好的解决了这个潜在问题。首先我们使用 ClickHouse 进行数据的存储,因此不用担心高基数标签问题;其次这些自动注入的标签将会提前进行编码,以数值字段的方式在 Server 端插入到数据中;并且对于大量的 K8s 自定义 Label,仅仅需要在查询时进行关联,完全无需存储。基于这些优化,DeepFlow 可以获得在 ClickHouse 原有性能之上的 10 倍提升,包括对于 CPU 和存储的提升。

那么你可能会有疑问,这样做了以后查询会不会特别复杂,我们也想到了这一点,通过一个抽象计算层,我们统一的向上层暴露标准 SQL 查询接口。对所有数据的查询就像他们是一张张大宽表一样,完全不用关心底下实际存储的到底是数值类型标签还是字符串类型标签,也不用关心 K8s Label 是否随着指标数据一起存储了,一条 SQL 语句、一层 SELECT 均可搞定查询。我们也为 Grafana 开发了很好用的交互式查询条件编辑器,只要会 SQL 就能操作下来,欢迎访问我们的 Online Demo[4] 体验。

体验Online Demo: https://deepflow.yunshan.net/docs/zh/install/overview/

DeepFlow 基于开源的全栈全链路可观测性建设实践
SmartEncoding

好了,从自动化走向精细化,我们从首战告捷到节节胜利,构建了完整的系统、应用、业务指标体系,并且将所有的指标拉齐关联,让运维、开发、运营团队能在一个平台上协同

DeepFlow 基于开源的全栈全链路可观测性建设实践
全栈指标体系

03

构建无盲点的 Tracing 能力

聊完了指标我们再来聊追踪,同样是从自动化到精细化的思路,从首战告捷到节节胜利,建设无盲点的分布式追踪能力

团队之间的摩擦往往来自于盲点。以往分布式追踪是一项高度依赖插码的工作,微服务的快速迭代、云原生基础设施的复杂性都使得这项工作变得越来越困难,覆盖面越来越小。这是一个残缺的火焰图,冰封的部分由于无法插码、或者没有来得及插码变成了盲区。而不同的团队也可能使用不同的追踪方案,使得业务流程在追踪时变得割裂。比如左边的团队负责用户,使用 SkyWalking;右边的团队负责业务,使用 OpenTelemetry。

DeepFlow 基于开源的全栈全链路可观测性建设实践
追踪追不全

同样,我们先来看看 DeepFlow 强大的 AutoTracing 能力。这次我们以一个 Istio 官方的 Bookinfo Demo 为例先来展示一下实际的效果。这个 Demo 由 Java、Ruby、Python、Node.js 语言开发的四个微服务组成,并且使用到了服务网格,每个 Pod 中都有 Sidecar 劫持流量。大家先猜测一下,完成对它的分布式追踪,我们需要做哪些事情?

DeepFlow 基于开源的全栈全链路可观测性建设实践
Istio Bookinfo Demo

我们先来看看 OpenTelemetry + Jaeger 对这个 Demo 追踪效果怎样。你没有看错,由于这个 Demo 中没有做 instrumentation,Jaeger 看不到任何内容,空的。见证奇迹的时刻到了!什么代码都没有插入的情况下,DeepFlow 完整的追踪到了这 4 个微服务之间的调用。依靠 eBPF 和 BPF 的能力,完全的全栈、全链路、自动化!

下面我们带着大家详细感受一下这张朴素的火焰图深层次的魅力:零插码,是我们想传达的第一个感受。将火焰图的每个 Span 绘制作为一个节点,我们得到了一个调用流程图,从图中可以清晰的看到这个简单应用的复杂调用过程。全链路,是我们想传达的第二个感受。4 个调用,我们追踪到了 24 个 eBPF Span、14 个 BPF Span,并构建出了他们的关系。多语言,是我们想传达的第三个感受。

这里覆盖了 Java、Python、Ruby、Node.js、C、C++ 实现的服务,DeepFlow 就这样悄无声息的追踪出来了。全栈,是我们想传达的第四个感受。我们可以看到,Pod 之间的逐跳网络访问路径清清楚楚,到底哪里是瓶颈明明白白。

DeepFlow 基于开源的全栈全链路可观测性建设实践
同节点链路

全栈,也体现在跨容器节点上,无论中间的网络路径是 IPIP 还是 VXLAN 隧道封装,都可以追踪的稳稳当当。

DeepFlow 基于开源的全栈全链路可观测性建设实践
跨节点链路

全栈,还体现在 Pod 内部的流量路径上。当你使用 Envoy 时,是否被迷宫一样的流量路径所困扰?DeepFlow 能轻轻松松的打开 Pod 内部的流量路径黑盒,看的一清二楚。

DeepFlow 基于开源的全栈全链路可观测性建设实践
App 及 Envoy 链路

回顾一下上述六点,我相信他们都是非常酷的创新,我也相信大家也会同样相信。我们的在线文档[5]中也对这个 Demo 进行了详细介绍,欢迎上手体验。

在线文档:https://deepflow.yunshan.net/docs/zh/auto-tracing/istio-bookinfo-demo/#%E6%9F%A5%E7%9C%8B%E5%88%86%E5%B8%83%E5%BC%8F%E8%BF%BD%E8%B8%AA

尝到甜头了吗?SRE 更自由了,开发也更自由了。目前这样的自动化追踪能力可用于所有多线程并发模型的场景,也可用于 Nginx、HAProxy、Envoy 等中间件,虽然还不能完全覆盖所有场景,但首战告捷以后,同样我们又可以继续向前解锁无盲点的追踪能力了。那么现在给大家介绍一下 DeepFlow 的追踪集成能力,我们目前支持集成 OpenTelemetry 和 SkyWalking 的追踪数据。

DeepFlow 基于开源的全栈全链路可观测性建设实践
DeepFlow + OpenTelemetry/SkyWalking

集成 OpenTelemetry 同样也体现了 DeepFlow 的高度自动化。仅仅两步,分别配置 otel-collector 的 traces_endpoint 和 DeepFlow,我们就能将所有的追踪数据通过 OTLP HTTP 接口集成到 DeepFlow 中。同样对 SkyWalking 的集成也很简单,在 OpenTelemetry 的基础上,配置对 SkyWalking Trace 数据的接收,就能将所有追踪数据集成到 DeepFlow 中。集成方式可参考 DeepFlow 在线文档[6]

这一次,我们尝试以追踪一个 Spring Boot 应用为例来展示 DeepFlow 的惊艳能力。这个 Demo 比较简单,由 5 个微服务和 MySQL 组成。

DeepFlow 基于开源的全栈全链路可观测性建设实践
Spring Boot Demo

我们先来看看 OpenTelemetry + Jaeger 追踪效果,这回不是空的,页面上展示了 46 个 Span,对比 DeepFlow 我们能展示 96 个 Span,这张火焰图现在看起来平平淡淡,但却暗藏玄机,让我们一起慢慢揭开它神秘的面纱,感受无盲点追踪的震撼。

全链路,是我们想传达出来的第一个感受。对比 Jaeger 显示的 46 个 Span,DeepFlow 额外追踪到了 20 个 eBPF Span、30 个 BPF Span。我们先有一个数字上的感受,更多的玄机一层一层来看。

全栈,是我们想传达出来的第二个感受。我们的网络路径追踪能力依然稳,清晰的展示了 Pod 之间的访问路径。全栈,此时同样也会展现在跨节点通信场景上,无论是否有隧道封装,无论采用何种隧道协议。全链路,我们还想继续传达。仔细看这个图最上方的 6 个 Span。这是由于 loadgenerator 服务没有做插码,OpenTelemetry 不能给出它的追踪路径,但使用 DeepFlow 的追踪能力,自动补齐了 6 个 eBPF 及 BPF Span,整个过程不用手动做任何事情。

DeepFlow 基于开源的全栈全链路可观测性建设实践
关联 Client

全链路,我们仍然想继续传达。再看图中这部分 Span,eBPF 自动发现了在一系列 OTel Span 之前和之后的两组 eBPF Span,他们是 MySQL 事务的开始和结束,非常酷。

DeepFlow 基于开源的全栈全链路可观测性建设实践
发现 MySQL Transaction

无盲点,是我们想传达出来的第六个感受。我们看图中这段 Span,第一行的客户端调用和最后一行的服务端响应出现了显著的时差。这个时候一般上下游团队会去争吵,到底是谁的问题。DeepFlow 就像一个裁判,谈笑间回答了这里面的玄机。从图中我们能看到,靠近客户端的位置虽然 OpenTelemetry Span 的时延大,但 eBPF Span 时延明显降低了,云原生环境不再是一个黑盒,看的一清二楚。我相信大家此时应该也能感受到满满的团队协作感,再也不用争吵了。

DeepFlow 基于开源的全栈全链路可观测性建设实践
无盲点追踪

我们的在线文档[7]中也对这个 Demo 进行了详细介绍,欢迎上手体验。另一方面,我们的 AutoTagging 能力也适用于追踪数据,我们会为所有的 Span 自动注入了大量标签。我们不再需要配置过多的 otel-collector processor 用于标签注入了,一切都是自动的、高性能的、环保的。

在线文档:https://deepflow.yunshan.net/docs/zh/agent-integration/tracing/opentelemetry/#%E6%9F%A5%E7%9C%8B%E8%BF%BD%E8%B8%AA%E6%95%B0%E6%8D%AE

现在,回过头来看看我们是怎样解决追踪盲点的。左下角的传统追踪方式就像战斗机的火控雷达一样,精准打击、定点打击,依靠开发插码可发现进程内部的函数调用链。右下角的 eBPF 就像预警机的预警雷达一样,自动追踪,全方位覆盖。现代战争已经无法离开预警机了。DeepFlow 将战斗机与预警机结合,实现了无盲点的追踪覆盖,从自动化到精细化,从首战告捷到节节胜利,激活了团队之间的协同能力。

DeepFlow 基于开源的全栈全链路可观测性建设实践
火控雷达 + 预警雷达

04

赋能 NewOps

最后,我想聊一聊 NewOps,运维团队如何打造一个产品,一步步为开发团队提供可观测性建设手段。

目前,已经有不少开源用户基于 DeepFlow 在开始建设全栈全链路的可观测性服务。DeepFlow 的内核平台是开源的,我们基于开源内核构建了企业版的所有协作功能,并基于标准 SQL API 为 Grafana、SkyWalking 等平台提供数据,使得社区可以基于开源内核,在不改变团队现有使用习惯的基础上快速构建完整的可观测性。这里我们来分享几个落地场景。第一个是运维团队基于 DeepFlow 向开发团队提供更丰富的 Grafana Dashboard,展示所有微服务的应用和网络性能、服务调用关系。

DeepFlow 基于开源的全栈全链路可观测性建设实践
DeepFlow + Grafana

第二个是运维团队基于 DeepFlow 向开发团队提供更精细的 SkyWalking 追踪图,点击每一个 Span,可以精细的看到从进程到Sidecar、Pod 网卡、K8s Node 网卡等全栈链路,以一个裁判员的视角帮助开发快速定位问题位置。

DeepFlow 基于开源的全栈全链路可观测性建设实践
DeepFlow + SkyWalking

刚才我所说的 NewOps,源自 2018 年 Tyler Treat 的一次演讲 —— The Future of Ops[8]。运维团队的职责在云原生是时代悄悄的发生着变化。

以往的主要职责是保证业务稳定性;微服务的普及使得运维和开发的摩擦增大,DevOps 的理念逐渐普及,希望开发能做一部分运维的工作,希望促进开发和运维团队之间的协同;当业务上云以后,运维团队发现基础设施都变成了托管服务,很多运维职责不再需要了;但云原生环境的复杂性再一次让开发团队面临了困难,他们精通业务开发,但通常不懂得系统架构、基础设施,遇到问题时无法自己完全解决。

这个时候,运维团队需要升级,从以往提供人力服务的角度,转变为基于云基础设施开发一系列产品,提供给业务团队自服务,可观测性平台就是这些产品中的一个核心部分。

The Future of Ops:https://www.youtube.com/watch?v=JUy3GYkPfto

那么,开源的 DeepFlow,作为一个高度自动化的可观测性协作平台,是我们希望带给运维人转型的一个礼物,它让观测更自动,让开发者更自由,让运维团队从打造产品的思路,从自动化到精细化,从首战告捷到节节胜利,构建组织的可观测性平台。相信讲到这里,大家应该能相信可观测性建设的革命到来了,那么现在期待大家拿起你的手机,挂上 VPN,给我们的 GitHub 一个 Star,大家的认可是我们前进的动力。期待大家的使用反馈、Issue、Pull Request!

05

什么是 DeepFlow

DeepFlow 是一款开源的高度自动化的可观测性平台,是为云原生应用开发者建设可观测性能力而量身打造的全栈、全链路、高性能数据引擎。DeepFlow 使用 eBPF、WASM、OpenTelemetry 等新技术,创新的实现了 AutoTracing、AutoMetrics、AutoTagging、SmartEncoding 等核心机制,帮助开发者提升埋点插码的自动化水平,降低可观测性平台的运维复杂度。利用 DeepFlow 的可编程能力和开放接口,开发者可以快速将其融入到自己的可观测性技术栈中。

GitHub 地址:https://github.com/deepflowys/deepflow

参考资料

[1]

PPT 下载: http://yunshan-guangzhou.oss-cn-beijing.aliyuncs.com/yunshan-ticket/pdf/ea0e4b6ebd97dda7b399f0197997358f_20220826140446.pdf

[2]

我们还需要 SRE 吗?: https://zhuanlan.zhihu.com/p/554118190

[3]

DeepFlow 在线文档: https://deepflow.yunshan.net/docs/zh/agent-integration/metrics/prometheus/

[4]

Online Demo: https://deepflow.yunshan.net/docs/zh/install/overview/

[5]

在线文档: https://deepflow.yunshan.net/docs/zh/auto-tracing/istio-bookinfo-demo/#%E6%9F%A5%E7%9C%8B%E5%88%86%E5%B8%83%E5%BC%8F%E8%BF%BD%E8%B8%AA

[6]

DeepFlow 在线文档: https://deepflow.yunshan.net/docs/zh/agent-integration/tracing/opentelemetry/

[7]

在线文档: https://deepflow.yunshan.net/docs/zh/agent-integration/tracing/opentelemetry/#%E6%9F%A5%E7%9C%8B%E8%BF%BD%E8%B8%AA%E6%95%B0%E6%8D%AE

[8]

The Future of Ops: https://www.youtube.com/watch?v=JUy3GYkPfto


加入DeepFlow开源社区
体验高度自动化的可观测性新时代




官网链接

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


GitHub 地址

https://github.com/deepflowys/deepflow


访问 DeepFlow 文档

https://deepflow.yunshan.net/docs/about/overview/


往期推荐:





DeepFlow AutoLogging:自动采集应用调用日志和流日志


DeepFlow 加入阿里云数据存储生态计划 携手共建云原生可观测性


DeepFlow v6.1.1重大更新 应用性能监控能力极大增强 开源社区同步发布


关于 DeepFlow


DeepFlow 是云杉网络开源的一款高度自动化的可观测性平台,是为云原生应用开发者建设可观测性能力而量身打造的全栈、全链路、高性能数据引擎。DeepFlow 使用 eBPF、WASM、OpenTelemetry 等新技术,创新的实现了 AutoTracing、AutoMetrics、AutoTagging、SmartEncoding 等核心机制,帮助开发者提升埋点插码的自动化水平,降低可观测性平台的运维复杂度。利用 DeepFlow 的可编程能力和开放接口,开发者可以快速将其融入到自己的可观测性技术栈中。


DeepFlow 企业版自2016年起已在中国移动、中国联通、中国电信、国家电网、招商银行、民生银行、光大银行、中国人保财险、平安科技、兴业数金、国泰君安、海通证券、上汽集团、深航货运、东方明珠、中保信等超过50家企业级数据中心落地部署,帮助客户构建多维度、一体化的可观测性平台。




DeepFlow 基于开源的全栈全链路可观测性建设实践


 点击【阅读原文】阅读完整版博客 

原文始发于微信公众号(高效运维):DeepFlow 基于开源的全栈全链路可观测性建设实践

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年9月8日11:00:18
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   DeepFlow 基于开源的全栈全链路可观测性建设实践http://cn-sec.com/archives/1285726.html

发表评论

匿名网友 填写信息