“云原生可观测性分享会”第四期《星火燎原-DeepFlow漫谈之技术、场景、方案》由云杉网络 售前经理 冀佳鹏演讲，分享了可观测性系统建设技术发展的探讨，畅聊在运营商、边缘网络、车联网、金融云数据中心等场景下的端到端运维体系的构建。下文为直播实录，接下来请大家开启沉浸式阅读模式吧。
大家好，我是云杉网络华东区技术经理冀佳鹏，这是我们举办的第四期云原生可观测性分享会，今天由我来和大家一起聊一聊可观测性，以及DeepFlow的行业应用和技术方案的实践。
1）可观测性的经典定义
讲到可观测性，绕不开的还是要聊一聊可观测性的经典定义，通过外部的数据观测，了解系统内部的运行情况并能够进行问题诊断。它包括的内容有Metrics、Tracing、Logging，我们通常叫做可观测性的三大支柱，当然这样的定义也在进行不同层次的延展。
从单个应用的可观测性，延展到整个业务系统，然后随着分布式业务、微服务的发展和覆盖范围的扩大，我们又需要面向混合云的可观测性。从内容层面上也在进行一些延展，但是Metrics、Tracing、Logging这样的总结和定义，在行业、社区、从业人员里还是非常广泛和经典的。
因为它们把可观测性要解决的问题描述清楚了，Metrics是面向聚合的指标数据、Tracing面向的是请求链接追踪，Logging更多是面向单次事件的记录。刚提到的一些定义的延展，其实也没有跳脱出这样经典的三类定义。
那么这三类数据的交集实际上就是蕴含着不同数据之间关联的能力。在构建可观测性系统的时候，首先我们肯定无法忽略任何一个模块，然后更重要的一点就是去实现这三类数据之间的关联。我们也可以看到在社区和商业板块中有众多的这样的监控类工具，比如以Metrics为主的像Grafana、Prometheus、Zabbix这样的监控工具；以Tracing为主的Skywalking、Jaeger、Opentracing追踪类或者叫APM的工具；还有以Logging为主的ELK、Splunk这一类的日志监控工具。
其实不管是开源、还是商用，我们也能够发现他们都在努力去做自身模块的数据和另外两类数据之间的关联和追踪。比如说Zabbix他们应该是在6.0版本也会加入应用链路追踪的能力；比如Skywalking在新版本的预告中也能看到eBPF技术的引入，另外包括很多其他的商用或者开源的监控产品，也在实践把本身的能力来开放出来，或者说是按照一个统一的关联标准去开放，提供可供其他工具关联的能力。所以我们在可观测系统建设过程中如果能去参考一套统一的标准或者方法的话，就会更加有利于整个可观测性生态上的融合。
2）关于Telemetry
刚刚讲到对于数据采集、关联和开放的标准和方法性的问题，其实社区和整个生态中已经有了一个比较好的解决方案就是OpenTelemetry，在他的官方介绍中帮助我们解释了是什么和不是什么。
OpenTelemetry是一组标准和工具的集合，旨在管理观测类数据，如Trace、Metrics、Logs等，这里明确提出了未来可能有新的观测类数据类型出现。另外OpenTelemetry不提供与可观测性相关的后端服务，这类后端服务通常提供的是存储、查询、可视化等服务。
OT在2021年的时候完成了Tracing、Metrics的设计规范，今年应该也会去解决Logging的一个关联规范和标准的问题。这是一个高速发展中的项目，得到了业界大量的关注和认可。他山之石，可以攻玉。我们可以借助这样标准思路上的指导。比如OpenTelemetry利用Context提供上下文统一的关联标准，使得我们不同的观测类数据里面能够轻松自如的关联和追踪。在整个排障过程中效率也会更高。
另外我们聊一下怎么去看待Telemetry这样的遥测数据，我们能看到很多设备厂商（华为、华三、锐捷）会提供基于设备芯片计算处理能力的遥测监控数据的输出，可以发现Telemetry关键能力为预置于前端的指标计算和标准化传输。当然也可以根据自身的监控数据内容的不同，定义成张三Telemetry、李四Telemetry都可以，但是需要去思考：自己是否真的具备前端的指标计算和标准化传输能力。
3）DeepFlow流量数据包处理（BPF）
在云资源池中，DeepFlow采集器恰好是这样Telemetry技术的一个经典体现，预置于前端的指标计算和标准化传输能力。软件的流量采集器部署在宿主机操作系统及容器Node上，通过内核态的数据包捕获技术抓取到交互数据包，然后在采集点上就会进行一系列的指标计算和关联，最后再标准输出。
这里有几个优势：1、不依赖任何软件库，2、不需要Sidecar，不需要虚拟交换机做任何镜像配置。所输出的数据包括网络性能监控指标的Metrics数据；网络会话的网络流日志Logging数据；网络链路上的网络路径的追踪数据。并且我们积极和国内主流的云厂商进行了兼容性的认证合作。
4）eBPF能力+
前期阶段，我们以网络性能为主的Telemetry数据的基础上，也在努力做应用性能分析数据的追踪和关联，比如和Skywalking和一些其他的商用APM做过关联和追踪，通过TraceID、SpanID 形成在云数据中心里面，能够关联起来的端到端的数据关联和追踪。
关于云内网络路径，在全链路的网络路径上包含了很多的中间网络节点或者网元，比如容器内部的各类Bridge、CNI，虚拟化层的OVS、VSS、VDS等，根据不同的通信场景里面经过不同的NAT网关、或者SLB的7层或者4层的负载均衡，相对于物理网络来讲是更加抽象、复杂的。每一次的应用请求，比如使用APM做代码追踪，追踪到出了应用，然后到这些复杂的中间链路上的性能切片的问题，我们DeepFlow都能解决。
但是在这个追踪关联的过程中，不管是从网络到应用、还是从应用到网络，经常出现断点的是应用性能分析这部分，可能是由于不同开发语言支持不同环境去插码和打桩的难度等，导致的各种原因。所以当在应用到网络里追踪一个比较小的业务范围内是很顺畅的，但是一个大型的分布式业务追踪的时候就会遇到各种各样的问题。
于是我们在DeepFlow6.0以上版本中引入了eBPF技术，丰富在应用性能监控部分的数据源，主要包括：在进行性能追踪的时候能够追踪到系统函数、到应用函数、方法级别的调用关系；能够提取出来业务层面的一些索引信息，比如交易ID、车机ID、终端ID的索引traceID。
做到网络链路上的网络性能数据的分析，加上eBPF的应用监控维度的数据源补充，从云资源池、分布式业务、应用里面拿到真正原生的、内生的全链路的监控数据。
这样做的好处对于用户来说做到了业务代码零修改、业务进程零重启、编程语言无感知，能够获取全量的网络+系统+应用的指标信息及任意服务的访问请求日志，实现在整个云数据中心场景下网络+应用全栈全链路追踪。
5）DeepFlow全链路监控实现
我们可以整体看数据中心可观测性的常见的技术图谱和他们所在的位置。这里是一个经典的云数据中心结构，这里的关键元素有移动端、车载端的请求接入，有防火墙内的物理网络链路及网络设备，有云资源池内部的计算资源（虚拟机、容器）以及相关的NFV的网络功能区域，还有云平台提供的PAAS层服务。
当业务请求进来以后，我们可以清晰的看到不同的工具在不同的位置上解决不同的观测性需求。比如客户端性能分析、网络拨测、物理网络流量分析、网络设备Telemetry数据分析、再到Zabbix提供的SNMP的资源层面的监控，Prometheus容器资源层面的监控，应用性能维度上的Skywalking听云这样的APM监控，在这个真实的业务请求全链路的地图里面，可以清晰的看到DeepFlow主要可以补全云数据中心内部的复杂的网络链路追踪，以及网络及应用性能指标数据、请求会话的流日志数据的输出。
当然也给我们一个启示：没有任何一个工具可以解决所有的问题，而能够解决全部问题的方法只有不同工具、产品之间的开放、兼容和关联。借此机会给大家插播一个信息，我们正在将这部分的相关技术开源，开源的项目叫做MetaFlow，大家感兴趣可以关注下一场直播，5月11日，产品VP向博士会为大家带来关于MetaFlow的最新消息及技术分享。
在数据中心内部的地图里面，看到了整个业务请求链路上所有的技术栈，打造的端到端的分析场景。现在再提升一个维度，从全局的场景地图中，来看DeepFlow主要的应用场景。
从资源池内部，我们构建出从业务、应用函数代码调用到容器POD、容器Bridge、虚拟机、宿主机、逻辑网元、PaaS层服务的全链路，从数据中心区域南北向物理网络链路上进行分光和镜像，netflow/sflow等方式将物理网络和虚拟网络进行一体化的分析和关联。如果要绘制更大的全景图，数据中心外面，比如分支机构、灾备数据中心也可以纳入到监控范围内。
再看运营商的5G核心网监控，这里5G核心网负责信令传输的网元，已经全部是微服的架构；在公有云侧，我们通过DeepFlow Cloud的SaaS平台来为公有云内部的应用进行性能分析和业务保障；车联网场景中，我们通过车机端部署Rust语言开发的探针，在边缘云节点、中心云、公有云节点上部署相应的流量采集器，实现云、边、端这一体化分析方案。
1）企业-多地数据中心混合云可观测平台
接下来就来逐个看在不同行业场景下的应用实践。之前很多客户问过我，“你们为什么能做到多数据中心，混合云架构下的一体化视图呈现？”这里借一个我们大型企业客户的案例场景给大家详细解答：这个客户的数据中心建设很具有代表意义，他们有几个分布于不同城市的数据中心，每个数据中心又包含了腾讯云、华为云、VMware等，异构的云资源池，还有一部分互联网应用的业务在公有云上，以及在一些重点的城市也有分支机构。
在这样的一个丰富的云数据中心场景下，我们帮助客户建设了一套全局的混合云可观测平台，这里有三个重点：1、策略控制；2、数据分布存储；3、集中展示。
2）证券（基金）-混合云大型分布式业务网络监控
目前还有很多证券、基金等客户的云基础设施建设中，发现一个共同特点——小步快跑，几乎每一个证券行业的客户处都存在三个或者三个以上的资源池类型，每个资源池规模不大，一二百个节点，比较常见的有EasyStack、腾讯云、阿里云、青云、包括一些超融合资源池SmartX、路坦力等。
他们都利用DeepFlow采集器探针实现了数据采集层面的几大能力：流量数据包的采集和计算、eBPF数据源补充、云数据中心内部的实时拨测能力，能够进行原始流量数据包共享的流量分发能力。从业务层面针对部署在异构资源池的分布式业务进行全局的性能保障，这里主要的业务包含核心交易类、互联网类、综合支撑类。
另外我们和一些运行管理类的工具或平台也进行开放和共享，比如提供开放的数据API，实时数仓的消息队列给智能运维分析平台、数据治理平台，使得它们能够调用全网的性能指标数据；另外是和云管平台进行一系列的联动，按照租户的维度将租户内资源和业务的监控视图赋能到租户所在的云平台上进行使用等等。
3）运营商-端到端分析场景
接下来聊聊运营商行业，在前一段时间，移动集团也定义出一套新的适用于云资源池，端到端性能分析的指导和要求，给了我们很多的启发。从端到端采集层，我们看到有数据中心内部和外部拨测、APM、日志、网络这四大方面的采集技术栈。在端到端的运维能力和场景中，包括横向端到端、纵向端到端、全局端到端这三类，横向端到端覆盖了从IaaS层到PaaS层到SaaS层的运维监控能力和场景，纵向端到端是从业务到系统再到租户，基于不同视角的调用拓扑的展示和调用链路的追踪。最后实现的则是全局端到端，全景业务可视化的终极目标。
现在看来这样的定义确实很科学，全方位的阐述了我们落地一个端到端运维体系的时候，需要有全面考量的要求。这个分析场景，恰好和DeepFlow端到端分析思路和方法完美的契合。接下来我们会把思路和方法带给我们其他的行业客户，希望能给其他行业带来端到端功能的落地实践。
4）运营商-5G核心网网元监控
在之前的3G、4G时代，一般是通过DPI设备来进行CT网络的流量采集分析，从而保障信令网络传输的性能情况，在5G核心网中有非常复杂的网元模块之间的服务调用，比如AMF、UDM网元模块，运行在华为云、VMware虚拟化层之上的容器层的微服务中，导致传统的监控手段在5GC的环境中很难奏效。
我们通过全栈的流量采集：第一自动分析5G核心网的网元之间调用关系；第二拆解复杂的全链路网络路径，最后，快速判断出5GC环境中的异常、时延的问题点。
5）运营商-算力网络关键度量平台
最近运营商有一件非常重要的大事，就是算力网络。有一点点类似于现在各个云厂商在努力做的分布式云，利用云网融合技术以及SDN／NFV等新型网络技术，将边缘计算节点、云计算节点以及含广域网在内的各类网络资源、社会算力深度融合在一起，通过集中控制或者分布式调度方法，来为企业客户提供灵活的可调度的包含计算、存储和网络的整体算力服务。
在这样大规模分布式云的智能调度中，需要我们来提供相应的网络运力、算力、存力相关的监控调度数据作为支撑，通过DeepFlow绘制整个动态的，能够进行数据辅助决策的算网地图。当然也包含有对于企业客户重点应用的全局性能保障和监控分析。
6）公有云-服务互联网客户的SaaS平台
我们在去年公开提供DeepFlowSaaS试用版，叫做DeepFlowCloud，为互联网客户提供应用保障和性能分析的能力。其实这个在国内来讲是一个比较创新的做法，公有云上的业务运维人员极少会有机会，或者有这样的手段通过数据包分析解析计算业务和应用相关的性能指标，所以当得知有这样一个对业务无侵扰、细粒度的监控方案的时候，还是非常的感兴趣的，我们也认为这样的手段和方法绝对能够去帮助互联网客户解决很多之前的困难，比如像代码插码改造、服务路径梳理等监控层面上的瓶颈。
从部署的角度来看，即使是万级容器节点规模，通过 yaml 配置文件，也能实现分钟级采集器部署上线，完全云原生规模化部署安装，另外同样具备和其他的已建设的监控工具和平台，数据的关联和对接。
对DeepFlowCloud
感兴趣的朋友可以扫描二维码体验
7）车联网-云、网、边、端的一体化监控手段
以下是车联网的行业场景，在车联网云-边-端的可观测性方案中主要覆盖三个场景，包括车对人，车对车，车对物联网。IT架构涉及到车端、互联网以及中心云、边缘云，相互之存在访问通信，除了有移动APP，娱乐等IT类应用外，还会涉及到IoT类的通信（车辆状态信息的上传、控制指令的下发）。通信的路径包括4G/5G、卫星通信、专线、云内网络等。
面对这样一个场景，在DeepFlow的方案中，除了要在主站的中心云、边缘云部署采集器以外，最重要的是要将采集器部署到车载主机上，在车端处也能够实现数据的获取和调用追踪。当然在车载端会对采集器提出更高的要求，包括极小的资源消耗，采集器的稳定性、安全性的要求，以及对自身的监控的能力要求等等。
现在我们车载端的采集器已经能够做到通过200MHz的CPU和256M的内存，来实现一整台车上的系统应用的指标数据采集和计算，以及IoT（主要是MQTT）协议、HTTP协议的解析分析。车辆网的这个场景其实后续也可以推广到其他IoT物理网，或者工业互联网场景，是我们后续考量的一个重要的应用场景。
最后我再利用一点时间，给大家简单看看我们在具体的客户处一些实践的视图，这里就先当做是抛砖引玉，因为接下来，后面几期的分享会有其他在项目一线的同事，给大家分享更加精彩、有意思的实践案例。
某新型车企云原生应用监控：可观测性平台
在可观测性平台的落地和建设中，一些互联网行业，或者偏互联网行业的客户，他们发展的更早，而且走的也更远一点，这是一个新能源车企的客户，是一个微服务环境，我们做了一些重点的容器业务集群的覆盖（当然这个规模每天都在增长）。
客户Tacing/Logging的相关平台的建设已经初具规模，使用Skywalking做应用性能的分析；使用Elasticsearch做日志分析；使用Zabbix做告警出口。客户引入DeepFlow作为网络及应用监控Metrics数据的补充。这里非常关键的一步就是需要和已经建设的Skywalking、Elasticsearch进行关联分析。另外他们使用的、全部的工具类产品中只有我们是商用产品，某种意义上也是一种认可。时间有限，先讲到这里，欢迎大家保持关注。
关注微信
