Debezium日常分享系列之:使用Debezium检测数据变异模式
Debezium日常分享系列之:使用Debezium检测数据变异模式
- 概念和背后的理念
- Debezium 如何公开指标
- 数据库活动指标
- 演示:订单服务监控仪表板
- 组件概览
- 订单服务
- JMX 导出器配置
- 组件启动
- 访问仪表板
- 结论
在当今动态的数据环境中,检测和理解数据变异模式对于系统的可靠性至关重要。在本博文中,我们将探讨如何在微服务架构中使用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 进行数据收集。
虽然并非所有业务指标都可以从数据库操作中得出,但很大一部分可以。