VictoriaMetrics vmanomaly 组件架构与配置实战从 Reader 到 Writer 的完整指南【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics本文以仓库 docs/anomaly-detection/components/README.md 为主体骨架结合 models.md、reader.md、scheduler.md、writer.md 等子组件文档与仓库内真实部署配置deployment/docker/vmanomaly编写。文章聚焦 vmanomaly 的组件化配置体系读者将掌握 Models、Reader、Scheduler、Writer、Monitoring、Settings、Server 七大配置区块的作用、必选/可选关系、字段语义以及热重载与环境变量等高级用法可直接基于文中配置搭建一套可运行的指标异常检测链路。一、组件总览vmanomaly 的七大配置区块VictoriaMetrics Anomaly Detection简称vmanomaly通过一个 YAML 配置文件驱动配置文件由以下七个独立区块组成各自职责单一、可组合区块必选/可选作用Model(s) section必选定义用什么算法、什么超参数对数据做异常检测Reader section必选定义从哪个数据源、用什么查询读取数据Scheduler(s) section必选定义何时训练模型、何时产出异常分数Writer section必选定义把模型输出写回哪个 VictoriaMetricsMonitoring section可选定义 vmanomaly 自身的自监控pull/pushSettings section可选定义全局运行参数并行度、状态恢复、模型保留策略等Server section可选定义内置 HTTP 服务与 UI 行为需要特别说明的几个使用前提来自原文档启动时配置校验从 v1.7.2 起服务在启动时会校验配置合法性校验错误会输出到容器日志字段描述与示例以上述各区块文档为准。类名短别名从 v1.13.0 起组件类名可以用短别名代替完整导入路径例如model.zscore.ZscoreModel→zscorereader.vm.VmReader→vmscheduler.periodic.PeriodicScheduler→periodic。Preset 模式从 v1.13.0 起还提供preset配置模式免写完整配置直接套用预置场景相关指南见 Presets.md。二、组件交互一条完整的数据流各组件之间并非彼此孤立而是形成一条固定的执行链。核心路径为config.yml → Scheduler → Reader → Model → Writer其中Scheduler是整个流程的驱动器它决定“何时训练、何时推理”并触发后续各环节Reader负责按调度器的时间窗口向配置好的 VictoriaMetrics或 VictoriaLogs / VictoriaTraces数据源发起查询把时序数据喂给模型Model在训练fit与推理infer两个阶段消费数据产出异常分数等输出序列Writer把模型输出保留原始标签集并可按配置附加额外标签写回 VictoriaMetricsMonitoring是可选的自监控环节既可以把指标主动 push 出去也可以暴露/metrics端点供抓取。下图仓库文件 vmanomaly-components.svg原文引用自 vmanomaly-components-diagram.md展示了组件之间的协作关系实线节点与箭头表示异常检测的必选路径虚线节点与箭头表示可选的自监控集成。此外还有一个与多租户相关的细节Reader 与 Writer 均支持多租户multitenancy可以通过tenant_id参数实现“从 A 租户读、向 B 租户写”或读写不同位置的数据。例如在 reader.md 中可以看到tenant_id支持0:0、multitenant等取值查询级tenant_id可以覆盖 reader 级配置。三、完整示例配置七区块一网打尽原文档给出了一份“最小但完整”的多对多映射配置多个模型 × 多个查询 × 多个调度器。这份配置是理解整个组件体系最好的入口下面完整保留并补充字段注释settings: n_workers: 4 # 并行运行模型的 worker 数量 native_threads_per_worker: 0 # 自动按容器感知的 CPU 容量在各 worker 间分配线程 anomaly_score_outside_data_range: 5.0 # 数据超出预期范围时使用的默认异常分数 restore_state: True # 从上次运行恢复状态若可用 retention: # 陈旧的模型在磁盘/内存中保留多久 ttl: 1d # 存活时间模型在 ttl 内未被用于推理即视为陈旧 check_interval: 1h # 多久检查一次陈旧模型并清理 # 模型“何时运行、多久运行一次”由 schedulers 定义 schedulers: periodic_online: # 调度器别名 class: periodic # 调度器类短别名 infer_every: 30s # 多久对新数据产出一轮异常分数 scatter_infer_jobs: true # 将推理任务在推理间隔内均匀打散避免同步突发 fit_every: 1000d # 仅引导用的大间隔如需周期性重置累积状态应改用有限节奏 fit_window: 3d # 训练阶段使用的历史数据长度 start_from: 00:00 # 将引导训练对齐到所配时区的午夜 tz: Europe/Kyiv # start_from 使用的时区 periodic_online_weekly: class: periodic infer_every: 15m scatter_infer_jobs: true fit_every: 1000d # 仅引导用如需重置累积状态请改用有限节奏 fit_window: 14d # 若未指定 start_from任务将在服务启动后立即开始 # 用什么模型类型、什么超参数跑数据 models: zscore: # 模型别名 class: zscore_online # 模型类 z_threshold: 3.5 decay: 0.99 # 数据点权重取值 (0, 1]1 表示对所有数据一视同仁 provide_series: [anomaly_score, y, yhat, yhat_upper] # 模型输出哪些序列 queries: [host_network_receive_errors] # 该模型跑在哪些查询上 schedulers: [periodic_online] # 只 fit 一次每 30s 推理 clip_predictions: True # 将预测裁剪到预期数据范围如该查询的 [0, inf] envelope_weekly: # 模型别名 class: temporal_envelope alpha: 0.005 # 使用仅引导的 fit 计划时适配趋势的速度 loss_reactivity: 3 # 允许新偏差更新包络 provide_series: [anomaly_score, y, yhat, yhat_lower, yhat_upper] queries: [cpu_seconds_total] schedulers: [periodic_online_weekly] # 按两周周期 fit之后每 15m 在线更新 anomaly_score_outside_data_range: 1.5 # 覆盖默认的数据越界异常分数 clip_predictions: True # 将预测裁剪到 [0, inf] seasonalities: [hod_smooth, dow_smooth] # 小时平滑 星期平滑季节性 # 从哪里读数据 reader: class: vm datasource_url: https://play.victoriametrics.com/ tenant_id: 0:0 sampling_period: 30s # 从 VictoriaMetrics /query_range 接口拉取的数据分辨率 workers: 0 # 自动选择有上限的数据源并发度 latency_offset: 1ms query_from_last_seen_timestamp: False tz: UTC # 无显式时区的查询所使用的时区 offset: 0s # 应用到所有查询的偏移量用于补偿数据延迟可在查询级覆盖 queries: # 查询别名 → MetricsQL 表达式 cpu_seconds_total: expr: avg(rate(node_cpu_seconds_total[5m])) by (mode) # step: 30s # 不设置时等于 reader 级 sampling_period data_range: [0, inf] # 查询级业务策略v1.30.2 起 detection_direction: above_expected # 查询级v1.30.2 起只检测尖峰 min_dev_from_expected: [0.01, 0.01] # 查询级v1.30.2 起 host_network_receive_errors: expr: rate(node_network_receive_errs_total[3m]) / rate(node_network_receive_packets_total[3m]) step: 15m # 查询级覆盖 sampling_period向 TSDB 请求更少的数据 data_range: [0, inf] # 查询级业务策略v1.30.2 起 detection_direction: above_expected # 查询级v1.30.2 起只检测尖峰 min_dev_from_expected: 0.0 # 查询级v1.30.2 起禁用绝对偏差过滤 # 把数据写到哪里 writer: datasource_url: http://victoriametrics:8428/ tenant_id: 0:0 # 集群版可支持 multitenant metric_format: __name__: $VAR for: $QUERY_KEY # 以 pull 和/或 push 方式启用自监控 monitoring: # pull: # 启用 /metrics 端点 # addr: 0.0.0.0 # port: 8490 push: # 启用推送自监控指标 url: http://victoriametrics:8428 push_frequency: 15m # 推送自监控指标的频率 # 配置 vmanomaly 服务与 UI server: port: 8490 path_prefix: /vmanomaly # 所有 HTTP 路由的可选路径前缀 max_concurrent_tasks: 4 # 后端同时处理的最大异常检测任务数 use_reader_connection_settings: True # 为 True 时UI 请求数据源复用 reader 的 datasource_url 与凭据 uvicorn_config: # 可选的 Uvicorn 服务器配置 log_level: warning这份配置演示了几个关键设计模型与调度器/查询是多对多绑定zscore模型绑定periodic_online调度器做高频30s推理envelope_weekly模型绑定periodic_online_weekly做低频15m推理且各模型绑定不同查询。fit 与 infer 解耦fit_every: 1000d是“仅引导”写法——服务启动时用fit_window的历史数据训练一次之后长期只做在线推理若需要周期性重置模型状态则应配置有限的fit_every节奏。查询级覆盖 reader 级参数step、data_range、detection_direction、min_dev_from_expected等都可以在reader.queries.alias下按查询单独设置。四、子组件深度解读4.1 Settings全局运行参数与状态恢复settings区块控制整个服务的运行方式主要参数包括n_workers并行运行模型的 worker 数例如4。native_threads_per_worker每个 worker 的原生线程数0表示按容器感知的 CPU 能力自动分配。anomaly_score_outside_data_range数据落在预期范围之外时使用的异常分数默认值如5.0模型和查询级都可以覆盖。restore_state是否从上次运行恢复模型与调度器状态。配合热重载使用可以避免不必要的重新训练、调度器重新初始化与数据重读详见原文档 Hot reload 一节。retention陈旧模型的保留策略包含ttl如1d模型在 TTL 内未被推理即视为陈旧与check_interval如1h检查并清理陈旧模型的周期。状态恢复State restoration是保证服务稳定性的关键能力强烈建议在重启频繁的场景如 Kubernetes 下开启restore_state: true。4.2 Scheduler训练与推理的节奏控制器vmanomaly内置三类调度器类名短别名见括号scheduler.periodic.PeriodicScheduler别名periodic生产环境主力。周期性对新数据运行模型产出异常分数并周期性重新训练模型以对抗数据漂移与模型退化。scheduler.oneoff.OneoffScheduler别名oneoff只运行一次后退出适合测试或对历史数据做一次性回填。scheduler.backtesting.BacktestingScheduler别名backtesting模拟 PeriodicScheduler 行为但只运行一次用于在含历史标注事件的数据上回测模型表现。Periodic 调度器的核心参数时间粒度由字符串末位单位决定如50s/4m/3h/2d/1w参数类型示例说明fit_windowstr14d训练模型使用的时间范围至少 1 秒infer_everystr1m模型对新数据产出并写入异常分数的频率至少 1 秒fit_everystr, 可选1h完全重训模型的频率未设置时等于infer_every每次推理都重训start_fromstr, 可选2024-11-26T01:00:00Z、01:00第一次fit_every的触发时间支持 ISO 8601 或 HH:MM过去的时间会按fit_every推算到下一个合适时刻需要特别提醒的陷阱原文档警告如果使用了start_from务必同时在 Settings 中开启restore_state: true。否则服务在两次调度之间被终止再重启后会一直空闲到下一个start_from时刻——例如start_from设为20:00服务 20:30 重启将直到第二天 20:00 才能再次产出异常分数中间空闲长达 23.5 小时。4.3 Reader数据入口与查询策略Reader 是数据入口支持两类VmReader类名vm/reader.vm.VmReader从 VictoriaMetrics / Prometheus 读取 Prometheus 兼容指标查询语言为 MetricsQL走/api/v1/query_range端点。关键参数包括datasource_url数据源地址tenant_id集群版租户标识0:0或multitenantsampling_period返回数据点的频率v1.9.0 起必填会转换为/query_range?step参数query_from_last_seen_timestamp为 True 时推理从该序列最后一次看到的时间戳开始查询对跳过若干轮 infer 的场景很有用latency_offset默认1ms用于覆盖 VictoriaMetrics 的-search.latencyOffset默认 30s。当sampling_period较小10-60s且等于infer_every时可避免日志中出现 “No data available for inference” 警告并保证推理无间隙workers数据源并发抓取线程数上限0表示按查询数与可用 CPU 自动选择有界值verify_tls/tls_cert_file/tls_key_file/bearer_token/bearer_token_fileTLS 与认证配置支持 mTLSv1.16.3 起tzIANA 时区默认 UTC供对季节性敏感模型使用可在查询级覆盖max_points_per_query长fit_window查询拆分为多个子区间时每子查询的最大点数帮助规避search.maxQueryDuration限制。查询级per-query参数v1.13.0 起引入的queries新格式允许每个查询覆盖 reader 级设置exprMetricsQL/PromQL 表达式即传给/query_range?query的内容step查询级频率用于优化从 VictoriaMetrics 读取的数据量data_range定义输入数据的合法取值范围。数据越界 → 高异常分数1模型预测越界 → 最低异常分数0。注意在模型中配置data_range已自 v1.30.2 起废弃应配置在reader.queries.alias下以保证查询被多个模型复用时业务口径一致detection_directionboth默认/above_expected/below_expected控制只有哪一侧偏差能产生异常分数min_dev_from_expected忽略小于该绝对阈值的偏差标量或一/两元素列表两元素可分别配置上下方向阈值min_rel_dev_from_expected忽略小于期望值绝对值一定百分比的偏差max_points_per_query、tz、tenant_id、offset均可按查询覆盖。一个完整的多查询 reader 示例来自 reader.mdreader: class: vm sampling_period: 1m datasource_url: https://play.victoriametrics.com/ max_points_per_query: 10000 data_range: [0, inf] tenant_id: multitenant offset: 0s queries: ingestion_rate_t1: expr: sum(rate(vm_rows_inserted_total[5m])) by (type) 0 step: 2m # 覆盖全局 sampling_period data_range: [10, inf] # y 10 触发异常分数 1 detection_direction: above_expected # 只把尖峰视为异常 min_dev_from_expected: [0, 5] # 忽略向上小于 5 的偏差 min_rel_dev_from_expected: [0, 15] # 忽略向上低于 15% 的偏差 max_points_per_query: 5000 tz: America/New_York tenant_id: 1:0 ingestion_rate_t2: expr: sum(rate(vm_rows_inserted_total[5m])) by (type) 0 step: 2m data_range: [10, inf] max_points_per_query: 5000 tz: America/New_York tenant_id: 2:0 offset: -15s # 提前 15 秒查询补偿数据采集延迟VLogsReader类名vlogs/reader.vlogs.VLogsReaderv1.26.0 起从 VictoriaLogs 的 stats 查询端点/select/stats_query_range读取日志统计数据VictoriaTraces 也复用同一 reader两者端点等价。查询必须使用 LogsQL 并以stats管道结尾支持avg、count、count_uniq、max、min、median、quantile、rate、sum等返回数值的统计函数。典型示例* | stats count() as logs # 日志总量 * | stats rate() as logs_per_sec # 每秒日志速率 * | stats by (_stream) rate() as logs_per_sec # 按流分组速率 * | stats count_uniq(_stream) as active_streams # 活跃流数量4.4 Models算法选择与输出控制models区块支持通过别名定义多个模型v1.10.0 起旧的扁平model配置已废弃若同时存在只使用models。所有模型共有的参数queries该模型运行在哪些 reader 查询上不设置则自动绑定 reader 中全部查询schedulers哪些调度器驱动该模型不设置则自动绑定全部调度器provide_series限制写入 writer 的输出序列。默认输出集合为{anomaly_score, y, yhat, yhat_lower, yhat_upper}且无论如何输出不能少于[anomaly_score]timestamp会被隐式加入写指标必需clip_predictions是否将预测裁剪到预期数据范围如[0, inf]。检测方向detection_direction当领域知识表明只有高于或低于期望值的值才是异常时可用它减少误报。三种取值的行为差异如下图所示图片来自 models.mdboth默认向后兼容y yhat或y yhat都跟踪适合没有领域先验的场景above_expected只跟踪y yhat。适合错误率、响应时间、页面加载时间等“越低越好”的指标below_expected只跟踪y yhat。适合 SLA 达标率、转化率、CSAT 满意度等“越高越好”的指标。最小偏差阈值min_dev_from_expected当偏差在相对意义上较大、但在绝对业务意义上可忽略时用它把|y - yhat| min_dev_from_expected的数据点异常分数显式置 0。v1.23.0 起支持两元素列表分别配置上下方向阈值如[0.01, 0.02]表示下偏差阈值 0.01、上偏差阈值 0.02。例如 CPU 利用率从 0.3% 突增到 1.3%相对涨幅 333% 但绝对值仅 1 个百分点业务上可能无需告警此时设min_dev_from_expected: 0.01即可过滤。内置模型类型vmanomaly内置多种模型包括滚动式与非滚动式两大类——非滚动模型每次 fit 基于固定历史窗口独立训练适合周期性回填滚动模型持续吸收新数据在线更新适合流式在线推理。原文档以 model-type-rolling.webp 等图示说明了两类模型的生命周期差异具体模型清单如zscore_online、temporal_envelope、temporal_envelope_multivariate、online_quantile等及自定义模型指南见 models.md。此外 v1.13.0 起模型可落盘存储on-disk mode以略降推理速度换取大幅降低的 RAM 占用适合大规模场景。4.5 Writer结果回写与指标格式化Writer 的职责是把模型输出写回 VictoriaMetrics保留原始标签集并可选附加额外标签。核心参数datasource_url目标地址tenant_id集群版支持0:0与multitenantmetric_format定义输出指标的命名与标签模板必须包含__name__键且值中带$VAR占位符。支持的占位符$VAR模型提供的输出变量如anomaly_score、y、yhat等$QUERY_KEY查询别名如ingestion_rate。例如metric_format: {__name__: vmanomaly_$VAR, for: $QUERY_KEY}会把anomaly_score写成名为vmanomaly_anomaly_score、带forquery_key标签的序列。更多占位符说明与格式示例见 writer.md 的 “Metrics formatting” 一节。4.6 Monitoring 与 Server自监控与内置 UImonitoring区块支持两种自监控模式pull开启/metrics端点通过addr如0.0.0.0与port如8490暴露供 Prometheus 等抓取push主动推送指标到urlpush_frequency控制推送频率如15m。server区块配置内置 HTTP 服务与 UIport服务监听端口如8490path_prefix所有 HTTP 路由的可选路径前缀如/vmanomalymax_concurrent_tasks后端并发处理的异常检测任务上限如4use_reader_connection_settings为 True 时UI 对数据源的请求复用 reader 的datasource_url与凭据uvicorn_config底层 Uvicorn 服务器配置如log_level: warning。五、热重载Hot reload配置变更零重启从 v1.25.0 起vmanomaly支持配置文件热重载通过--watch命令行参数启用。配合 Settings 中的状态恢复restore_state: true使用效果最佳——可以保留模型与调度器状态避免不必要的重训练、调度器重建与数据重读。vmanomaly_config_reload_enabled自监控指标为1表示已启用热重载0表示未启用。5.1 工作原理从 v1.29.5 起基于文件系统事件的热重载已被废弃原因是 Kubernetes ConfigMap 符号链接轮转等场景下事件投递不可靠改为基于内容轮询服务按-configCheckInterval默认30s检查被监视的.yml/.yaml文件发现内容变化后等待去抖窗口重建全局配置并重新初始化各组件。每次重载会使vmanomaly_config_reloads_total指标自增携带statussuccess或statusfailure标签校验失败也会记入日志。失败回退机制如果重载失败服务会记录错误原因并继续沿用上一次有效的配置直到下一次成功重载——保证服务稳定性。在分片sharded部署中每次全局配置变更都会重新计算当前分片的分配从 v1.30.4 起无运行任务的分片保持存活但空闲后续重载分配新任务时会恢复兼容的模型状态并创建调度器无需重启进程。5.2 热重载示例假设config.yaml内容如下服务通过--watch启动settings: n_workers: 4 anomaly_score_outside_data_range: 5.0 restore_state: True schedulers: periodic: class: periodic infer_every: 30s fit_every: 1000d # 仅引导如需重置累积状态改用有限节奏 fit_window: 24h reader: datasource_url: https://play.victoriametrics.com/ tenant_id: 0:0 class: vm sampling_period: 30s queries: cpu_seconds_total: expr: avg(rate(node_cpu_seconds_total[5m])) by (mode) data_range: [0, inf] # step: 30s # 不设置时等于 sampling_period host_network_receive_errors: expr: rate(node_network_receive_errs_total[3m]) / rate(node_network_receive_packets_total[3m]) step: 15s data_range: [0, inf] models: zscore: class: zscore_online z_threshold: 3.5 decay: 0.99 # 越接近 1 对历史数据越一视同仁 provide_series: [anomaly_score] # 未指定 queries自动使用 reader 中全部查询 # 未指定 schedulers自动使用全部调度器 writer: datasource_url: http://victoriametrics:8428/ tenant_id: 0:0 monitoring: push: url: http://victoriametrics:8428 push_frequency: 15m服务启动 15 分钟后如果修改了cpu_seconds_total查询的表达式与频率reader: queries: cpu_seconds_total: expr: avg(rate(node_cpu_seconds_total[10m])) by (mode) # 修改了回看窗口 data_range: [0, inf] step: 60s # 修改了 step保存后热重载自动检测到config.yaml变化并重载。由于改动合法服务会记录成功并让vmanomaly_config_reloads_total{statussuccess}自增其行为是基于host_network_receive_errors训练的zscore_online模型实例仍然有效、可以直接复用推理直到下一个fit_every基于cpu_seconds_total训练的模型实例因查询表达式与频率已变化而失效将按新表达式重新训练。即热重载只重训受影响的部分未被触动的模型状态得以保留。六、环境变量占位符动态配置与密钥管理从 v1.25.0 起配置文件中可以直接引用环境变量语法为标量字符串占位符%{ENV_NAME}。这对于管理 API Key、数据库凭据等敏感信息尤其有用——不必把明文写进 YAML。例如设置环境变量VMANOMALY_URLhttp://localhost:8428后可在 reader 区块中写datasource_url: %{VMANOMALY_URL}服务启动时自动替换。reader: class: vm datasource_url: %{VMANOMALY_URL} # 替换为 VMANOMALY_URL 的值 tenant_id: %{VMANOMALY_TENANT_ID} bearer_token: %{VMANOMALY_BEARER_TOKEN} sampling_period: 30s writer: datasource_url: %{VMANOMALY_URL} tenant_id: %{VMANOMALY_TENANT_ID} bearer_token: %{VMANOMALY_BEARER_TOKEN} # 其他配置区块 ...注意如果引用的环境变量未设置或拼写有误占位符不会被替换可能导致配置校验或端点探测失败。建议在启动服务前确保所有引用的环境变量均已设置。七、仓库中的真实部署示例除了官方文档仓库内还带有可直接参考的 docker 编排示例deployment/docker/vmanomalyvmanomaly-integration 目录提供了一套完整的集成栈其中 vmanomaly_config.yml 是真实的 vmanomaly 配置与compose.yml、prometheus.yml、vmalert_config.yml等配合组成可运行环境schedulers: periodic: infer_every: 1m fit_every: 1000d # 仅引导如需重置累积状态请改用有限节奏 fit_window: 2w models: temporal_envelope: class: temporal_envelope queries: all schedulers: all seasonalities: [hod_smooth, dow_smooth] alpha: 0.005 loss_reactivity: 5 iqr_threshold: 2 reader: datasource_url: http://victoriametrics:8428/ sampling_period: 60s queries: node_cpu_rate: expr: sum(rate(node_cpu_seconds_total[5m])) by (mode, instance, job) writer: datasource_url: http://victoriametrics:8428/ monitoring: pull: # 启用 /metrics 端点 addr: 0.0.0.0 port: 8490vmanomaly-node-exporter-preset 目录则演示了基于 node-exporter 指标的 preset 用法其中 user_input_example.yml 展示了用户只需补充极少量输入即可获得预置模型与告警规则。八、总结vmanomaly的组件化设计把“读数据、算模型、定节奏、写结果、自监控、跑服务”拆分为清晰解耦的配置区块必选链路Scheduler 驱动 → Reader 取数 → Model 计算 → Writer 回写构成一条完整的数据闭环可选增强Settings 控制并行度与状态恢复Monitoring 暴露自监控指标Server 提供 UI 与任务并发控制灵活绑定模型与查询、调度器之间通过queries/schedulers实现多对多组合满足“不同指标不同节奏、不同算法”的混合场景生产友好--watch热重载 状态恢复避免不必要的重训练失败时回退到上一有效配置%{ENV_NAME}环境变量占位符保障密钥不入文件查询级data_range/detection_direction/min_dev_from_expected让业务口径与模型解耦。从 v1.13.0 的类名短别名、v1.25.0 的热重载与环境变量、v1.29.5 的内容轮询式重载到 v1.30.2 的查询级 KPI 策略detection_direction、min_dev_from_expected等统一收敛到reader.queries.alias下这套配置体系持续向“稳定、可运维、业务可解释”演进。掌握上述七个区块的字段语义与组合方式即可按需构建从指标采集到异常告警的完整链路。【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
VictoriaMetrics vmanomaly 组件架构与配置实战：从 Reader 到 Writer 的完整指南
VictoriaMetrics vmanomaly 组件架构与配置实战从 Reader 到 Writer 的完整指南【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics本文以仓库 docs/anomaly-detection/components/README.md 为主体骨架结合 models.md、reader.md、scheduler.md、writer.md 等子组件文档与仓库内真实部署配置deployment/docker/vmanomaly编写。文章聚焦 vmanomaly 的组件化配置体系读者将掌握 Models、Reader、Scheduler、Writer、Monitoring、Settings、Server 七大配置区块的作用、必选/可选关系、字段语义以及热重载与环境变量等高级用法可直接基于文中配置搭建一套可运行的指标异常检测链路。一、组件总览vmanomaly 的七大配置区块VictoriaMetrics Anomaly Detection简称vmanomaly通过一个 YAML 配置文件驱动配置文件由以下七个独立区块组成各自职责单一、可组合区块必选/可选作用Model(s) section必选定义用什么算法、什么超参数对数据做异常检测Reader section必选定义从哪个数据源、用什么查询读取数据Scheduler(s) section必选定义何时训练模型、何时产出异常分数Writer section必选定义把模型输出写回哪个 VictoriaMetricsMonitoring section可选定义 vmanomaly 自身的自监控pull/pushSettings section可选定义全局运行参数并行度、状态恢复、模型保留策略等Server section可选定义内置 HTTP 服务与 UI 行为需要特别说明的几个使用前提来自原文档启动时配置校验从 v1.7.2 起服务在启动时会校验配置合法性校验错误会输出到容器日志字段描述与示例以上述各区块文档为准。类名短别名从 v1.13.0 起组件类名可以用短别名代替完整导入路径例如model.zscore.ZscoreModel→zscorereader.vm.VmReader→vmscheduler.periodic.PeriodicScheduler→periodic。Preset 模式从 v1.13.0 起还提供preset配置模式免写完整配置直接套用预置场景相关指南见 Presets.md。二、组件交互一条完整的数据流各组件之间并非彼此孤立而是形成一条固定的执行链。核心路径为config.yml → Scheduler → Reader → Model → Writer其中Scheduler是整个流程的驱动器它决定“何时训练、何时推理”并触发后续各环节Reader负责按调度器的时间窗口向配置好的 VictoriaMetrics或 VictoriaLogs / VictoriaTraces数据源发起查询把时序数据喂给模型Model在训练fit与推理infer两个阶段消费数据产出异常分数等输出序列Writer把模型输出保留原始标签集并可按配置附加额外标签写回 VictoriaMetricsMonitoring是可选的自监控环节既可以把指标主动 push 出去也可以暴露/metrics端点供抓取。下图仓库文件 vmanomaly-components.svg原文引用自 vmanomaly-components-diagram.md展示了组件之间的协作关系实线节点与箭头表示异常检测的必选路径虚线节点与箭头表示可选的自监控集成。此外还有一个与多租户相关的细节Reader 与 Writer 均支持多租户multitenancy可以通过tenant_id参数实现“从 A 租户读、向 B 租户写”或读写不同位置的数据。例如在 reader.md 中可以看到tenant_id支持0:0、multitenant等取值查询级tenant_id可以覆盖 reader 级配置。三、完整示例配置七区块一网打尽原文档给出了一份“最小但完整”的多对多映射配置多个模型 × 多个查询 × 多个调度器。这份配置是理解整个组件体系最好的入口下面完整保留并补充字段注释settings: n_workers: 4 # 并行运行模型的 worker 数量 native_threads_per_worker: 0 # 自动按容器感知的 CPU 容量在各 worker 间分配线程 anomaly_score_outside_data_range: 5.0 # 数据超出预期范围时使用的默认异常分数 restore_state: True # 从上次运行恢复状态若可用 retention: # 陈旧的模型在磁盘/内存中保留多久 ttl: 1d # 存活时间模型在 ttl 内未被用于推理即视为陈旧 check_interval: 1h # 多久检查一次陈旧模型并清理 # 模型“何时运行、多久运行一次”由 schedulers 定义 schedulers: periodic_online: # 调度器别名 class: periodic # 调度器类短别名 infer_every: 30s # 多久对新数据产出一轮异常分数 scatter_infer_jobs: true # 将推理任务在推理间隔内均匀打散避免同步突发 fit_every: 1000d # 仅引导用的大间隔如需周期性重置累积状态应改用有限节奏 fit_window: 3d # 训练阶段使用的历史数据长度 start_from: 00:00 # 将引导训练对齐到所配时区的午夜 tz: Europe/Kyiv # start_from 使用的时区 periodic_online_weekly: class: periodic infer_every: 15m scatter_infer_jobs: true fit_every: 1000d # 仅引导用如需重置累积状态请改用有限节奏 fit_window: 14d # 若未指定 start_from任务将在服务启动后立即开始 # 用什么模型类型、什么超参数跑数据 models: zscore: # 模型别名 class: zscore_online # 模型类 z_threshold: 3.5 decay: 0.99 # 数据点权重取值 (0, 1]1 表示对所有数据一视同仁 provide_series: [anomaly_score, y, yhat, yhat_upper] # 模型输出哪些序列 queries: [host_network_receive_errors] # 该模型跑在哪些查询上 schedulers: [periodic_online] # 只 fit 一次每 30s 推理 clip_predictions: True # 将预测裁剪到预期数据范围如该查询的 [0, inf] envelope_weekly: # 模型别名 class: temporal_envelope alpha: 0.005 # 使用仅引导的 fit 计划时适配趋势的速度 loss_reactivity: 3 # 允许新偏差更新包络 provide_series: [anomaly_score, y, yhat, yhat_lower, yhat_upper] queries: [cpu_seconds_total] schedulers: [periodic_online_weekly] # 按两周周期 fit之后每 15m 在线更新 anomaly_score_outside_data_range: 1.5 # 覆盖默认的数据越界异常分数 clip_predictions: True # 将预测裁剪到 [0, inf] seasonalities: [hod_smooth, dow_smooth] # 小时平滑 星期平滑季节性 # 从哪里读数据 reader: class: vm datasource_url: https://play.victoriametrics.com/ tenant_id: 0:0 sampling_period: 30s # 从 VictoriaMetrics /query_range 接口拉取的数据分辨率 workers: 0 # 自动选择有上限的数据源并发度 latency_offset: 1ms query_from_last_seen_timestamp: False tz: UTC # 无显式时区的查询所使用的时区 offset: 0s # 应用到所有查询的偏移量用于补偿数据延迟可在查询级覆盖 queries: # 查询别名 → MetricsQL 表达式 cpu_seconds_total: expr: avg(rate(node_cpu_seconds_total[5m])) by (mode) # step: 30s # 不设置时等于 reader 级 sampling_period data_range: [0, inf] # 查询级业务策略v1.30.2 起 detection_direction: above_expected # 查询级v1.30.2 起只检测尖峰 min_dev_from_expected: [0.01, 0.01] # 查询级v1.30.2 起 host_network_receive_errors: expr: rate(node_network_receive_errs_total[3m]) / rate(node_network_receive_packets_total[3m]) step: 15m # 查询级覆盖 sampling_period向 TSDB 请求更少的数据 data_range: [0, inf] # 查询级业务策略v1.30.2 起 detection_direction: above_expected # 查询级v1.30.2 起只检测尖峰 min_dev_from_expected: 0.0 # 查询级v1.30.2 起禁用绝对偏差过滤 # 把数据写到哪里 writer: datasource_url: http://victoriametrics:8428/ tenant_id: 0:0 # 集群版可支持 multitenant metric_format: __name__: $VAR for: $QUERY_KEY # 以 pull 和/或 push 方式启用自监控 monitoring: # pull: # 启用 /metrics 端点 # addr: 0.0.0.0 # port: 8490 push: # 启用推送自监控指标 url: http://victoriametrics:8428 push_frequency: 15m # 推送自监控指标的频率 # 配置 vmanomaly 服务与 UI server: port: 8490 path_prefix: /vmanomaly # 所有 HTTP 路由的可选路径前缀 max_concurrent_tasks: 4 # 后端同时处理的最大异常检测任务数 use_reader_connection_settings: True # 为 True 时UI 请求数据源复用 reader 的 datasource_url 与凭据 uvicorn_config: # 可选的 Uvicorn 服务器配置 log_level: warning这份配置演示了几个关键设计模型与调度器/查询是多对多绑定zscore模型绑定periodic_online调度器做高频30s推理envelope_weekly模型绑定periodic_online_weekly做低频15m推理且各模型绑定不同查询。fit 与 infer 解耦fit_every: 1000d是“仅引导”写法——服务启动时用fit_window的历史数据训练一次之后长期只做在线推理若需要周期性重置模型状态则应配置有限的fit_every节奏。查询级覆盖 reader 级参数step、data_range、detection_direction、min_dev_from_expected等都可以在reader.queries.alias下按查询单独设置。四、子组件深度解读4.1 Settings全局运行参数与状态恢复settings区块控制整个服务的运行方式主要参数包括n_workers并行运行模型的 worker 数例如4。native_threads_per_worker每个 worker 的原生线程数0表示按容器感知的 CPU 能力自动分配。anomaly_score_outside_data_range数据落在预期范围之外时使用的异常分数默认值如5.0模型和查询级都可以覆盖。restore_state是否从上次运行恢复模型与调度器状态。配合热重载使用可以避免不必要的重新训练、调度器重新初始化与数据重读详见原文档 Hot reload 一节。retention陈旧模型的保留策略包含ttl如1d模型在 TTL 内未被推理即视为陈旧与check_interval如1h检查并清理陈旧模型的周期。状态恢复State restoration是保证服务稳定性的关键能力强烈建议在重启频繁的场景如 Kubernetes 下开启restore_state: true。4.2 Scheduler训练与推理的节奏控制器vmanomaly内置三类调度器类名短别名见括号scheduler.periodic.PeriodicScheduler别名periodic生产环境主力。周期性对新数据运行模型产出异常分数并周期性重新训练模型以对抗数据漂移与模型退化。scheduler.oneoff.OneoffScheduler别名oneoff只运行一次后退出适合测试或对历史数据做一次性回填。scheduler.backtesting.BacktestingScheduler别名backtesting模拟 PeriodicScheduler 行为但只运行一次用于在含历史标注事件的数据上回测模型表现。Periodic 调度器的核心参数时间粒度由字符串末位单位决定如50s/4m/3h/2d/1w参数类型示例说明fit_windowstr14d训练模型使用的时间范围至少 1 秒infer_everystr1m模型对新数据产出并写入异常分数的频率至少 1 秒fit_everystr, 可选1h完全重训模型的频率未设置时等于infer_every每次推理都重训start_fromstr, 可选2024-11-26T01:00:00Z、01:00第一次fit_every的触发时间支持 ISO 8601 或 HH:MM过去的时间会按fit_every推算到下一个合适时刻需要特别提醒的陷阱原文档警告如果使用了start_from务必同时在 Settings 中开启restore_state: true。否则服务在两次调度之间被终止再重启后会一直空闲到下一个start_from时刻——例如start_from设为20:00服务 20:30 重启将直到第二天 20:00 才能再次产出异常分数中间空闲长达 23.5 小时。4.3 Reader数据入口与查询策略Reader 是数据入口支持两类VmReader类名vm/reader.vm.VmReader从 VictoriaMetrics / Prometheus 读取 Prometheus 兼容指标查询语言为 MetricsQL走/api/v1/query_range端点。关键参数包括datasource_url数据源地址tenant_id集群版租户标识0:0或multitenantsampling_period返回数据点的频率v1.9.0 起必填会转换为/query_range?step参数query_from_last_seen_timestamp为 True 时推理从该序列最后一次看到的时间戳开始查询对跳过若干轮 infer 的场景很有用latency_offset默认1ms用于覆盖 VictoriaMetrics 的-search.latencyOffset默认 30s。当sampling_period较小10-60s且等于infer_every时可避免日志中出现 “No data available for inference” 警告并保证推理无间隙workers数据源并发抓取线程数上限0表示按查询数与可用 CPU 自动选择有界值verify_tls/tls_cert_file/tls_key_file/bearer_token/bearer_token_fileTLS 与认证配置支持 mTLSv1.16.3 起tzIANA 时区默认 UTC供对季节性敏感模型使用可在查询级覆盖max_points_per_query长fit_window查询拆分为多个子区间时每子查询的最大点数帮助规避search.maxQueryDuration限制。查询级per-query参数v1.13.0 起引入的queries新格式允许每个查询覆盖 reader 级设置exprMetricsQL/PromQL 表达式即传给/query_range?query的内容step查询级频率用于优化从 VictoriaMetrics 读取的数据量data_range定义输入数据的合法取值范围。数据越界 → 高异常分数1模型预测越界 → 最低异常分数0。注意在模型中配置data_range已自 v1.30.2 起废弃应配置在reader.queries.alias下以保证查询被多个模型复用时业务口径一致detection_directionboth默认/above_expected/below_expected控制只有哪一侧偏差能产生异常分数min_dev_from_expected忽略小于该绝对阈值的偏差标量或一/两元素列表两元素可分别配置上下方向阈值min_rel_dev_from_expected忽略小于期望值绝对值一定百分比的偏差max_points_per_query、tz、tenant_id、offset均可按查询覆盖。一个完整的多查询 reader 示例来自 reader.mdreader: class: vm sampling_period: 1m datasource_url: https://play.victoriametrics.com/ max_points_per_query: 10000 data_range: [0, inf] tenant_id: multitenant offset: 0s queries: ingestion_rate_t1: expr: sum(rate(vm_rows_inserted_total[5m])) by (type) 0 step: 2m # 覆盖全局 sampling_period data_range: [10, inf] # y 10 触发异常分数 1 detection_direction: above_expected # 只把尖峰视为异常 min_dev_from_expected: [0, 5] # 忽略向上小于 5 的偏差 min_rel_dev_from_expected: [0, 15] # 忽略向上低于 15% 的偏差 max_points_per_query: 5000 tz: America/New_York tenant_id: 1:0 ingestion_rate_t2: expr: sum(rate(vm_rows_inserted_total[5m])) by (type) 0 step: 2m data_range: [10, inf] max_points_per_query: 5000 tz: America/New_York tenant_id: 2:0 offset: -15s # 提前 15 秒查询补偿数据采集延迟VLogsReader类名vlogs/reader.vlogs.VLogsReaderv1.26.0 起从 VictoriaLogs 的 stats 查询端点/select/stats_query_range读取日志统计数据VictoriaTraces 也复用同一 reader两者端点等价。查询必须使用 LogsQL 并以stats管道结尾支持avg、count、count_uniq、max、min、median、quantile、rate、sum等返回数值的统计函数。典型示例* | stats count() as logs # 日志总量 * | stats rate() as logs_per_sec # 每秒日志速率 * | stats by (_stream) rate() as logs_per_sec # 按流分组速率 * | stats count_uniq(_stream) as active_streams # 活跃流数量4.4 Models算法选择与输出控制models区块支持通过别名定义多个模型v1.10.0 起旧的扁平model配置已废弃若同时存在只使用models。所有模型共有的参数queries该模型运行在哪些 reader 查询上不设置则自动绑定 reader 中全部查询schedulers哪些调度器驱动该模型不设置则自动绑定全部调度器provide_series限制写入 writer 的输出序列。默认输出集合为{anomaly_score, y, yhat, yhat_lower, yhat_upper}且无论如何输出不能少于[anomaly_score]timestamp会被隐式加入写指标必需clip_predictions是否将预测裁剪到预期数据范围如[0, inf]。检测方向detection_direction当领域知识表明只有高于或低于期望值的值才是异常时可用它减少误报。三种取值的行为差异如下图所示图片来自 models.mdboth默认向后兼容y yhat或y yhat都跟踪适合没有领域先验的场景above_expected只跟踪y yhat。适合错误率、响应时间、页面加载时间等“越低越好”的指标below_expected只跟踪y yhat。适合 SLA 达标率、转化率、CSAT 满意度等“越高越好”的指标。最小偏差阈值min_dev_from_expected当偏差在相对意义上较大、但在绝对业务意义上可忽略时用它把|y - yhat| min_dev_from_expected的数据点异常分数显式置 0。v1.23.0 起支持两元素列表分别配置上下方向阈值如[0.01, 0.02]表示下偏差阈值 0.01、上偏差阈值 0.02。例如 CPU 利用率从 0.3% 突增到 1.3%相对涨幅 333% 但绝对值仅 1 个百分点业务上可能无需告警此时设min_dev_from_expected: 0.01即可过滤。内置模型类型vmanomaly内置多种模型包括滚动式与非滚动式两大类——非滚动模型每次 fit 基于固定历史窗口独立训练适合周期性回填滚动模型持续吸收新数据在线更新适合流式在线推理。原文档以 model-type-rolling.webp 等图示说明了两类模型的生命周期差异具体模型清单如zscore_online、temporal_envelope、temporal_envelope_multivariate、online_quantile等及自定义模型指南见 models.md。此外 v1.13.0 起模型可落盘存储on-disk mode以略降推理速度换取大幅降低的 RAM 占用适合大规模场景。4.5 Writer结果回写与指标格式化Writer 的职责是把模型输出写回 VictoriaMetrics保留原始标签集并可选附加额外标签。核心参数datasource_url目标地址tenant_id集群版支持0:0与multitenantmetric_format定义输出指标的命名与标签模板必须包含__name__键且值中带$VAR占位符。支持的占位符$VAR模型提供的输出变量如anomaly_score、y、yhat等$QUERY_KEY查询别名如ingestion_rate。例如metric_format: {__name__: vmanomaly_$VAR, for: $QUERY_KEY}会把anomaly_score写成名为vmanomaly_anomaly_score、带forquery_key标签的序列。更多占位符说明与格式示例见 writer.md 的 “Metrics formatting” 一节。4.6 Monitoring 与 Server自监控与内置 UImonitoring区块支持两种自监控模式pull开启/metrics端点通过addr如0.0.0.0与port如8490暴露供 Prometheus 等抓取push主动推送指标到urlpush_frequency控制推送频率如15m。server区块配置内置 HTTP 服务与 UIport服务监听端口如8490path_prefix所有 HTTP 路由的可选路径前缀如/vmanomalymax_concurrent_tasks后端并发处理的异常检测任务上限如4use_reader_connection_settings为 True 时UI 对数据源的请求复用 reader 的datasource_url与凭据uvicorn_config底层 Uvicorn 服务器配置如log_level: warning。五、热重载Hot reload配置变更零重启从 v1.25.0 起vmanomaly支持配置文件热重载通过--watch命令行参数启用。配合 Settings 中的状态恢复restore_state: true使用效果最佳——可以保留模型与调度器状态避免不必要的重训练、调度器重建与数据重读。vmanomaly_config_reload_enabled自监控指标为1表示已启用热重载0表示未启用。5.1 工作原理从 v1.29.5 起基于文件系统事件的热重载已被废弃原因是 Kubernetes ConfigMap 符号链接轮转等场景下事件投递不可靠改为基于内容轮询服务按-configCheckInterval默认30s检查被监视的.yml/.yaml文件发现内容变化后等待去抖窗口重建全局配置并重新初始化各组件。每次重载会使vmanomaly_config_reloads_total指标自增携带statussuccess或statusfailure标签校验失败也会记入日志。失败回退机制如果重载失败服务会记录错误原因并继续沿用上一次有效的配置直到下一次成功重载——保证服务稳定性。在分片sharded部署中每次全局配置变更都会重新计算当前分片的分配从 v1.30.4 起无运行任务的分片保持存活但空闲后续重载分配新任务时会恢复兼容的模型状态并创建调度器无需重启进程。5.2 热重载示例假设config.yaml内容如下服务通过--watch启动settings: n_workers: 4 anomaly_score_outside_data_range: 5.0 restore_state: True schedulers: periodic: class: periodic infer_every: 30s fit_every: 1000d # 仅引导如需重置累积状态改用有限节奏 fit_window: 24h reader: datasource_url: https://play.victoriametrics.com/ tenant_id: 0:0 class: vm sampling_period: 30s queries: cpu_seconds_total: expr: avg(rate(node_cpu_seconds_total[5m])) by (mode) data_range: [0, inf] # step: 30s # 不设置时等于 sampling_period host_network_receive_errors: expr: rate(node_network_receive_errs_total[3m]) / rate(node_network_receive_packets_total[3m]) step: 15s data_range: [0, inf] models: zscore: class: zscore_online z_threshold: 3.5 decay: 0.99 # 越接近 1 对历史数据越一视同仁 provide_series: [anomaly_score] # 未指定 queries自动使用 reader 中全部查询 # 未指定 schedulers自动使用全部调度器 writer: datasource_url: http://victoriametrics:8428/ tenant_id: 0:0 monitoring: push: url: http://victoriametrics:8428 push_frequency: 15m服务启动 15 分钟后如果修改了cpu_seconds_total查询的表达式与频率reader: queries: cpu_seconds_total: expr: avg(rate(node_cpu_seconds_total[10m])) by (mode) # 修改了回看窗口 data_range: [0, inf] step: 60s # 修改了 step保存后热重载自动检测到config.yaml变化并重载。由于改动合法服务会记录成功并让vmanomaly_config_reloads_total{statussuccess}自增其行为是基于host_network_receive_errors训练的zscore_online模型实例仍然有效、可以直接复用推理直到下一个fit_every基于cpu_seconds_total训练的模型实例因查询表达式与频率已变化而失效将按新表达式重新训练。即热重载只重训受影响的部分未被触动的模型状态得以保留。六、环境变量占位符动态配置与密钥管理从 v1.25.0 起配置文件中可以直接引用环境变量语法为标量字符串占位符%{ENV_NAME}。这对于管理 API Key、数据库凭据等敏感信息尤其有用——不必把明文写进 YAML。例如设置环境变量VMANOMALY_URLhttp://localhost:8428后可在 reader 区块中写datasource_url: %{VMANOMALY_URL}服务启动时自动替换。reader: class: vm datasource_url: %{VMANOMALY_URL} # 替换为 VMANOMALY_URL 的值 tenant_id: %{VMANOMALY_TENANT_ID} bearer_token: %{VMANOMALY_BEARER_TOKEN} sampling_period: 30s writer: datasource_url: %{VMANOMALY_URL} tenant_id: %{VMANOMALY_TENANT_ID} bearer_token: %{VMANOMALY_BEARER_TOKEN} # 其他配置区块 ...注意如果引用的环境变量未设置或拼写有误占位符不会被替换可能导致配置校验或端点探测失败。建议在启动服务前确保所有引用的环境变量均已设置。七、仓库中的真实部署示例除了官方文档仓库内还带有可直接参考的 docker 编排示例deployment/docker/vmanomalyvmanomaly-integration 目录提供了一套完整的集成栈其中 vmanomaly_config.yml 是真实的 vmanomaly 配置与compose.yml、prometheus.yml、vmalert_config.yml等配合组成可运行环境schedulers: periodic: infer_every: 1m fit_every: 1000d # 仅引导如需重置累积状态请改用有限节奏 fit_window: 2w models: temporal_envelope: class: temporal_envelope queries: all schedulers: all seasonalities: [hod_smooth, dow_smooth] alpha: 0.005 loss_reactivity: 5 iqr_threshold: 2 reader: datasource_url: http://victoriametrics:8428/ sampling_period: 60s queries: node_cpu_rate: expr: sum(rate(node_cpu_seconds_total[5m])) by (mode, instance, job) writer: datasource_url: http://victoriametrics:8428/ monitoring: pull: # 启用 /metrics 端点 addr: 0.0.0.0 port: 8490vmanomaly-node-exporter-preset 目录则演示了基于 node-exporter 指标的 preset 用法其中 user_input_example.yml 展示了用户只需补充极少量输入即可获得预置模型与告警规则。八、总结vmanomaly的组件化设计把“读数据、算模型、定节奏、写结果、自监控、跑服务”拆分为清晰解耦的配置区块必选链路Scheduler 驱动 → Reader 取数 → Model 计算 → Writer 回写构成一条完整的数据闭环可选增强Settings 控制并行度与状态恢复Monitoring 暴露自监控指标Server 提供 UI 与任务并发控制灵活绑定模型与查询、调度器之间通过queries/schedulers实现多对多组合满足“不同指标不同节奏、不同算法”的混合场景生产友好--watch热重载 状态恢复避免不必要的重训练失败时回退到上一有效配置%{ENV_NAME}环境变量占位符保障密钥不入文件查询级data_range/detection_direction/min_dev_from_expected让业务口径与模型解耦。从 v1.13.0 的类名短别名、v1.25.0 的热重载与环境变量、v1.29.5 的内容轮询式重载到 v1.30.2 的查询级 KPI 策略detection_direction、min_dev_from_expected等统一收敛到reader.queries.alias下这套配置体系持续向“稳定、可运维、业务可解释”演进。掌握上述七个区块的字段语义与组合方式即可按需构建从指标采集到异常告警的完整链路。【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
