01、开箱即用 Dashboard
DeepFlow 在此之前提供的 Application 系列 Dashboard，主要用于观测 RED（请求、错误、时延）黄金指标的历史变化、服务之间的调用关系、服务的请求日志详情。此类 Grafana Dashboard 的缺点是不同 Panel 之间的联动分析能力较弱，需要较多的手动操作。因此社区在此基础上针对初次体验、业务变更等使用场景，提供了一个新的开箱即用 Dashboard。
过滤条件区域
通过【过滤条件】过滤需要分析的服务。
- server：需要分析服务（作为服务端）
- endpoint：端点，端点的提取方式参考应用协议字段映射文档
- l7_protocol：应用协议，对应 HTTP、RPC、SQL、MQ、DNS 等应用协议
- signal_source：信号源，目前支持进行区分的三种信号源为 Packet (cBPF)、eBPF、OTel
- eBPF：使用 eBPF 零侵扰采集的函数调用数据，Dashboard 默认查看的是 eBPF 信号源。如果你的操作系统内核不支持 eBPF，可手动切换到 Packet 查看数据
- Packet：使用 AF_PACKET + cBPF 零侵扰采集的网卡流量数据
- OTel：使用 OTLP 协议集成的分布式追踪数据
端点列表区域
通过【端点列表】分析服务 API 的 RED 指标。
端点列表可查看服务端服务 (auto_service_1)、端点 (endpoint)、应用协议 (l7_protocol) 对应的请求速率、响应异常、响应时延指标量。表格支持的操作如下：
- 点击指标量的表头可进行排序，快速过滤出异常比例高或响应时延大的服务端点
- 点击表格某一行，将打开一个新页面，展示点击行对应的服务端服务 + 端点 + 应用协议的端点详情
端点详情区域
通过【端点详情】观测 API endpoint 对应的 RED 指标变化趋势、API 调用详情、调用链追踪信息。
指标折线图
- 请求速率：查看 server + endpoint + l7_protcol 变量对应的请求速率变化趋势，图例由 <math xmlns="http://www.w3.org/1998/Math/MathML"> 服务端服务 服务端服务 </math>服务端服务 应用协议 $ 端点组成。
- 响应时延：查看 server + endpoint + l7_protcol 变量对应的响应时延变化趋势，其中包含 P90 响应时延及 P99 响应时延两个指标量，图例由 <math xmlns="http://www.w3.org/1998/Math/MathML"> 服务端服务 服务端服务 </math>服务端服务 应用协议 <math xmlns="http://www.w3.org/1998/Math/MathML"> 端点 − 端点- </math>端点− 指标量名称组成。
- 异常比例：查看 server + endpoint + l7_protcol 变量对应的异常比例变化趋势，其中包含客户端异常比例及服务端异常比例两个指标量，图例由 <math xmlns="http://www.w3.org/1998/Math/MathML"> 服务端服务 服务端服务 </math>服务端服务 应用协议 <math xmlns="http://www.w3.org/1998/Math/MathML"> 端点 − 端点- </math>端点− 指标量名称组成。
- 超时总数：查看 server + endpoint + l7_protcol 变量对应的超时变化趋势，图例由 <math xmlns="http://www.w3.org/1998/Math/MathML"> 服务端服务 服务端服务 </math>服务端服务 应用协议 $ 端点组成。
调用列表
查看 server + endpoint + l7_protcol 变量对应的调用详情列表，可查看客户端服务、响应码、响应异常描述等等信息。表格支持的操作如下：
- 点击响应状态表头漏斗 ICON，支持根据响应状态过滤数据
- 点击响应时延表头，支持按指标量进行排序
- 点击表格中的某一行，可对当前调用进行追踪，结果可在调用链追踪对应的火焰图中查看
调用链追踪
当点击「调用列表」中的一行时，调用链追踪区域即可以火焰图形式展示链路，对于火焰图的使用可参考 DeepFlow 帮助文档中的调用链追踪说明。
02、Dashboard 用法举例
以下使用一个 Demo 演示如何利用开箱即用 Dashboard 在分钟级排查应用问题。
Step 1：过滤 foo-svc 服务，通过端点列表发现 /error 接口服务端异常比例高达 100%。
Step 2：点击端点列表 /error 行，通过新 Tab 查看端点详情，通过异常比例曲线发现一直存在异常 ，通过调用列表发现都是 demo-ingress-nginx-ingress 访问 foo.example.com/error 链接时，foo-svc 返回了 500 异常。
Step 3：点击调用列表中 500 异常的行，对异常调用发起追踪，通过调用链追踪火焰图可知整个调用由 loadgenerator-ng 服务通过 curl 发起的调用，调用经过了 demo-ingress-nginx-ingress，然后转发到了 foo-svc，最后 foo-svc 的 java 进程返回了 500 异常。
至此，我们仅查看一个 Dashboard、只需两三步操作，即完成了一次故障定界 。这些能力都是你在一键安装完 DeepFlow 的五分钟后就能立即获取的，真·开箱即用的应用可观测性。
03、对研发效能提升的意义
研发效能及 DevOps 领域最具影响力的调查机构 DORA（DevOps Research and Assessments）为 DevOps 成熟度设定了四个指标，其中前两个最重要的指标分别为 **Change lead time（代码从提交到上线的时间）**和 Deployment frequency（发布频率） 。在 DORA 2023 年的报告中，DevOps 精英级（Elite）对这两项指标的要求分别为 **Less than one day（小于一天）**和 On-demand（随时）。
为了提升这两个指标，可累坏了研发兄弟们：每次想要做 API 变更、代码删减之前都如临大敌，痛苦的向各方确认业务依赖，生怕有所遗漏；每次发布过程中的 On-call 也会时常碰到调用链不全、指标不够的痛苦 。为了解决这些问题，以往你会被迫使用 APM，但迎来的现实却是插桩永远覆盖不全、Agent 和 SDK 永远要升级，升级又要 On-call。久而久之你会进入被迫使用 APM 和讨厌 APM 的死循环。
DeepFlow 基于 eBPF 的零侵扰可观测性有望改变这一现状，显然我们的社区用户也发现了这点。但受限于 Grafana 的关联分析能力，新上手的用户容易迷失在我们内置的大量 Dashboard 之内。在过去几个月，我们收到了好几个社区用户的使用建议，于是便有了这个非常简洁的「开箱即用」 Dashboard，让你在一键安装 DeepFlow 的五分钟之后，打开这个 Dashboard 就能以上帝视角查看应用性能和稳定性隐患，也能让你在以后的每次变更之前轻松确认业务依赖，同样能让你在灰度升级过程中快速观测新版本的健康状况。而获得这些能力不需要修改任何一行代码，也不需要重启任何一个进程。
这个 Dashboard 已经在腾讯IEG、中国移动磐基等社区用户处有了很不错的实践，从 DeepFlow 首次安装时的 DAY 0 初体验，到每一次业务的上新、扩容、缩容，已经在 DevOps 的各个流程环节开始帮助开发兄弟们消除性能和稳定性上的隐患，避免了未来可能触发的故障，我们将会在后续文章中介绍他们的使用案例。
现在就开始尝试 eBPF 的零侵扰可观测性，相信你会距离精英级 DevOps 前进一大步 ！另一个好消息是 DeepFlow 6.4 已经支持了 RedHat/CentOS 3.10 内核上的 eBPF 能力，Enjoy！
04、什么是 DeepFlow
DeepFlow 是云杉网络开发的一款可观测性产品，旨在为复杂的云基础设施及云原生应用提供深度可观测性。DeepFlow 基于 eBPF 实现了应用性能指标、分布式追踪、持续性能剖析等观测信号的零侵扰（Zero Code）采集，并结合智能标签（SmartEncoding）技术实现了所有观测信号的全栈（Full Stack）关联和高效存取。使用 DeepFlow，可以让云原生应用自动具有深度可观测性，从而消除开发者不断插桩的沉重负担，并为 DevOps/SRE 团队提供从代码到基础设施的监控及诊断能力。