从 InfluxDB 迁移到 VictoriaMetrics 完整指南数据模型对比、MetricsQL 查询改造与 vmctl 数据迁移实战【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics本篇技术指南以 VictoriaMetrics 官方迁移指南为核心系统讲解从 InfluxDB 迁往 VictoriaMetrics 时必然遇到的三大核心问题数据模型差异measurement/field/tag 如何映射为 metric/label、查询语言改造InfluxQL 如何翻译为 MetricsQL以及历史数据迁移使用vmctl工具完成 InfluxDB v1 数据回填。读完本文你将掌握 InfluxDB 数据在 VictoriaMetrics 中的等价表示方法、Line Protocol 写入与 Grafana 查询配置方式并能独立跑通一次完整的 vmctl 数据迁移。为什么从 InfluxDB 迁移到 VictoriaMetricsInfluxDB 是为 IoT 监控、应用性能监控APM和分析场景设计的知名时序数据库拥有自成一体的查询语言、独特的数据模型以及完备的指标采集与处理工具链。VictoriaMetrics 则是专为海量监控数据设计的高性能开源时序数据库在保证成本效益的同时具备极强的横向扩展能力。许多公司正是出于性能与可扩展性的考量选择从 InfluxDB 迁移到 VictoriaMetrics官方文档收录了 ARNES 与 Brandwatch 的案例研究可供参考。迁移通常需要回答三个问题两种数据模型如何对应、InfluxQL 查询如何在 MetricsQL 中等价表达、存量数据如何导入。下文逐一展开。数据模型差异measurement/field/tag 与 metric/label 的映射两种数据库都是schemaless免预定义的无需提前定义指标或标签这是迁移的基础前提。但具体的数据组织方式存在显著差异维度InfluxDBVictoriaMetrics多维数据通过tags实现通过labels实现标签值类型支持多种数据类型标签值始终是字符串见 labels 说明时间戳精度纳秒毫秒指标值类型支持多种数据类型始终为float64见 raw samples组织单元measurement、field、database、bucket、organization只有全局命名空间或tenant多租户没有 measurement/field/database/bucket/organization 概念查询语言InfluxQL / Flux 等多个版本统一的MetricsQL不兼容 Influx 任何查询语言其中最关键的一点VictoriaMetrics没有 measurement 和 field 概念指标名承载了全部语义。如果某个 measurement 包含多个 field在 VictoriaMetrics 中就会拆成多条指标。以 InfluxDB 官方文档的样例数据为例原始形式为_measurement_fieldlocationscientist_value_timecensusbeesklamathanderson232019-08-18T00:00:00Zcensusantsportlandmullen302019-08-18T00:00:00Zcensusbeesklamathanderson282019-08-18T00:06:00Zcensusantsportlandmullen322019-08-18T00:06:00Z在 VictoriaMetrics 数据模型中等价表示为metric namelabelsvaluetimecensus_bees{locationklamath, scientistanderson}232019-08-18T00:00:00Zcensus_ants{locationportland, scientistmullen}302019-08-18T00:00:00Zcensus_bees{locationklamath, scientistanderson}282019-08-18T00:06:00Zcensus_ants{locationportland, scientistmullen}322019-08-18T00:06:00Z实际上VictoriaMetrics 的指标名本身就是一条名为__name__的静态标签上例可写作{__name__census_bees, locationklamath, scientistanderson}。所有标签都被自动索引因此无论按指标名还是按标签查询查询速度都是一样的。完整的数据模型定义见 keyConcepts 数据模型。写入数据InfluxDB Line Protocol 与 Telegraf 兼容VictoriaMetrics 原生支持 InfluxDB Line Protocol 数据摄入。最简单的验证方式是直接用curl向写入端点发送 HTTP POST 请求curl -d census,locationklamath,scientistanderson bees23 -X POST http://victoriametrics-addr:8428/write单次请求中可以携带任意数量以\n换行符分隔的 Line Protocol 行。注意根据 Influx Line Protocol 规范引号包裹的 tag/field 值内部不允许出现裸换行字节否则会解析失败。写入后可调用导出接口验证数据例如匹配locationklamath的时间序列curl -G http://victoriametrics-addr:8428/api/v1/export -d match{locationklamath}预期返回 JSON{ metric: { __name__: census_bees, location: klamath, scientist: anderson }, values: [ 23 ], timestamps: [ 1566079200000 ] }VictoriaMetrics 会对经由 Line Protocol 摄入的数据执行额外的数据映射转换其规则为db查询参数映射为db标签值除非 Line 中已存在dbtag可通过-influxDBLabel标志覆盖标签名需要更严格的数据隔离时可改用多租户机制field 名映射为{measurement}{separator}{field}形式的时序名{separator}默认为_可用-influxMeasurementFieldSeparator修改若{measurement}为空或设置-influxSkipMeasurement则时序名直接使用 field 名-influxSkipSingleField可控制单 field 场景的行为field 值映射为时序值非数值 field 值会被转换为 0tag 原样映射为 Prometheus 标签设置-usePromCompatibleNaming后指标名与标签名会被规范化为 Prometheus 兼容命名不支持的字符替换为_例如foo.bar-baz/1→foo_bar_baz_1。例如 Linefoo,tag1value1,tag2value2 field112,field240会被转换为两条 Prometheus 数据点foo_field1{tag1value1, tag2value2} 12 foo_field2{tag1value1, tag2value2} 40时间戳方面Line Protocol 默认以纳秒为单位而 VictoriaMetrics 内部以毫秒存储秒、微秒、纳秒精度的输入都会被自动换算为毫秒。让 Telegraf 直接向 VictoriaMetrics 推送数据VictoriaMetrics 与 Telegraf 完全兼容。只需在 Telegraf 配置中把输出地址替换为 VictoriaMetrics 即可[[outputs.influxdb]] urls [http://victoriametrics-addr:8428]其中victoriametrics-addr替换为 VictoriaMetrics 的主机名或 IP。集群版则使用 vminsert 地址http://vminsert-addr:8480/insert/tenant/influx多实例时注意配置负载均衡tenant依据多租户设置填写。此外 VictoriaMetrics 还暴露 InfluxDB v2 HTTP API 端点/influx/api/v2/write与/api/v2/write以及基于outputs.http的写法url http://victoriametrics-addr:8428/influx/write、data_format influx。对发送SHOW DATABASES查询并期望特定数据库名的插件可通过-influx.databaseNames标志传入期望的数据库列表。更多细节见 InfluxDB 集成文档。除 Line Protocol 外VictoriaMetrics 还支持大量其他指标采集方式。查询数据从 InfluxQL 到 MetricsQLVictoriaMetrics 没有命令行查询接口CLI而是提供VMUI——一个用于查询与可视化指标图形界面以及 Grafana 数据源两种途径。Grafana 接入方式见 Grafana 数据源配置相关章节通用查询方法见 keyConcepts 查询数据。基础概念一个 InfluxQL 查询的完整翻译以如下 Line Protocol 数据样本为例measurement 为foo、field 为bar附加 taginstancelocalhostfoo,instancelocalhost bar1.00 1652169600000000000 foo,instancelocalhost bar2.00 1652169660000000000 foo,instancelocalhost bar3.00 1652169720000000000 foo,instancelocalhost bar5.00 1652169840000000000 foo,instancelocalhost bar5.50 1652169960000000000 foo,instancelocalhost bar5.50 1652170020000000000 foo,instancelocalhost bar4.00 1652170080000000000 foo,instancelocalhost bar3.50 1652170260000000000 foo,instancelocalhost bar3.25 1652170320000000000 foo,instancelocalhost bar3.00 1652170380000000000 foo,instancelocalhost bar2.00 1652170440000000000 foo,instancelocalhost bar1.00 1652170500000000000 foo,instancelocalhost bar4.00 1652170560000000000若要在 Grafana 中绘制该序列InfluxQL 面板查询为SELECT last (bar) FROM foo WHERE (instance localhost) AND $timeFilter GROUP BY time (1m)将其逐段翻译为 MetricsQLSELECT last(bar) FROM foo对 instant 或 range API 的请求本质上都是读操作无需SELECT语句VictoriaMetrics 没有 measurement/field整段替换为指标名foo_barWHERE (instance localhost)MetricsQL 的标签过滤以花括号形式跟在指标名后翻译为{instancelocalhost}WHERE $timeFilter时间过滤由请求参数携带MetricsQL 中无需书写GROUP BY time(1m)range 查询默认按请求携带的step参数自动按时间分组无需在表达式里显式指定额外的聚合与分组函数见官方文档。最终 MetricsQL 表达式为foo_bar{instancelocalhost}。以step1m在 Grafana 中执行的结果如下注意两种可视化存在细微差别VictoriaMetrics 会填充图中的缺口因为它在建模上假定时间序列是连续而非离散的。InfluxDB 中可通过给查询添加fill(previous)达到类似效果若想限制 VictoriaMetrics 填充缺口的区间可设置-search.setLookbackToStep命令行标志将缺口填充限制在传给/api/v1/query_range的单个step区间内。另外当step参数低于实际数据分辨率时查询可能返回比预期更多的数据点包含不存在的时间点这是 range 查询的预期行为。进阶用法绝大多数查询只是“选择 rate 聚合”掌握基础就足以应付大多数 MetricsQL 使用场景。以 Grafana 上最热门的 Node Exporter Full 仪表盘为例其包含约 230 条查询而拆解后构成非常规律约 120 条查询只是带标签过滤地选择指标例如node_textfile_scrape_error{instance$node,job$job}约 80 条查询对选中指标使用 rate 函数例如rate(node_netstat_Tcp_InSegs{instance$node,job$job}[5m])其余为 sum、count 等聚合函数。进一步学习 MetricsQL 可参考 MetricsQL 核心概念与 MetricsQL 函数全集。使用 vmctl 迁移存量数据把数据从其他数据库迁入 VictoriaMetrics本质上就是通过任一支持的摄入格式回填数据。而从 InfluxDB 迁移时官方推荐的更省心方案是vmctl其完整参数与用法见 vmctl influx 模式文档与 vmctl 总览。注意vmctl 仅支持 InfluxDBv1.x的数据迁移InfluxDB v2.x 迁移暂不支持官方文档指引使用第三方方案influx_to_victoriametrics解决详见 InfluxDB v2 章节。最小迁移命令指定 InfluxDB 地址、数据库名与 VictoriaMetrics 地址即可启动迁移./vmctl influx --influx-addrhttp://influx-addr:8086 \ --influx-databasebenchmark \ --vm-addrhttp://victoriametrics-addr:8428典型的执行过程会先探索数据库结构再逐条导入InfluxDB import mode 2020/01/18 20:47:11 Exploring scheme for database benchmark 2020/01/18 20:47:11 fetching fields: command: show field keys; database: benchmark; retention: autogen 2020/01/18 20:47:11 found 10 fields 2020/01/18 20:47:11 fetching series: command: show series ; database: benchmark; retention: autogen Found 40000 timeseries to import. Continue? [Y/n] y 40000 / 40000 [----------------------------------------------------------------------------------------] 100.00% 21 p/s 2020/01/18 21:19:00 Import finished! 2020/01/18 21:19:00 VictoriaMetrics importer stats: idle duration: 13m51.461434876s; time spent while importing: 17m56.923899847s; total samples: 345600000; samples/s: 320914.04; total bytes: 5.9 GB; bytes/s: 5.4 MB; import requests: 40001; 2020/01/18 21:19:00 Total time: 31m48.467044016s从源码结构看迁移流程与日志一一对应Client.Explore()依次执行show field keys、show tag keys、show series探明数据库 schema含保留策略随后通过 FetchDataPoints 构造select field from measurement where ...查询并按块拉取数据timeFilter负责把时间过滤拼进查询条件。目标端地址--vm-addr的配置细节见 vmctl 配置说明。数据迁移本质上是回填backfilling过程建议阅读 Single-server 回填注意事项。数据映射规则vmctl 按以下规则改写 InfluxDB 数据与写入路径的映射规则保持一致field 值映射为时序值tag 原样映射为标签--influx-database映射为db标签值除非 Line 中已存在dbtag可用--influx-skip-database-label跳过field 名映射为{measurement}{separator}{field}形式的时序名{separator}默认为_可用--influx-measurement-field-separator修改。例如 Linefoo,tag1value1,tag2value2 field112,field240转换为foo_field1{tag1value1, tag2value2} 12 foo_field2{tag1value1, tag2value2} 40源码层面的佐证非数值 field 在导入时会被跳过fieldsByMeasurement中对string类型字段计数并跳过数值统一经 toFloat64 转换RFC3339 时间戳在 parseDate 中被换算为毫秒时间戳。数据过滤按 series 与按时间可通过--influx-filter-series对导出数据施加额外过滤./vmctl influx --influx-database benchmark \ --influx-filter-series on benchmark from cpu where hostnamehost_1703过滤会直接作用到 schema 探索阶段日志中的实际查询为show series on benchmark from cpu where hostnamehost_1703对应源码 getSeriesCommand 的拼接逻辑。按时间过滤则使用以下两个标志--influx-filter-time-start--influx-filter-time-end例如只导入某一天的数据./vmctl influx --influx-database benchmark \ --influx-filter-time-start 2020-01-01T10:07:00Z \ --influx-filter-time-end 2020-01-01T15:07:00Z迁移性能调优Influx 模式下 vmctl 通过执行读查询从 InfluxDB 拉取数据迁移速度主要受限于 InfluxDB 响应查询的能力。默认情况下 vmctl 串行执行读请求可用--influx-concurrency提高并发读请求数默认为 1但要注意不要压垮迁移期间的 InfluxDB。--influx-chunk-size控制单次 chunk 拉取的最大数据点数量用于控制 InfluxDB 的内存使用避免处理数十亿数据点的大型时序时 OOM。从源码看分块查询同时作用于 series 拉取与数据点拉取Client结构体持有chunkSizeFetchDataPoints中构造Chunked: true的分块查询。其余目标端参数也值得关注--vm-concurrency默认 2控制并发导入 worker 数--vm-batch-size默认 200000控制攒批发送的样本数--vm-compress默认 true对导入请求启用 gzip 压缩--vm-rate-limit可限制数据传输速率以保护目标端--vm-backoff-*系列控制失败重试策略。完整清单见 vmctl influx 参数列表。集群版导入时还需设置--vm-account-id指定租户。通用迁移建议见 vmctl migration tips。常见问题FAQVictoriaMetrics 与 InfluxDB 相比如何官方 FAQ 指出 VictoriaMetrics 在资源效率上显著更优详见 FAQ 对比章节。为什么不支持 Remote Read API这样我就不用学 MetricsQL 了因为 Remote Read API 的性能开销非常高。PromQL 和 MetricsQL 常被一起提及为什么MetricsQL 是受 PromQL 启发的查询语言与 PromQL 向后兼容因此基于 Prometheus 数据源的 Grafana 仪表盘切换到 VictoriaMetrics 后应能正常工作。两种语言共享相同的核心概念仅存在细微差异。查询返回的数据点比预期多为什么当step参数低于实际数据分辨率时VictoriaMetrics 可能返回不存在的数据点缺口填充行为详见 range query。如何拿到“真实”的最后一个数据点last_over_time返回给定回看窗口内的最后值。例如last_over_time(metric[10s])仅在真实样本距离按start、end、step参数计算的采样点不足 10 秒时返回值tlast_over_time返回给定回看窗口内最后样本的时间戳用法与last_over_time类似。如何用 MetricsQL 获取原始数据点在方括号中指定时间区间并以 instant query 发送即可。例如GET api/v1/query?querymy_metric[5m]timetime会返回my_metric在time到time-5m区间内的原始样本。MetricsQL 中能否有多个聚合器如SELECT MAX(field), MIN(field)可以尝试如下查询( alias(max(field), max), alias(min(field), min) )。Influx 的percentile函数如何翻译为 MetricsQL使用histogram_quantile与histogram_over_time函数组合实现。Influx 的stddev函数如何翻译为 MetricsQL使用histogram_stddev与histogram_over_time函数组合实现。迁移路线小结完成一次从 InfluxDB 到 VictoriaMetrics 的迁移可以归纳为四步理解映射确认 measurement/field/tag →{measurement}_{field}指标名 标签的映射规则评估db标签与命名规范化的影响验证写入用curl或 Telegraf 改造向/write端点发送 Line Protocol用/api/v1/export校验数据形态改造查询将 InfluxQL 逐步翻译为 MetricsQL去掉 SELECT、花括号过滤、时间与 step 交由请求参数并在 VMUI 或 Grafana 中验证结果一致性迁移存量用vmctl influx指定地址与数据库执行回填配合--influx-filter-*、--influx-concurrency、--influx-chunk-size控制范围与速度完成后核对 importer stats。迁移过程中的回填注意事项可参考 Single-server-VictoriaMetrics 回填章节vmctl 的通用技巧见 vmctl 迁移建议。【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考