Debezium日常分享系列之：使用Debezium检测数据变异模式

在当今动态的数据环境中，检测和理解数据变异模式对于系统的可靠性至关重要。在本博文中，我们将探讨如何在微服务架构中使用Debezium进行全面的数据库活动记录和分析。我们将深入探讨Debezium如何捕获行级别的变化并实时流式传输，从而实现对数据库操作的即时可见性。通过与分析工具集成，我们将了解如何构建详细的活动仪表板，揭示每个表的操作数量和性质。这些洞察力对于识别意外模式非常宝贵，例如由于带有错误的新微服务部署而导致插入操作突然减少。您将学习如何设置Debezium，为特定的使用案例进行配置，并利用生成的数据创建可操作的仪表板。

概念和背后的理念

近年来，由于微服务、容器化应用程序和云环境等架构的日益复杂，可观察性已成为现代系统的重要组成部分。

以下是可观察性在当今至关重要的一些重要原因：

• 更快的故障排除和事件响应
  • 可观察性提供了对系统行为的深入洞察，通过关联日志、指标和跟踪，帮助团队快速识别和解决问题，减少停机时间并缩短响应时间。
• 主动问题检测
  • 可观察性通过实时识别异常和模式实现主动监控，使团队能够在潜在问题影响用户之前解决它们。

应用程序通常会公开不同类型的指标，以提供对其行为、性能和整体健康状况的洞察。这些指标可分为几种主要类型：

• 基础设施指标
  • 这些指标跟踪底层基础设施的资源使用情况，例如：CPU 使用率、内存使用率、磁盘 I/O、网络 I/O。
• 应用程序性能指标
  • 这些指标衡量应用程序的运行性能，以确保应用程序以最佳方式运行并满足用户期望。例如：请求率、错误率、延迟、吞吐量。
• 业务指标
  • 这些指标侧重于应用程序对业务目标的影响，例如：交易数量、转化率、收入、用户注册。

通常，基础架构和应用程序指标相当“标准”，并且有框架/工具可轻松用于指示您的应用程序公开这些指标。另一方面，业务指标在应用程序之间可能有所不同，因此您每次都需要实现自定义代码来公开这些指标。

这个想法是从较低的层次思考，并利用变更数据捕获 (CDC) 来提取可用作业务指标的数据。

假设我们有一个订单服务，用于处理和存储客户的订单。要监控的一个重要业务指标是订单数量。这个数字与业务非常相关，因为它与公司的收益直接相关。订单数量的相应下降应尽快提醒负责该服务的团队。

通常，我们需要一个计数器指标，每次正确下订单并将其存储在数据库中时，该指标都会递增。但是，如果我们可以通过 CDC 监控数据库来提取这些信息呢？

让我们探索 Debezium 如何提供这种可能性。

Debezium 如何公开指标

Debezium 公开三类指标：

• 快照指标
  • 提供有关执行快照时连接器操作的信息，例如 RowsScanned、RemainingTableCount、TotalTableCount。
• 流式传输指标
  • 提供有关连接器读取数据库日志时连接器操作的信息，例如 TotalNumberOfCreateEventsSeen、QueueRemainingCapacity、QueueTotalCapacity。
• 架构历史指标
  • 提供有关连接器架构历史状态的信息，例如 ChangesApplied、ChangesRecovered、Status。

所有这些指标均通过 JMX 公开。您可以在我们的文档中内容。

数据库活动指标

从 3.0.0.Final 版本（具体为 3.0.0.Beta1）开始，引入了以下新的流式传输指标：

• NumberOfCreateEventsSeen计算每个表的创建事件数。
• NumberOfDeleteEventsSeen计算每个表的删除事件数。
• NumberOfUpdateEventsSeen计算每个表的更新事件数。
• NumberOfTruncateEventsSeen计算每个表的截断事件数。

由于这些指标是实验性的，因此您需要通过将 internal.advanced.metrics.enable 属性设置为 true 来选择启用它们。

演示：订单服务监控仪表板

使用 Debezium 公开这些指标后，您可以轻松创建带有警报的仪表板，以监控可能影响您业务的任何重大变化。我们将使用自己的 PostgreSQL 数据库、Kafka Connect 运行时上的 Debezium PostgreSQL 连接器以及 Prometheus 和 Grafana 作为我们的可观察性平台来设置我们的订单服务。

对于此演示，您需要克隆 Debezium 示例存储库中的代码并转到 db-activity-monitoring 目录。

组件概览

订单服务

订单服务是一个 Quarkus 应用程序，默认情况下，每 10 秒存储 100 个订单，或每秒约 10 个订单的速率。您可以通过将 application.properties 中的 app.version 属性设置为 1.0 以外的任何值来模拟不良部署。这将强制应用程序以标准速率的一半执行订单插入。

该应用程序还公开了 application.info 指标，其常数值为 1.0，但带有两个标签：版本和名称。我们将使用此指标在图表上放置一个标签，以指示已部署服务的版本。

JMX 导出器配置

我们看到 Debezium 将指标作为 JMX bean 公开，因此通常可以使用 JMX 导出器将这些指标公开给 Prometheus。在 debezium-jmx-exporter 中，config.yml 文件包含其配置。最重要的是以下模式

- pattern: "debezium.([^:]+)<type=connector-metrics, context=([^,]+), server=([^,]+), key=([^>]+)><>NumberOfCreateEventsSeen"name: "debezium_metrics_create_events_count"labels:plugin: "$1"context: "$2"name: "$3"table: "$4"type: "COUNTER"

假设 MBean 的名称是 debezium.postgres<type=connector-metrics, context=streaming, server=monitoring, key=inventory.orders><>NumberOfCreateEventsSeen，上述规则只是创建以下指标：

# TYPE debezium_metrics_create_events_count_total counter
debezium_metrics_create_events_count{context="streaming",name="monitoring",plugin="postgres",table="inventory.orders",} 100.0

组件启动

之后，您就可以按照以下步骤开始演示了：

构建我们的订单服务。

order-service/mvnw package -f order-service/pom.xml

运行我们的撰写文件来启动所需的一切。

export DEBEZIUM_VERSION=3.0.0.Final
docker-compose up -d --build

当所有服务都启动并运行时我们可以注册我们的连接器

curl -i -X POST -H "Accept:application/json" -H  "Content-Type:application/json" http://localhost:8083/connectors/ -d @postgres-activity-monitoring.json

访问仪表板

打开 Web 浏览器并转到 Grafana UI http://localhost:3000。以用户 admin 和密码 admin 身份登录控制台。当系统询问时，请更改密码或跳过此步骤。

然后，为了监控订单服务活动，我们创建了常规/微服务活动监控仪表板。

几分钟后，您应该会看到订单率约为每秒 10。

为了模拟下降，我们可以将 APP_VERSION 环境更新为不同于 1.0 的值。

docker stop order-service
docker rm -f order-service && \
docker compose run -d -e APP_VERSION=1.1 --name order-service order-service

一段时间后，您将看到服务将开始创建订单，订单量下降约 50%（见图 1）。

由于我们还配置了当订单率低于 7 时触发的警报，因此您也可以在警报面板中检查它是否触发。

但这还不是全部，我们还配置了邮件通知，您可以通过访问 http://localhost:8085 上的 Fake SMTP UI 进行检查。

结论

我们已经了解了变更数据捕获 (CDC) 如何从数据库中提取见解，以作为微服务可靠性和可观察性的关键绩效指标 (KPI)。这种方法使我们能够避免修改我们的服务来公开这些指标，而是依靠 Debezium 进行数据收集。

虽然并非所有业务指标都可以从数据库操作中得出，但很大一部分可以。