背景

DataX是一个异构数据源离线同步工具,致力于实现包括关系型数据库(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、FTP等各种异构数据源之间稳定高效的数据同步功能。解决异构数据源同步问题,DataX将复杂的网状的同步链路变成了星型数据链路,DataX作为中间传输载体负责连接各种数据源。当需要接入一个新的数据源的时候,只需要将此数据源对接到DataX,便能跟已有的数据源做到无缝数据同步。

datax测量组件比较弱,datax Communication组件负责测量采集和计算,但相比专业的时序数据库,如,Prometheus,功能和性能相差甚远,因此需要集成如Prometheus这样的平台,加强监控能力

参考和术语

metrics-exporter设计 url

测量(metrics)  透视系统内部状态,通常以数字展现,也可以文字,如,系统开和关

  1. datax原理介绍

Datadog 监控 datax 监控_Datadog 监控

 *官方图,Transport处是Channel,本人觉得不太准确,应为Transport

> 作业分解为任务,任务分组,最后调度器调度任务(组)

*作业分片和任务分组没有在高可用中

> 调度器负责分派资源执行任务(组),TaskEecutor执行任务

> transport包括数据交换(exchanger),数据转换(transformer),交换数据字节数/记录数的统计(channel)

测量组件介绍

测量组件可观测平台的一部分,由metrics,exporter,reporter 3部分组成

  • metrics负责测量收集/计算,业界metrics组件选择比较少,主要有dropwizard-metrics,micrometer也是源于dropwizard-metrics,还有些框架自带metrics组件,基本上也是参考dropwizard-metrics
  • exporter/reporter,两者是配套,exporter 转换本地测量类型为目标监控平台类型;reporter 推送转换后的测量到监控平台,本组件实现Prometheus测量转换和报告

Datadog 监控 datax 监控_数据源_02

 Counter/Gauge/Meter/Summary/Histogram  dropwizard-metrics支持的测量类型,其中后3者属于统计量;另外,Prometheus Counter/Gauge都是数值,Gauge可加可减,Counter单调增加

ScheduledReporter/DefaultScheduledReporter  ScheduledReporter是dropwizard-metric提供的Reporter实现,定时报告测量,抽象模板模式,DefaultScheduledReporter本组件的ScheduledReporter实现,使用DropWizardPrometheusExporter转换测量为Prometheus对应类型,继而使用simple-pushgateway推送到Prometheus

TagExtractor  tag是Prometheus测量的属性,定义数据维度,对后续的统计非常重要;TagExtractor是本组件接口,应用实现自己的tag生成逻辑

MetricHolder 本组件开发的类,负责全局构建,操作,持有测量

metrics组件详细设计说明可参看:微服务可观测平台(三)-测量组件设计与实现

datax集成测量组件

测量组件有了,接下来解决两个问题,初始化和metrics收集

初始化

datax没有集成spring/spring boot,初始化更多地自行写代码实现,幸好spring boot可以比较容易修改成手动调用的配置类

Datadog 监控 datax 监控_Datadog 监控_03

 metrics以作业维度,很容易想到初始化的地方就是在JobContianer,在该类增加initMetrics,该方法主要是实例metrics报告器,metrics组件支持3类reporter,nop/console/schedule

相应地,core.json增加配置

Datadog 监控 datax 监控_java_04

url是PushGateway地址,metrics组件推送metrics到Prometheus 的push gateway,再由Prometheus server采集

metrics收集

datax使用Communication收集和计算监控测量,以任务为单位,合并统计到任务组,再统计到作业粒度

测量采集主要在channel,采集量有字节数,数据数,读/写等待时间,类型均为counter,计算衍生速率测量,数据数/秒和字节数/秒等

通过以上分析,我们的metrics组件只要channel采集即可,1m/5m/15m速率计算在Prometheus完成

Datadog 监控 datax 监控_数据源_05

 读写等待时间,datax是累计counter,需要改为增量

Datadog 监控 datax 监控_等待时间_06

 统计分别在channel的入口和出口

metrics tag机制

Prometheus使用tag作为统计维度,在datax,作业job id作为Prometheus的job,还需要分组(数据/字节/读写等待时间),类型(成功/成功)

组件提供了TagExtrator类,tag抓取器,支持用户自定义标签

Datadog 监控 datax 监控_等待时间_07

 metricsName 格式 group.tag….,实现分析metricsName,抓取标签

Prometheus dashboard

接下来配置Prometheus仪表盘

Datadog 监控 datax 监控_java_08

  • 读写数据速率,按record计算读写速率,1m/5m
  • 读写字节速率,按byte计算读写速率,1m/5m
  • 读写数据/字节成功总数,总数
  • 读写等待时间

下面是metrics promSQL配置

Datadog 监控 datax 监控_Datadog 监控_09

Datadog 监控 datax 监控_Datadog 监控_10

 

Datadog 监控 datax 监控_java_11

 效果

测试场景 mysql同步到neo4j

mysql使用示例数据库sakila,neo4j使用官方的沙箱

Datadog 监控 datax 监控_Datadog 监控_12

 同步到neo4j,只同步节点数据,共40811行

Datadog 监控 datax 监控_初始化_13

 总图

Datadog 监控 datax 监控_等待时间_14

 读写数据总数

Datadog 监控 datax 监控_java_15

 读写字节速率

Datadog 监控 datax 监控_初始化_16

 datax任务summary,可以作为对比

Datadog 监控 datax 监控_Datadog 监控_17

 总数,读写速率一致

neo4j总数与同步后不一致,这个是图库同步的逻辑有关,不是同步漏了数据,大家知道是什么原因?

代码

代码包包括metrics-exporter和datax

附录

问题

可以看到,Prometheus监控比datax自身丰富,可读性更好,并且可以配触发器告警, 功能上和Communication重叠,但Communication不能去掉,用于限流,需后续合并