Nightingale 集成 Canal 监控基于 Categraf Prometheus 采集的 MySQL binlog 全流程实践【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale导读本文围绕 Nightingale 仓库内置的 Canal 集成包integrations/Canal展开完整讲解如何让 Canal Server 通过 Prometheus 格式端点暴露自身指标、如何用 Categraf 的input.prometheus插件采集并打上可区分的标签、以及如何借助仓库自带的 Canal instances 仪表盘查看 binlog 解析 TPS、延迟、Client 吞吐与 Store 内存水位。读完本文你将掌握一套可复制、可排障的 Canal 监控接入方案并理解为什么不能随意覆盖destination、instance这两个标签。监控链路总览Canal 是阿里巴巴开源的 MySQL binlog 增量订阅与消费组件运行时会持续解析主库 binlog 并向下游 Client 推送格式化事件。要观测它的运行健康度监控链路分三段MySQL binlog │ dump/parse ▼ Canal Server ──(HTTP /metrics, 默认 11112)──► Categraf input.prometheus │ interval15 拉取 ▼ Prometheus 兼容时序库Nightingale │ ▼ Canal instances 内置仪表盘 / 告警规则Canal Server 本身就提供 Prometheus 格式的指标端点官方默认端口11112因此无需额外安装 exporter——这正是本项目集成包选择“直接用 Categraf 的 Prometheus input 采集”的原因integrations/Canal/markdown/README.md 开篇即明确了这一思路。在 Nightingale 仓库中integrations/目录是各组件 Categraf 采集配置与指标命名的“事实来源”ground truthaiagent/tools/integrations_loader.go 的注释明确写道每个组件的markdown/README.md和collect/*/*.toml会被转成文档条目并入索引LLM 通过search_n9e_docs检索时能直接搜到真实的[[instances]]写法而 center/integration/init.go 则会在中心端启动时读取每个组件的markdown/README.md作为内置组件说明读取dashboards/下的 JSON 作为内置仪表盘模板。也就是说本文下面要用的配置与仪表盘都是随仓库发布的、可直接落地的标准做法。Canal Server 端配置打开指标拉取端口Canal 的指标端口由canal.properties中的canal.metrics.pull.port控制官方示例默认值为11112。确认配置文件中已启用该端口canal.metrics.pull.port11112修改配置后需重启 Canal Server 使其生效。启动完成后先确认端点能正常返回指标避免把“Canal 未暴露指标”误判成“采集端配置错误”。使用 curl 验证并筛选canal_instance前缀的指标curl -fsS http://127.0.0.1:11112/metrics | grep canal_instance | head-ffail fast on HTTP error、-s静默、-S出错时显示错误信息三个参数组合保证只有 HTTP 状态码为 2xx 且输出非空时命令才成功退出。如果这里无输出或报错请先排查 Canal 是否真正开启了指标拉取端口例如端口被占用、canal.metrics.pull.port未生效等而不是直接去改采集端。Categraf 端配置input.prometheus 采集确认 Canal 端点正常后在 Categraf 的conf/input.prometheus/目录下新建canal.tomlinterval 15 [[instances]] urls [http://127.0.0.1:11112/metrics] url_label_key canal_server url_label_value {{.Host}} labels { job canal }逐项说明配置项取值作用interval15秒全局/插件级采集周期即每 15 秒从 Canal 拉取一次/metricsurls[http://127.0.0.1:11112/metrics]要抓取的 Prometheus 端点列表多个 Canal Server 可写成多个 URLurl_label_keycanal_server为每条时序追加的标签名用于区分不同的 Canal 目标url_label_value{{.Host}}标签值模板{{.Host}}会被替换为 URL 的主机部分不含端口labels{ job canal }额外静态标签统一标记数据来源为 canal便于检索与过滤参考同目录下 integrations/N9E/markdown/README.md 的 N9E 自监控配置可以看到同一模式url_label_key/url_label_value组合用于把“来自哪台主机/哪个实例”写进标签labels用于声明 job。多台 Canal Server 需要全部列入urls并通过url_label_value的模板变量保证每台机器都有可区分的标识。注意N9E 示例用instance作为 URL 标签键而 Canal 示例刻意用canal_server——因为 Canal 原始指标里已经带有instance标签表示 destination 的实例Categraf 侧再用instance会与之冲突详见下一节。为什么不能覆盖destination和instance标签这是本集成包中最重要的一条约束integrations/Canal/markdown/README.md 特别强调不要覆盖 Canal 原始指标中的destination和instance标签仪表盘变量依赖这些标签。Canal 暴露的指标本身带有丰富的维度标签destinationCanal 的订阅目标名对应canal.properties中配置的 destination一个 Canal Server 可同时跑多个 destinationinstancedestination 对应的实例标识此外还有parser、parallel、packetType、le等维度分别标识解析器序号、并行模式、Client 包类型和直方图桶。内置仪表盘正是靠这些标签做聚合和变量联动下一节会看到所有面板的表达式都带destination~$destination如果在 Categraf 侧用labels强行覆盖destination或instance会导致仪表盘顶部的destination变量查不到值变量定义是label_values(canal_instance, destination)多个 destination 的曲线被混在一起无法区分packetType、parser等原本用于分组的标签维度被破坏部分面板如 Client requests、并行解析器拆分失去意义。因此labels里只应放job这类“不冲突”的自定义标签采集目标的标识交给url_label_key/url_label_value。内置仪表盘深度解析canal_by_categraf.json集成包自带一个名为Canal instances的仪表盘模板定义在 integrations/Canal/dashboards/canal_by_categraf.json数据源类型为prometheus。它只有一个查询型变量destination定义为label_values(canal_instance, destination)即从canal_instance系列的所有destination标签值动态生成下拉选项所有面板再通过destination~$destination与之联动。这就是上一节“禁止覆盖destination标签”的根源。仪表盘按四个分组组织从上到下依次为Instance status实例状态、Throughput吞吐、Client客户端、Store存储各组面板与核心 PromQL 如下。Instance status实例基本信息面板说明核心表达式节选BasicCanal instance 基本信息canal_instance{destination~$destination}、canal_instance_parser_mode并行解析器、canal_instance_store批量模式 batchMode、缓冲区大小 sizeNetwork bandwidth网络带宽占用inbound 为读取 MySQL binlogoutbound 为向 Client 传输格式化 binlograte(canal_instance_received_binlog_bytes{parser0}[2m]) / 1024、rate(canal_instance_client_bytes[2m]) / 1024parser1/2分别展示并行解析器各序号的分量Delay延时master 为 Canal Server 相对 MySQL master 的延时master heartbeat 机制可在 idle 状态下刷新延时put/get/ack 分别以 store put、client get、client ack 操作的时间点为基准canal_instance_traffic_delay / 1000、canal_instance_put_delay / 1000、canal_instance_get_delay / 1000、canal_instance_ack_delay / 1000除以 1000 将原始值换算为秒级展示Blockingsink 线程 blocking 占比dump 线程 blocking 占比仅 parallel modeclamp_max(rate(canal_instance_publish_blocking_time{parser0}[2m]), 1000) / 10、clamp_max(rate(canal_instance_sink_blocking_time[2m]), 1000) / 10Throughput吞吐面板说明核心表达式TPS(table rows)以 master 变更行数table rows为基准计算的 binlog 处理 TPS区分 put/get/ack 三类操作rate(canal_instance_put_rows[2m])、rate(canal_instance_get_rows[2m])、rate(canal_instance_ack_rows[2m])TPS(MySQL transaction)以 MySQL transaction 为单位的 binlog 处理 TPSrate(canal_instance_transactions[2m])这两个面板一个看行级吞吐、一个看事务级吞吐配合使用能判断 Canal 的解析压力落在哪一层。Client客户端消费情况面板说明核心表达式Client requestsCanal instance 接收到的请求统计按 packet type 分类canal_instance_client_packets图例{{packetType}}Client QPSclient 请求的 GET 与 ACK 包 QPSrate(canal_instance_client_packets{packetTypeGET}[2m])、rate(canal_instance_client_packets{packetTypeCLIENTACK}[2m])Empty packetsserver 响应 GET 请求但返回空包的占比rate(canal_instance_client_empty_batches[2m])对比rate(canal_instance_client_packets{packetTypeGET}[2m])Response timeCanal client 请求响应时间概况直方图rate(canal_instance_client_request_latency_bucket[2m])图例{{le}}msGET/ACK 的 QPS 直接反映下游 Client 的消费节奏Empty packets 占比过高通常意味着 binlog 消费跟不上或下游长时间不拉取。Store内存队列水位Canal 使用内存 ringbufferstore在解析线程与 Client 之间缓冲事件水位过高往往预示下游消费阻塞面板说明核心表达式Store remain eventsringbuffer 内未释放的 events 数量canal_instance_store_produce_seq - canal_instance_store_consume_seqStore remain memringbuffer 内未释放 events 占用的内存KB(canal_instance_store_produce_mem - canal_instance_store_consume_mem) / 1024两个面板都用“生产序号/内存 − 消费序号/内存”的差值刻画积压量是判断 Client 是否阻塞的最直接指标。各面板的中文描述词条可以在 integrations/Canal/i18n/en_US.json 中查到对应英文便于在 Nightingale 界面切换语言时对照理解。常见问题与排障场景一TPS、延迟和 Client 面板为空只启动了 Canal Server、但没有创建 destination或没有 binlog 读写流量时TPS、延迟和 Client 面板为空是正常现象不是采集故障。原因在于这些指标由 destination 的解析线程parse/sink产生没有 destination 就没有对应序列没有 binlog 读写rate(...)对计数器求导的结果为 0 或不产生新样本曲线自然不出现。正确做法是先确认 Canal 侧确实有 destination 且主库有写入流量再检查面板。而Instance status 和 Store 分组的面板基于canal_instance等基础序列只要 Server 起来了通常就有数据可用来反向确认采集链路是否打通。场景二destination变量下拉为空检查是否在 Categraf 的labels或url_label_key里使用了destination或instance作为标签名把原始标签覆盖掉了。按本文第三节的配置url_label_key canal_server、labels { job canal }即可规避。场景三curl 验证通过但仪表盘无数据链路排查顺序curl确认 Canal 端点 → 确认 Categraf 采集间隔interval与拉取日志无报错 → 在 Nightingale 时序库中按canal_instance检索是否存在数据 → 检查仪表盘datasource变量选中的是否是对应的 Prometheus 数据源。数据到达时序库后可直接复用本集成包仪表盘模板在 Nightingale 内置组件中搜索 Canal 导入。总结Canal 集成是 Nightingale 生态中“零 exporter、纯 Prometheus 拉取”的典型代表Canal 端只需打开canal.metrics.pull.portCategraf 端只需一份十几行的input.prometheus配置即可把 binlog 解析的 TPS、四类延时、Client 消费 QPS、Store 积压水位等关键指标汇入 Nightingale配合随包发布的 Canal instances 仪表盘开箱即用。整个过程的配置模板与仪表盘定义都沉淀在 integrations/Canal 目录中既是实操参考也是 AI 检索链路aiagent/tools/integrations_loader.go中的配置权威来源——记住“不覆盖destination/instance标签”这一条红线就能稳定复现这套方案。【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考