DeepFlow AutoLogging：自动采集应用调用日志和流日志 原创 精华

第九期“原力释放 云原生可观测性分享会”云杉网络 产品专家 李倩分享了 DeepFlow AutoLogging功能，可以自动采集网络流日志，并提供丰富的性能指标和精细至每包的TCP时序日志，与应用调用日志结合提供完整的全栈回溯能力。

b站回看地址：https://www.bilibili.com/video/BV1Z14y147XM/?vd_source=8217e32e9012f691b56ca71735c1a472

大家好，我是云杉网络DeepFlow的产品经理李倩，今天给大家带来的主题是 《DeepFlow AutoLogging：自动采集应用调用日志和流日志》。

今天的内容其实是云杉网络“云原生可观测性分享会”的直播里面，第八期也就是上一期的一个延续，第八期我们的研发VP向阳给大家带来了🔗DeepFlow首个开源版本的分享，其中主要和大家详细聊了AutoMetrics 和 AutoTracing的能力，对于可观测领域三大支柱的的Logging，在这次直播中来给大家详细讲解。

今天从三个方面给大家进行分享：

第一： 分享应用调用日志，从数据来源、数据抽象到数据使用三个角度和大家谈谈，如何自动采集的HTTP/MySQL等多协议调用日志；

第二： 分享网络流日志，主要对比公有云的流日志及流日志的应用场景；

第三： 讲解 AutoLogging 的实现，基于BPF/eBPF的自动日志采集能力。

01 | 应用调用日志-数据来源

首先强调下，应用调用日志与与应用在代码层面打的日志是不一样，例如Nginx的AccessLog，MySQL的General Log/Error Log这些都是调用日志的范畴。

但是这些日志都是单个组件的日志，并不是应用的调用日志，对于应用问题的排查，需要挨个去找组件的负责人看日志，但组件负责人不懂业务，不知道如何快速搜索日志，导致了问题的排查过程中协作成本巨高。

应用的调用日志是给Dev团队建设的，一个站在应用视角快速查看所有的调用详情信息的能力，其实这个能力获取可以将目前现有的组件日志都集中起来查看也是一种思路，但是如何以应用无感知/自动化的形式低成本的接入，以及更符合云原生的这个理念来实现的话，这是目前市面上没有的，这是DeepFlow的AutoLogging的价值点所在。

DeepFlow的调用日志，其实由各种各样的应用协议组成的，目前DeepFlow平台上已经包含了例如网络应用的HTTP的访问日志、DNS的查询日志、SQL/NoSQL的操作日志、RPC的调用日志、MQ的API调用日志，也会包含可观测领域中Tracing的数据，例如OpenTelmetry协议的Span调用，还会陆续支持一些物联网的协议，例如MQTT的日志。

02 | 应用调用日志-数据抽象

数据的来源刚刚大家也看到了，非常的丰富，随着市场的需求和版本的迭代，将会有更多协议的数据接入进来。如果需更好的使用这些‘五花八门’的数据，需要对数据进行治理，治理的第一步，对数据进行统一的抽象，数据抽象将从公共字段、请求字段、响应字段、指标量，这四个层面来展开：

公共字段

包含应用协议、协议版本、日志类型，其中日志类型包含请求/响应/会话类型，一般协议都是这三种，也会有一些协议有些例外，例如OpenTelemetry协议，仅一个会话类型。

请求字段

整体抽象为请求类型、请求域名、请求资源、请求ID，例如HTTP的方法，MySQL的命令类型，DNS的查询类型都为请求类型，HTTP的host对应请求域名，HTTP的Url、MySQL的命令、DNS的查询名称都对应请求资源，这个请求资源的抽象是参考各个APM的厂商的定义，例如Datadog的Resource，Skywalking的Endpoint。

响应字段

分为响应状态、响应码、响应异常、结果，整体来说基本都是对应响应码映射的。

指标量

分为吞吐请求长度、响应长度的字段，以及响应时延字段，结合指标量可以更好的分析调用。

03 | 应用调用日志-自定义属性

数据抽象的收益是统一管理，可弊端也在统一。在设计之初，其实就考虑了要做自定义属性的扩展，随着OpenTemetry的Tracing数据接入，这个事情就变的更加重要。

因此除了定义的标准字段外，又定义了Attribute_Names和Attribute_Values这两个数组，数组里面可以携带自定义属性和自定义属性对应的值，这个是根据不同的需求来携带，没有长度和格式的限制，非常的灵活。

两个数组里面的 Key 和 Value 按顺序来进行映射，在产品化的时候，通过Qurey组件进行转化，用户是无感知数组的存在的，看到的都是Key，Value这样的属性关系，通过Key查询来获取Value，这个和使用其他Tag查询的逻辑也是一致的。

04 | 应用调用日志-AutoTagging

刚刚分析的是各种协议如何映射为调用日志，站在应用的视角已经可以统一查看调用日志了。

而如何快速过滤应用呢？这也是一个必须解决的问题，在传统架构中，一般会根据IP段或者根据所在服务器来过滤，但是应用架构逐步迁移到云上，开始使用微服务架构后，IP已经不再稳定，而资源也不在简单是服务器了，这种时候如何来快速过滤应用呢？

DeepFlow的AutoTagging能力，可以给调用日志打上各种云厂商的标签，比如租户、区域、子网、云服务器、RDS、负载均衡器、NAT网关、K8s的命名空间、容器服务、工作负载、动态Label等等，有了这些标签，则可以快速的根据各种云标签过滤应用，然后查看应用的调用日志了。

以上主要和大家分享了应用调用日志背后数据处理的一些理论能力，接下来带大家感受下基于这样的能力，应用调用日志激发的实际价值。

05 | 应用调用日志-总览

这是基于调用日志构建的一张Grafana的Dashboard，这个Dashboard主要可查看服务的调用关系、RED指标量。Dashboard就是基于前面数据抽象来实现的。

我们可以通过AutoTagging打上的标签，Dashboard主要使用K8s相关的标签，快速过滤应用，比如DeepFlow这个应用，就直接过滤Namespace=DeepFlow就可以了。然后结合Grafana的一些阈值能力，就可以快速的在视觉找到需要关注的服务，从而缩小问题定位的范围。

06 | 应用调用日志-HTTP访问日志

接下来看看如何查看HTTP的调用日志以及DeepFlow平台的调用日志与AccessLog的差异。

左边是在Grafana上构建的应用调用日志的Dashboard，可根据TAG过滤应用，根据Protocol过滤HTTP、HTTPS、HTTP2协议，即可查看当前服务的HTTP的调用日志。

右边是将AccessLog与DeepFlow的应用调用日志做的一个映射，通过对比，可看出来除了remote_user其他都能映射的非常好。

HTTP访问日志除了作为代替AccessLog，还可以结合调用日志的状态和指标量，快速知道哪些调用存在异常，哪些调用响应慢。

07 | 应用调用日志-MySQL慢查询日志

对于MySQL慢查询的日志，在云上数据库实例化后，想看数据库的日志，其实并不容易，需要在云上开启各种设置和权限，及时看到了日志，也比较难快速的去过滤对应的应用日志。

我们来看看DeepFlow是如何查看慢查询日志的，这个是刚刚HTTP调用日志一样的Dashboard，仅需要切换下搜索条件即可，将协议切换为MySQL，request_type输入为COM_QUREY，以及request_resource为SELECT*。

设置好这样的过滤条件，得到的就是MySQL的查询日志，接着再对响应时延排序过滤，就可以找到慢查询了。

08 | 应用调用日志-分布式追踪Span日志

除了看网络应用协议的调用日志外，通过前面的数据来源我们也知道，调用日志也支持接入分布式追踪协议的Span信息。

目前DeepFlow已经支持对接OpenTelemtry的Span信息，每个Span其实都对应着一个调用，当前展示的就是Opentelemtry的一个Span日志。

接入Span的信息后，除了可以看日志，根据状态、指标量来定位调用问题外，还有一个重要的目的，就是还可以基于目前DeepFlow平台已有的网络中采集的调用和通过eBPF采集的调用，进行全栈全链路的追踪。

09 | 应用调用日志-全栈全链路追踪

这就是一个最终追踪出来的火焰图，这个火焰图上不仅包含应用代码层面的调用，也包含了系统层面、网络层面，针对如何追踪这个事，由于时间问题，今天就不展开细说，我会利用后续的直播继续给大家详细的去分享，如何对应用进行全栈全链路的追踪。

应用调用日志，仅能观测到应用层面的一些问题，DeepFlow可以通过FlowID将应用调用背后的网络流日志关联起来。接下来分享网络流日志能有什么样的能力。

10 | 网络流日志-功能定义

先看下公有云对网络流日志的功能说明，这是阿里云的一个定义，是捕获特定位置的流量，将流量转化为流日志记录下来，流日志是什么呢？流日志是记录捕获特定时间窗口的特定五元组的网络流。

所以对于基础功能的定义，DeepFlow是有遵循公有云的定义的，并在此基础上还有更丰富的能力。

11 | 网络流日志-DeepFlow与公有云对比

接下来看看DeepFlow流日志与公有云流日志的对比，我来解读一下其中的一些差异点。

先看看捕获周期，DeepFlow的粒度能小到1分钟，同时捕获位置DeepFlow也更丰富，除了VPC网络，也会覆盖到容器网络、物理网络、也能从网络层面扩展到系统层面。

接着看看TAG，配合DeepFlow的AutoTagging的能力，DeepFlow流日志的TAG是远比公有云更丰富的，除了VPC网络的一些Tag，还包含隧道的Tag、容器网络，以及更丰富的采集位置Tag。

接着指标量，公有云仅有Packet/Byte这两个，DeepFlow则覆盖了从网络吞吐到性能，再到时延多个维度。

在DeepFlow的流日志中，增加了流状态字段，可通过此字段快速过滤异常的流，这是目前公有云上不支持的。当然公有云支持的日志状态字段和安全策略的状态，DeepFlow目前不支持，不过此功能也已经加入到排期中了。

最后，再看一个很重要的事情，从计费上看，公有云目前是计费的，按采集流量大小和存储空间来收费，DeepFlow开源及SaaS版本都具备此能力，开源大家都知道免费的，SaaS版本目前也是免费试用阶段。

好，分析了这么多功能对比，下面我们来看下DeepFlow网络流日志功能，具体能解决什么问题。

12 | 网络流日志-总览

这是基于网络流日志构建的Granafa的Dashboard，是可以和应用调用日志一样，查看服务的调用关系，但是和应用调用日志不一样的是，这个总览的Dashboard查看的是网络层面的指标量，比如吞吐、重传、建连失败、建连时延等指标数据。

13 | 网络流日志-网络时延

查看应用调用日志时，经常会关注响应时延慢的调用，可这个响应慢，除了应用本身响应慢以外，还可能是TCP建连慢，也有可能是数据传输，也可能是协议栈慢，对于网络相关时延的排查，需要查看应用调用对应的流日志来分析。

首先应用调用日志和网络流日志是如何关联的，DeepFlow平台上是通过一个FlowID来将两个日志进行关联，因此可以根据调用日志的FlowID，在流日志中进行查找，找到这条调用对应的流日志，然后分析流日志中的建连时延、系统时延和数据传输时延指标量，排查网络时延高导致了应用调用响应慢。

14 | 网络流日志-流状态异常日志

应用调用日志是可以根据状态查看异常日志，流日志也是一样，可以对状态进行过滤查看异常的流日志，因此这个时候就能去看看调用异常背后是否因为网络异常导致。

右上角给出来了DeepFlow流日志里面的状态定义，主要对流结束类型来进行定义，比如建连时延，因为端口复用可关闭，比如传输过程中，服务端发送RST报文导致的结束。

15 | 网络流日志-TCP时序日志

接下来继续深入的结合TCP时序日志，分析具体的包的时延和问题。特别说明下：TCP时序日志目前是DeepFlow企业版的增强功能了，现在开源的版本里面是没有的。

用一个简单的Demo，讲解开源的调用日志和流日志功能。这是我们给开源社区搭建的一个Demo环境，这个Demo环境是基于Grafana来构建的，已经构建了很多应用和网络相关的Dashboard。

点击前往原文观看

16 | AutoLogging-采集

接下来从日志采集和日志处理两个方面给大家介绍，AutoLogging是如何基于BPF/eBPF来自动采集日志的。

首先我们来看看采集部分，采集部需分别从调用日志和流日志两个方面来看。

流日志

流日志通过前面产品介绍可知，是根据网络流量来生成的日志，因此采集则主要集中在网络层面，目前可覆盖物理网络一直到虚拟网络，可以采集宿主机到虚拟机、一直到容器POD的网卡的流量，在实现上流日志通过BPF + AF_PACKET技术来完成，其中Windows系统的采集则通过使用Winpcap来完实现的。

调用日志

调用日志的数据包含两部分数据，一部分是从网络应用协议来的，还有一部分是可观测的Tracing数据。

对于网络应用协议这部分的数据，调用日志既包含了网络层面采集的，也扩展到了Sidecar和应用进程层面，对于网络层面采集的位置和实现技术与流日志是一致，只是处理逻辑会有一些不一样；而对于Sidecar和应用进程层面，则是使用eBPF技术来实现的，其中对于非加密和非压缩的协议，则通过eBPF的Kprobe和Tracepoints来完成，而对于HTTP2、HTTPS则需要使用Uprobe来完成。

对于Opentelemetry的数据接入，是通过Otel-Collector将Traces的数据发送给deepflow-agent，就完成了Tracing的数据接入。采集的部分先分享到这里，接下来我们看看采集完成后，会进行些什么样的处理。

17 | AutoLogging-处理

对于日志的处理，分为三个部分：公共处理部分、流日志处理、调用日志处理。

对于网络流量的处理可分为：隧道拆解，其中对于隧道拆解，基本主流的隧道协议，都已经支持，比如Vxlan，IPIP，Gre等等。隧道拆解完成后，则会按协议栈的顺序依次解析协议，从链路层一直到传输层。

接着需要对于流量进行AutoTagging的预处理，这里主要加上唯一的Tag，方便后面Server根据唯一Tag增加全量Tag。到这步，对于不同的日志需要分开处理了，对于网络流日志，此时可以根据产品定义去生成流日志。

对应用调用日志，还需要完成应用协议识别，确定具体协议后，再进行应用协议解析，最后才能根据定义生成调用日志。

对于应用调用日志，除了刚刚分享的这个处理流程，还有另外一条路径，主要是因为应用调用日志不仅包含网络应用协议，还包含APM定义的Tracing数据，对于这部分数据，可以直接接入，接入后直接解析即可。

18 | 应用调用日志-协议扩展

好，处理这部分也到这，接下来额外说下扩展一个应用协议。前面一直在说应用调用日志支持接入各种各样的协议，这里大概分享下协议接入需要做一些什么事情。

第一部分：需要解析协议；

第二部分：协议解析完成后，需要将协议映射到调用日志中；

第三部分：除了调用日志外，DeepFlow还提供预聚合数据的能力，对应用RED指标进行计算。

协议扩展要做的事情就是这些，目前DeepFlow已经开源，也欢迎开源社区的小伙伴们来贡献更多的协议，让应用调用日志更丰富。

今天的分享主要侧重在框架的讲解，并不涉及太多代码细节，如果大家对实现细节感兴趣的话，可以直接查看GitHub上的代码，下方是DeepFlow GitHub的链接。

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

19 | 未来迭代的方向

最后总结一下未来DeepFlow日志的一个迭代方向。

目前DeepFlow在Logging方向上，有AutoLogging的能力，后面还会持续做日志集成，会接入Promtail、Fluentd等等的数据，并利用AutoTagging的能力，注入各种标签，更符合云原生的这样一个设计理念。我今天分享的内容就结束了，可以通过以下方式接入DeepFlow，谢谢大家。

加入DeepFlow开源社区

体验高度自动化的可观测性新时代

官网链接
https://deepflow.yunshan.net/community.html

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

访问 DeepFlow 文档
https://deepflow.yunshan.net/docs/about/overview/