使用 DeepFlow 开启 MySQL 可观测性

基于 Prometheus mysqldexporter 的 MySQL 监控方案大家都很熟悉，Grafana 也推出了相关的 MySQL Dashboard 来监控 MySQL 服务的状态。但是 Prometheus 的方案具有较强的侵入性，需要配置专用账号访问数据库，从 MySQL 上获取需要监控的指标数据，这对权限管控严格的运维团队来说无疑不是一个友好的选择。同时，Prometheus 获取的数据限于 MySQL 服务本身，依然解答不了谁的请求有异常、谁的访问超时了等问题。

意识到这些不足之后，我们基于 DeepFlow 构建了一个高效、可配置、无侵入的 MySQL 监控面板，可监控 MySQL 服务的网络时延、吞吐、异常，以及 SQL 性能问题，以快速定位性能瓶颈和排查故障原因。部署了 DeepFlow 之后，deepflow-agent 会自动采集所在节点上的可观测数据，我们基于这些数据构建了一个 Dashboard，内容包括：

• Overview
• Connections
• Delay
• Error
• Throughput
• SQL Analysis

前往我们的在线 Demo 也可快速体验 Dashboard。

0x0: Dashboard 介绍

进入 Dashboard ，我们配置了如下变量，分别对应不同部署方案下的数据库服务：

variables

在 K8s 上部署的数据库服务，可用 cluster 和 db_service 变量组合，切换到目标数据库，其中，db_service 变量假定了数据库服务的 workload 名字包含 sql 字样，使用者可根据实际情况修改变量值，我们下个版本也会支持在 Dashboard 上通过变量配置服务名，以更方便地使用这个 Dashboard：

cluster

db_service

在云服务器上部署的数据库服务，可用 db_chost 变量切换到目标数据库：

db_chost

使用云数据库，可用 db_ip 变量通过 IP 切换到目标数据库，并且支持输入网段：

db_ip

在右侧，我们用 统计位置 可查看不同视角下的监控信息，比如我们的默认值 tap_side = 客户端网卡，我们看到的就是在客户端处采集到的对外连接数据库的监控情况。

tap_side

最后，我们有个 client_for_SQL_Analysis 变量，它仅对 SQL_Analysis 面板生效，可用于快速分析具体某个应用的业务情况。

client_for_SQL_Analysis

0x1: Dashboard 使用

接下来，我们根据 Dashboard 的面板设计，来完整体验一次定位 MySQL 网络请求、故障定位及业务分析的全过程。

当我们接收到前方报障数据库异常，打开 Dashboard，我们会首先查看服务的总览：

Overview：左侧包含总请求量、客户端概况、以及服务端、客户端的异常总数、异常比例。通过右侧的拓扑图，可快速查看正在访问数据库服务的所有请求来源，右下角我们可以看到网络时延的分布。通过这个 Dashboard，我们快速了解到数据库拓扑概况、当前请求量、是否有异常发生、是否有过高的网络时延出现。

Overview

对服务的现状有个大概的把握之后，接下来，我们再来看看数据库的活动连接：

Connection：我们提供两个视角来看活动连接的概况。第一个是服务视角：从服务侧看，我们发现服务侧的活动连接数始终在30以下，随着业务发生而波动，这说明进行连接的客户端在完成业务查询后快速断开，没有持有长时间的会话。

server_side_connection

第二个是客户端视角：从客户端分组看，我们发现保持连接的客户端中，大部分客户端都保持了平稳的连接。

client_side_connection

通过以上这个面板，我们知道了过去一段时间内客户端活跃连接的情况，我们认为服务保持的活跃连接是可控的，处于一个比较平稳的状态，那连接本身是否正常呢？我们结合以下面板继续分析：

Delay：查看时延，从服务接收请求的 P90/P95/P99 三个指标来看，有99%的请求时延保持在 1.2ms 以下，说明每个连接的响应时延在可控范围内，再根据客户端分组，我们快速定位到哪个客户端的平均时延较高。

Delay

Error：查看错误和异常，我们分别查看请求是否有服务端异常和客户端异常，通过客户端分组，查看错误发生在哪个客户端应用里，并且，我们还找到了发生超时的客户端应用。

Error

结合以上的数个面板分析，我们知道了异常信息以及异常来源，我们发现请求本身没有异常，但是偶有超时发生，我们继续排查，是否因为请求返回了大量数据，导致有超时发生：

Throughput：查看服务吞吐量，我们通过数据的吞吐速率、以及与客户端交互的请求中，筛查交互吞吐量最高的客户端应用。

Throughput

结合错误、时延、吞吐来分析，我们发现了吞吐高、时延高的应用，可能就是本次故障发生的原因。然后，我们使用 *deepflow-server* 作为查询变量，输入到 client_for_SQL_Analysis 变量中，分析一下这个应用的 SQL：

client_for_SQL_Analysis

SQL Analysis：我们查看这个应用发出的 SQL 请求，得到查询请求、DML语句请求的时序图，从而知道了过去一段时间内，业务请求是平稳的，SQL 查询时延集中在 1ms 以内，但有部分 SQL 查询在 4ms 以上。

SQL Analysis Left

从 SQL Delay 时序图来看，部分 SQL 查询的时延甚至达到了 15+ms。结合右侧的 SQL 分析 ，我们也定位到了时延高的 SQL 以及没有限制返回数、设计不合理的 SQL，部分 SQL 的查询结果明显不在我们预期之内。

SQL Analysis Full

最后，我们还可以通过 Distributed Tracing，对时延大于 10ms 的 SQL 发起追踪，看看时间到底耗费在网络层还是应用层。

Distributed Tracing

至此，我们从网络请求、时延、错误及异常、吞吐量以及最后的 SQL 分析，完整地完成了一次 MySQL 故障定位，我们知道了哪个应用有异常、有什么异常、甚至具体到哪个业务发生了异常。得益于 DeepFlow 的 AutoTracing、AutoMetrics、AutoLogging、AutoTagging 核心机制，我们可以从应用角度快速分析 MySQL 服务的调用拓扑、性能指标、访问日志、调用链追踪。 而且在全过程中，我们没有访问过一次数据库，对进行中的业务没有任何影响。

0x2: 后续规划

我们目前在制作一批 Dashboard，包括：Nginx、MySQL/PostgreSQL、HTTP、Dubbo/gRPC、Kafka/MQTT、TCP/UDP/IP、DNS 等，希望能带来社区高度自动化、高精度的可观测性体验，期待有社区的小伙伴能加入一起。

0x3: 什么是 DeepFlow

DeepFlow 是云杉网络开发的一款可观测性产品，旨在为复杂的云基础设施及云原生应用提供深度可观测性。DeepFlow 基于 eBPF 实现了应用性能指标、分布式追踪、持续性能剖析等观测信号的零侵扰（Zero Code）采集，并结合智能标签（SmartEncoding）技术实现了所有观测信号的全栈（Full Stack）关联和高效存取。使用 DeepFlow，可以让云原生应用自动具有深度可观测性，从而消除开发者不断插桩的沉重负担，并为 DevOps/SRE 团队提供从代码到基础设施的监控及诊断能力。

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

访问 DeepFlow Demo，体验高度自动化的可观测性新时代。