VictoriaMetrics vmanomaly Writer 组件详解VmWriter 配置、指标格式化与多租户写入实践【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetricsVictoriaMetrics Anomaly Detectionvmanomaly通过 Reader、Models、Scheduler、Writer 等组件构成完整的异常检测闭环其中 Writer 组件负责将模型产出的异常分数anomaly score等结果序列写回 VictoriaMetrics是整个流水线的出口。本文以仓库文档 docs/anomaly-detection/components/writer.md 为主体结合组件总览、模型输出定义、自监控指标与部署示例系统讲解 VmWriter 的全部配置参数、metric_format指标命名规则、多租户写入行为与 mTLS 保护帮助你在生产环境中正确配置并验证异常检测结果的落库链路。Writer 在 vmanomaly 组件体系中的定位vmanomaly服务在启动时会解析配置文件其中writer是必需的配置段之一详见 docs/anomaly-detection/components/README.md。整个数据流可以概括为Reader从 VictoriaMetrics 的/query_range等端点按调度器Scheduler拉取历史与增量数据Models在 fit / infer 阶段对每条时间序列计算异常分数与预测区间Writer将模型输出序列anomaly_score、yhat、yhat_lower、yhat_upper、y等写回 VictoriaMetrics供 Grafana 仪表盘、vmalert 告警规则等下游消费。Writer 的核心设计目标是平滑地对接 VictoriaMetrics 生态它在写入结果时保留输入数据自带的标签集labelset并可选地附加额外的标签如查询别名、配置来源等使异常检测结果能够与原始指标天然关联、便于按维度聚合与告警。官方文档同时说明未来版本会引入更多数据导出方式但目前vmanomaly主要采用 VmWriter 完成数据导出。VM writer 概述VmWriter是vmanomaly内置的、面向 VictoriaMetrics / Prometheus 兼容写入协议的结果导出器。它默认使用 VictoriaMetrics 的导入接口/api/v1/import该参数自 v1.19.2 起已被弃用默认路径自动生效将模型输出以 Prometheus 文本协议NDJSON 序列化批量提交并具备连接重试、批量拆分、跨周期前缀缓存等生产级能力。组件类名支持短别名引用自 v1.13.0 起writer.vm.VmWriter可以简写为vm在更早的版本中必须书写完整类名。如果配置中省略class字段VmWriter是默认选项。配置参数总览下表汇总了VmWriter的全部配置参数以 docs/anomaly-detection/components/writer.md 为准参数示例说明classwriter.vm.VmWriter或vm启用写入 VictoriaMetrics / Prometheus 所需的类名。自 v1.13.0 起支持短别名vm未指定时默认使用VmWriterdatasource_urlhttp://localhost:8481/数据源写入目标URL 地址tenant_id0:0、multitenant仅适用于 VictoriaMetrics Cluster 版本。租户由accountID或accountID:projectID标识自 v1.16.2 起支持multitenant端点用于跨多个租户写入详见下方多租户支持一节metric_format__name__: vmanomaly_$VAR输出指标的命名与标签模板。必须包含__name__键且其值必须包含$VAR占位符以区分不同输出序列。支持占位符$VAR模型提供的变量与$QUERY_KEY查询别名其余键为用户自定义标签详见指标格式化一节import_json_path/api/v1/import可选用于覆盖默认导入路径。自 v1.19.2 起已弃用health_path/health可选探测数据源可用性的绝对或相对 URL 路径用于覆盖默认的/healthuserUSERNAMEBasicAuth 用户名passwordPASSWORDBasicAuth 密码timeout5s请求超时时间以字符串形式传入verify_tlsfalse是否校验 TLS 证书。False时不校验True时使用系统 CA 存储校验传入 CA 捆绑文件路径如ca.crt时使用该 CA 捆绑校验tls_cert_filepath/to/cert.crt客户端证书文件路径如client.crt自 v1.16.3 起可用用于 mTLStls_key_filepath/to/key.crt客户端证书私钥文件路径如client.key自 v1.16.3 起可用用于 mTLSbearer_tokentoken以标准格式通过请求头传递的令牌Authorization: bearer {token}bearer_token_filepath_to_file存放令牌的文件路径同样以Authorization: bearer {token}请求头传递自 v1.15.9 起可用connection_retry_attempts1连接失败时的重试次数自 v1.29.2 起可用默认1batch_max_series1000单次 VictoriaMetrics 导入请求中输出时间序列的最大数量自 v1.30.3 起可用更大的推理输出会被拆分为多个请求默认1000batch_max_bytes4194304单次导入请求序列化后的最大字节数软上限自 v1.30.3 起可用单条不可分割的 NDJSON 时间序列可能超过此软界默认 4 MiB4194304metric_prefix_cache_max_entries10000跨写入周期保留的预构建指标-标签前缀缓存条目数上限自 v1.30.3 起可用设为0可禁用跨周期前缀缓存默认10000完整配置示例以下为官方给出的VmWriter配置示例可直接放入vmanomaly配置文件的writer段writer: class: vm # or writer.vm.VmWriter until v1.13.0 datasource_url: http://localhost:8428/ tenant_id: 0:0 metric_format: __name__: vmanomaly_$VAR for: $QUERY_KEY run: test_metric_format config: io_vm_single.yaml import_json_path: /api/v1/import health_path: health user: foo password: bar connection_retry_attempts: 2 # if not specified, it will be 1 by default batch_max_series: 1000 # maximum series per VictoriaMetrics import request batch_max_bytes: 4194304 # soft maximum serialized request size (4 MiB) metric_prefix_cache_max_entries: 10000 # set to 0 to disable cross-cycle caching其中datasource_url指向接收写入的 VictoriaMetrics 单机实例如http://victoriametrics:8428/在 Docker Compose 部署中通常直接使用服务名作为主机名见 deployment/docker/vmanomaly/vmanomaly-integration/compose.yml 中的 vmanomaly 服务。提示batch_max_series与batch_max_bytes用于控制写入请求的粒度。当模型输出时间序列规模很大时vmanomaly会按这两个边界自动拆分请求避免单个导入请求过大导致写入端内存压力或超时metric_prefix_cache_max_entries则通过跨周期缓存预构建的指标前缀来降低重复序列化的开销在高基数场景下可根据内存预算调优。Metrics formatting 指标格式化metric_format是 Writer 配置中最核心的业务字段它决定了模型输出序列在写回 VictoriaMetrics 时使用什么指标名与标签。配置中必须设置两个必填参数__name__和for。__name__: PREFIX1_$VAR for: PREFIX2_$QUERY_KEY其作用机制如下__name__指标名模板$VAR占位符会被替换为模型输出的变量名例如PREFIX1_anomaly_score、PREFIX1_yhat_lower、PREFIX1_yhat、PREFIX1_yhat_upper、PREFIX1_y等。这些变量名的完整定义见 docs/anomaly-detection/components/models.md 的 vmanomaly output 小节其中anomaly_score是主指标0.0 ~ 1.0 表示正常大于 1.0 通常判定为异常告警阈值可另行调整yhat为预测期望值yhat_lower/yhat_upper为预测下/上边界y为查询返回的原始值。不同模型还可能提供额外输出如 Prophet 的trend、seasonalitySeasonal Trend Decomposition 的resid等这些变量同样可通过$VAR映射。for查询标签模板$QUERY_KEY占位符会被替换为查询别名即 reader 配置queries段中定义的 key。例如 reader 中定义了queries: {query_name_1: ..., query_name_2: ...}则输出会带上标签forPREFIX2_query_name_1、forPREFIX2_query_name_2从而把异常分数与具体的输入查询关联起来。除了以上两个必填模板你还可以指定任意自定义标签键值对custom_label_1: label_name_1 custom_label_2: label_name_2一个完整的metric_format示例及其效果metric_format: __name__: PREFIX1_$VAR for: PREFIX2_$QUERY_KEY custom_label_1: label_name_1 custom_label_2: label_name_2假设输入数据自带标签cpu1, deviceeth0, instancenode-exporter:9100这些标签来自 docs/anomaly-detection/components/reader.md 中queries返回的指标则最终写回的指标形如{__name__PREFIX1_anomaly_score, forPREFIX2_query_name_1, custom_label_1label_name_1, custom_label_2label_name_2, cpu1, deviceeth0, instancenode-exporter:9100} {__name__PREFIX1_yhat_lower, forPREFIX2_query_name_1, custom_label_1label_name_1, custom_label_2label_name_2, cpu1, deviceeth0, instancenode-exporter:9100} {__name__PREFIX1_anomaly_score, forPREFIX2_query_name_2, custom_label_1label_name_1, custom_label_2label_name_2, cpu1, deviceeth0, instancenode-exporter:9100} {__name__PREFIX1_yhat_lower, forPREFIX2_query_name_2, custom_label_1label_name_1, custom_label_2label_name_2, cpu1, deviceeth0, instancenode-exporter:9100}可以看到输入指标自带的标签cpu、device、instance被完整保留同时叠加了模板标签__name__、for与自定义标签。这一特性使得 Grafana 仪表盘与 vmalert 告警规则可以直接沿用原始指标的维度体系对异常分数做切片分析。官方建议为metric_format添加for标签以获得更平滑的异常分数仪表盘可视化体验见 docs/anomaly-detection/QuickStart.md 的配置建议。多租户支持多租户写入仅适用于VictoriaMetrics Cluster 版本。租户由accountID或accountID:projectID标识自 v1.15.9 起支持multitenant端点可在单个 Writer 配置下将数据写入多个租户详细的多租户概念可参考仓库中 docs/victoriametrics/Cluster-VictoriaMetrics.md 的多租户章节。根据writer.tenant_id取值与结果标签集中是否携带多租户标签实际行为分为四种情况writer.tenant_id ! multitenant如0:0且reader.tenant_id ! multitenant可为不同但合法的值如0:1vm_account_id标签在 Reader 侧不会被创建、不会持久化到 Writer也不会出现在输出中结果数据正常写入无日志、无报错。writer.tenant_id multitenant且标签集中存在vm_project_id这通常发生在reader.tenant_id也设为multitenant时——Reader 查询返回的结果中会携带vm_account_id标签结果一切按预期工作数据正常写入无日志、无报错。writer.tenant_id multitenant但标签集中缺少vm_account_id例如 Reader 侧做了聚合、或查询中缺少keep_metric_names结果数据仍会写入默认租户0:0但会抛出如下警告The label vm_account_id was not found in the label set of {query_result.key}, but tenant_idmultitenant is set in writer. The data will be written to the default tenant 0:0. Ensure that the query retains the necessary multi-tenant labels, or adjust the aggregation settings to preserve vm_account_id key in the label set.writer.tenant_id ! multitenant如0:0但标签集中存在vm_account_id结果写入被允许但会抛出如下警告The label set for the metric {query_result.key} contains multi-tenancy labels, but the write endpoint is configured for single-tenant mode (tenant_id ! multitenant). Either adjust the query in the reader to avoid multi-tenancy labels or ensure that reserved key vm_account_id is not explicitly set for single-tenant environments.简而言之vm_account_id/vm_project_id是保留标签其语义必须与writer.tenant_id的配置模式保持一致。在multitenant模式下务必让 Reader 的查询保留多租户路由标签避免聚合吞掉它们在单租户模式下则不要显式设置vm_account_id。这一行为在 docs/anomaly-detection/components/monitoring.md 的 Reader / Writer 日志章节中也有对应描述——The label vm_account_id was not found警告即意味着multitenantWriter 将回退到租户0:0。mTLS 保护自 v1.16.3 起vmanomaly的 VmWriter 等组件支持mTLS双向 TLS用于与启用了 mTLS 的 VictoriaMetrics Enterprise 实例建立安全通信实现客户端与服务端之间的双向证书身份校验防止未授权访问。mTLS 相关的配置参数为verify_tls若传入字符串其作用等价于 VictoriaMetrics 的-mtlsCAFile命令行参数指定 CA 捆绑文件设为True则使用系统默认证书存储tls_cert_file客户端证书路径等价于 VictoriaMetrics 的-tlsCertFiletls_key_file客户端证书私钥路径类似-tlsKeyFile。配置示例完整参数解析见 docs/anomaly-detection/components/reader.md 的 mTLS protection 一节该节对 Reader / Writer / Monitoring 各组件给出了一致的配置原则writer: class: vm datasource_url: https://your-victoriametrics-instance-with-mtls tenant_id: 0:0 verify_tls: path/to/ca.crt # path to CA bundle for TLS verification tls_cert_file: path/to/client.crt # path to the client certificate tls_key_file: path/to/client.key # path to the client certificate key需要注意的是verify_tls的三种取值语义分别对应False不校验证书、True使用系统 CA 存储校验、CA 文件路径使用指定的 CA 捆绑校验。写入行为的自监控指标VmWriter 会暴露一组健康与行为指标详细定义见 docs/anomaly-detection/components/monitoring.md 的 Writer behaviour metrics 小节用于观测写入链路的状态。自 v1.17.0 起这些指标统一增加了scheduler_alias与preset标签以适配多调度器场景且请求耗时类指标由Summary改为Histogram以支持分位数计算指标类型说明vmanomaly_writer_request_duration_secondsHistogram向 VictoriaMetricsurl发起写请求的总耗时秒按query_key、scheduler_alias、preset标注自 v1.30.1 起成功的与已处理失败的尝试含连接重试均会被观测vmanomaly_writer_responses旧名vmanomaly_writer_response_countCounter按 HTTP 状态码code统计的响应计数code也取值connection_error、timeout、ssl_error、io_errorvmanomaly_writer_sent_bytesCounter向 VictoriaMetrics 发送的总字节数vmanomaly_writer_request_serialize_secondsHistogram数据序列化耗时秒vmanomaly_writer_datapoints_sentCounter发送的总数据点数量vmanomaly_writer_timeseries_sentCounter发送的总时间序列数量这些指标可通过monitoring.pull暴露/metrics端点或monitoring.push周期性推送到指定 URL两种方式采集。从源码结构看写入请求的序列化耗时与预处理的序列数量在请求失败前就已记录而sent_bytes与datapoints仅在成功响应后累加——这意味着监控指标能如实反映成功写入与尝试写入的差别便于区分因重试导致的指标波动。对应地Writer 日志中Cannot write N points for QUERY前缀的报错会附带 SSL / 连接 / 超时 / I/O 原因Connection error while writing ... reinitializing session and retrying则代表一次可重试的连接失败。实战在 vmanomaly 中配置并验证 Writer将上述知识点落到部署层面完整的vmanomaly配置含 Reader、Models、Scheduler 与 Writer可以参考 docs/anomaly-detection/components/README.md 与 docs/anomaly-detection/QuickStart.md 中的示例。一个最小的 Writer 段只需指定写入目标与指标模板writer: class: vm # use VictoriaMetrics as a data destination datasource_url: http://victoriametrics:8428/ # [YOUR_DATASOURCE_URL] # optional tenant ID # tenant_id: 0:0 metric_format: __name__: $VAR for: $QUERY_KEY部署与验证步骤建议如下用--dryRun校验配置vmanomaly在启动时会做配置校验自 v1.7.2 起。官方推荐在正式启动前使用--dryRun标志该参数仅做解析、合并与 schema 校验无需 license可尽早发现writer段中如metric_format缺__name__、datasource_url笔误等问题。命令行参数细节见 docs/anomaly-detection/QuickStart.md 的 command-line arguments 小节。Docker Compose 部署仓库提供了一整套 vmanomaly vmagent VictoriaMetrics vmalert Grafana 的集成示例见 deployment/docker/vmanomaly/vmanomaly-integration/compose.yml其中 vmanomaly 服务将配置文件挂载为/config.yaml命令形如[/config.yaml, --licenseFile/license]并将 8490 端口暴露给 UI / API。查询验证写入结果启动后可在目标 VictoriaMetrics 上用 MetricsQL 查询由metric_format生成的序列如vmanomaly_anomaly_score结合for、自定义标签与原始标签做过滤确认异常分数已正确落库同时可通过vmanomaly_writer_datapoints_sent等自监控指标确认写入计数持续增长。可选开启热加载配合--watch参数与-configCheckInterval默认 30s 的内容轮询可在不重启服务的情况下调整writer等配置段vmanomaly_config_reloads_total指标会以statussuccess或statusfailure记录每次重载结果。小结WriterVmWriter是vmanomaly异常检测流水线的收尾环节它决定了异常检测结果以什么名字、什么标签、以怎样的传输策略进入 VictoriaMetrics。掌握metric_format的$VAR/$QUERY_KEY占位符与自定义标签用法理解tenant_id多租户语义与 mTLS 证书配置并善用batch_max_series、batch_max_bytes、connection_retry_attempts等传输调优参数以及vmanomaly_writer_*自监控指标就能构建一条可靠、可观测、可扩展的异常检测结果落库链路。【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 VictoriaMetrics vmanomaly Writer 组件详解：VmWriter 配置、指标格式化与多租户写入实践
VictoriaMetrics vmanomaly Writer 组件详解VmWriter 配置、指标格式化与多租户写入实践【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetricsVictoriaMetrics Anomaly Detectionvmanomaly通过 Reader、Models、Scheduler、Writer 等组件构成完整的异常检测闭环其中 Writer 组件负责将模型产出的异常分数anomaly score等结果序列写回 VictoriaMetrics是整个流水线的出口。本文以仓库文档 docs/anomaly-detection/components/writer.md 为主体结合组件总览、模型输出定义、自监控指标与部署示例系统讲解 VmWriter 的全部配置参数、metric_format指标命名规则、多租户写入行为与 mTLS 保护帮助你在生产环境中正确配置并验证异常检测结果的落库链路。Writer 在 vmanomaly 组件体系中的定位vmanomaly服务在启动时会解析配置文件其中writer是必需的配置段之一详见 docs/anomaly-detection/components/README.md。整个数据流可以概括为Reader从 VictoriaMetrics 的/query_range等端点按调度器Scheduler拉取历史与增量数据Models在 fit / infer 阶段对每条时间序列计算异常分数与预测区间Writer将模型输出序列anomaly_score、yhat、yhat_lower、yhat_upper、y等写回 VictoriaMetrics供 Grafana 仪表盘、vmalert 告警规则等下游消费。Writer 的核心设计目标是平滑地对接 VictoriaMetrics 生态它在写入结果时保留输入数据自带的标签集labelset并可选地附加额外的标签如查询别名、配置来源等使异常检测结果能够与原始指标天然关联、便于按维度聚合与告警。官方文档同时说明未来版本会引入更多数据导出方式但目前vmanomaly主要采用 VmWriter 完成数据导出。VM writer 概述VmWriter是vmanomaly内置的、面向 VictoriaMetrics / Prometheus 兼容写入协议的结果导出器。它默认使用 VictoriaMetrics 的导入接口/api/v1/import该参数自 v1.19.2 起已被弃用默认路径自动生效将模型输出以 Prometheus 文本协议NDJSON 序列化批量提交并具备连接重试、批量拆分、跨周期前缀缓存等生产级能力。组件类名支持短别名引用自 v1.13.0 起writer.vm.VmWriter可以简写为vm在更早的版本中必须书写完整类名。如果配置中省略class字段VmWriter是默认选项。配置参数总览下表汇总了VmWriter的全部配置参数以 docs/anomaly-detection/components/writer.md 为准参数示例说明classwriter.vm.VmWriter或vm启用写入 VictoriaMetrics / Prometheus 所需的类名。自 v1.13.0 起支持短别名vm未指定时默认使用VmWriterdatasource_urlhttp://localhost:8481/数据源写入目标URL 地址tenant_id0:0、multitenant仅适用于 VictoriaMetrics Cluster 版本。租户由accountID或accountID:projectID标识自 v1.16.2 起支持multitenant端点用于跨多个租户写入详见下方多租户支持一节metric_format__name__: vmanomaly_$VAR输出指标的命名与标签模板。必须包含__name__键且其值必须包含$VAR占位符以区分不同输出序列。支持占位符$VAR模型提供的变量与$QUERY_KEY查询别名其余键为用户自定义标签详见指标格式化一节import_json_path/api/v1/import可选用于覆盖默认导入路径。自 v1.19.2 起已弃用health_path/health可选探测数据源可用性的绝对或相对 URL 路径用于覆盖默认的/healthuserUSERNAMEBasicAuth 用户名passwordPASSWORDBasicAuth 密码timeout5s请求超时时间以字符串形式传入verify_tlsfalse是否校验 TLS 证书。False时不校验True时使用系统 CA 存储校验传入 CA 捆绑文件路径如ca.crt时使用该 CA 捆绑校验tls_cert_filepath/to/cert.crt客户端证书文件路径如client.crt自 v1.16.3 起可用用于 mTLStls_key_filepath/to/key.crt客户端证书私钥文件路径如client.key自 v1.16.3 起可用用于 mTLSbearer_tokentoken以标准格式通过请求头传递的令牌Authorization: bearer {token}bearer_token_filepath_to_file存放令牌的文件路径同样以Authorization: bearer {token}请求头传递自 v1.15.9 起可用connection_retry_attempts1连接失败时的重试次数自 v1.29.2 起可用默认1batch_max_series1000单次 VictoriaMetrics 导入请求中输出时间序列的最大数量自 v1.30.3 起可用更大的推理输出会被拆分为多个请求默认1000batch_max_bytes4194304单次导入请求序列化后的最大字节数软上限自 v1.30.3 起可用单条不可分割的 NDJSON 时间序列可能超过此软界默认 4 MiB4194304metric_prefix_cache_max_entries10000跨写入周期保留的预构建指标-标签前缀缓存条目数上限自 v1.30.3 起可用设为0可禁用跨周期前缀缓存默认10000完整配置示例以下为官方给出的VmWriter配置示例可直接放入vmanomaly配置文件的writer段writer: class: vm # or writer.vm.VmWriter until v1.13.0 datasource_url: http://localhost:8428/ tenant_id: 0:0 metric_format: __name__: vmanomaly_$VAR for: $QUERY_KEY run: test_metric_format config: io_vm_single.yaml import_json_path: /api/v1/import health_path: health user: foo password: bar connection_retry_attempts: 2 # if not specified, it will be 1 by default batch_max_series: 1000 # maximum series per VictoriaMetrics import request batch_max_bytes: 4194304 # soft maximum serialized request size (4 MiB) metric_prefix_cache_max_entries: 10000 # set to 0 to disable cross-cycle caching其中datasource_url指向接收写入的 VictoriaMetrics 单机实例如http://victoriametrics:8428/在 Docker Compose 部署中通常直接使用服务名作为主机名见 deployment/docker/vmanomaly/vmanomaly-integration/compose.yml 中的 vmanomaly 服务。提示batch_max_series与batch_max_bytes用于控制写入请求的粒度。当模型输出时间序列规模很大时vmanomaly会按这两个边界自动拆分请求避免单个导入请求过大导致写入端内存压力或超时metric_prefix_cache_max_entries则通过跨周期缓存预构建的指标前缀来降低重复序列化的开销在高基数场景下可根据内存预算调优。Metrics formatting 指标格式化metric_format是 Writer 配置中最核心的业务字段它决定了模型输出序列在写回 VictoriaMetrics 时使用什么指标名与标签。配置中必须设置两个必填参数__name__和for。__name__: PREFIX1_$VAR for: PREFIX2_$QUERY_KEY其作用机制如下__name__指标名模板$VAR占位符会被替换为模型输出的变量名例如PREFIX1_anomaly_score、PREFIX1_yhat_lower、PREFIX1_yhat、PREFIX1_yhat_upper、PREFIX1_y等。这些变量名的完整定义见 docs/anomaly-detection/components/models.md 的 vmanomaly output 小节其中anomaly_score是主指标0.0 ~ 1.0 表示正常大于 1.0 通常判定为异常告警阈值可另行调整yhat为预测期望值yhat_lower/yhat_upper为预测下/上边界y为查询返回的原始值。不同模型还可能提供额外输出如 Prophet 的trend、seasonalitySeasonal Trend Decomposition 的resid等这些变量同样可通过$VAR映射。for查询标签模板$QUERY_KEY占位符会被替换为查询别名即 reader 配置queries段中定义的 key。例如 reader 中定义了queries: {query_name_1: ..., query_name_2: ...}则输出会带上标签forPREFIX2_query_name_1、forPREFIX2_query_name_2从而把异常分数与具体的输入查询关联起来。除了以上两个必填模板你还可以指定任意自定义标签键值对custom_label_1: label_name_1 custom_label_2: label_name_2一个完整的metric_format示例及其效果metric_format: __name__: PREFIX1_$VAR for: PREFIX2_$QUERY_KEY custom_label_1: label_name_1 custom_label_2: label_name_2假设输入数据自带标签cpu1, deviceeth0, instancenode-exporter:9100这些标签来自 docs/anomaly-detection/components/reader.md 中queries返回的指标则最终写回的指标形如{__name__PREFIX1_anomaly_score, forPREFIX2_query_name_1, custom_label_1label_name_1, custom_label_2label_name_2, cpu1, deviceeth0, instancenode-exporter:9100} {__name__PREFIX1_yhat_lower, forPREFIX2_query_name_1, custom_label_1label_name_1, custom_label_2label_name_2, cpu1, deviceeth0, instancenode-exporter:9100} {__name__PREFIX1_anomaly_score, forPREFIX2_query_name_2, custom_label_1label_name_1, custom_label_2label_name_2, cpu1, deviceeth0, instancenode-exporter:9100} {__name__PREFIX1_yhat_lower, forPREFIX2_query_name_2, custom_label_1label_name_1, custom_label_2label_name_2, cpu1, deviceeth0, instancenode-exporter:9100}可以看到输入指标自带的标签cpu、device、instance被完整保留同时叠加了模板标签__name__、for与自定义标签。这一特性使得 Grafana 仪表盘与 vmalert 告警规则可以直接沿用原始指标的维度体系对异常分数做切片分析。官方建议为metric_format添加for标签以获得更平滑的异常分数仪表盘可视化体验见 docs/anomaly-detection/QuickStart.md 的配置建议。多租户支持多租户写入仅适用于VictoriaMetrics Cluster 版本。租户由accountID或accountID:projectID标识自 v1.15.9 起支持multitenant端点可在单个 Writer 配置下将数据写入多个租户详细的多租户概念可参考仓库中 docs/victoriametrics/Cluster-VictoriaMetrics.md 的多租户章节。根据writer.tenant_id取值与结果标签集中是否携带多租户标签实际行为分为四种情况writer.tenant_id ! multitenant如0:0且reader.tenant_id ! multitenant可为不同但合法的值如0:1vm_account_id标签在 Reader 侧不会被创建、不会持久化到 Writer也不会出现在输出中结果数据正常写入无日志、无报错。writer.tenant_id multitenant且标签集中存在vm_project_id这通常发生在reader.tenant_id也设为multitenant时——Reader 查询返回的结果中会携带vm_account_id标签结果一切按预期工作数据正常写入无日志、无报错。writer.tenant_id multitenant但标签集中缺少vm_account_id例如 Reader 侧做了聚合、或查询中缺少keep_metric_names结果数据仍会写入默认租户0:0但会抛出如下警告The label vm_account_id was not found in the label set of {query_result.key}, but tenant_idmultitenant is set in writer. The data will be written to the default tenant 0:0. Ensure that the query retains the necessary multi-tenant labels, or adjust the aggregation settings to preserve vm_account_id key in the label set.writer.tenant_id ! multitenant如0:0但标签集中存在vm_account_id结果写入被允许但会抛出如下警告The label set for the metric {query_result.key} contains multi-tenancy labels, but the write endpoint is configured for single-tenant mode (tenant_id ! multitenant). Either adjust the query in the reader to avoid multi-tenancy labels or ensure that reserved key vm_account_id is not explicitly set for single-tenant environments.简而言之vm_account_id/vm_project_id是保留标签其语义必须与writer.tenant_id的配置模式保持一致。在multitenant模式下务必让 Reader 的查询保留多租户路由标签避免聚合吞掉它们在单租户模式下则不要显式设置vm_account_id。这一行为在 docs/anomaly-detection/components/monitoring.md 的 Reader / Writer 日志章节中也有对应描述——The label vm_account_id was not found警告即意味着multitenantWriter 将回退到租户0:0。mTLS 保护自 v1.16.3 起vmanomaly的 VmWriter 等组件支持mTLS双向 TLS用于与启用了 mTLS 的 VictoriaMetrics Enterprise 实例建立安全通信实现客户端与服务端之间的双向证书身份校验防止未授权访问。mTLS 相关的配置参数为verify_tls若传入字符串其作用等价于 VictoriaMetrics 的-mtlsCAFile命令行参数指定 CA 捆绑文件设为True则使用系统默认证书存储tls_cert_file客户端证书路径等价于 VictoriaMetrics 的-tlsCertFiletls_key_file客户端证书私钥路径类似-tlsKeyFile。配置示例完整参数解析见 docs/anomaly-detection/components/reader.md 的 mTLS protection 一节该节对 Reader / Writer / Monitoring 各组件给出了一致的配置原则writer: class: vm datasource_url: https://your-victoriametrics-instance-with-mtls tenant_id: 0:0 verify_tls: path/to/ca.crt # path to CA bundle for TLS verification tls_cert_file: path/to/client.crt # path to the client certificate tls_key_file: path/to/client.key # path to the client certificate key需要注意的是verify_tls的三种取值语义分别对应False不校验证书、True使用系统 CA 存储校验、CA 文件路径使用指定的 CA 捆绑校验。写入行为的自监控指标VmWriter 会暴露一组健康与行为指标详细定义见 docs/anomaly-detection/components/monitoring.md 的 Writer behaviour metrics 小节用于观测写入链路的状态。自 v1.17.0 起这些指标统一增加了scheduler_alias与preset标签以适配多调度器场景且请求耗时类指标由Summary改为Histogram以支持分位数计算指标类型说明vmanomaly_writer_request_duration_secondsHistogram向 VictoriaMetricsurl发起写请求的总耗时秒按query_key、scheduler_alias、preset标注自 v1.30.1 起成功的与已处理失败的尝试含连接重试均会被观测vmanomaly_writer_responses旧名vmanomaly_writer_response_countCounter按 HTTP 状态码code统计的响应计数code也取值connection_error、timeout、ssl_error、io_errorvmanomaly_writer_sent_bytesCounter向 VictoriaMetrics 发送的总字节数vmanomaly_writer_request_serialize_secondsHistogram数据序列化耗时秒vmanomaly_writer_datapoints_sentCounter发送的总数据点数量vmanomaly_writer_timeseries_sentCounter发送的总时间序列数量这些指标可通过monitoring.pull暴露/metrics端点或monitoring.push周期性推送到指定 URL两种方式采集。从源码结构看写入请求的序列化耗时与预处理的序列数量在请求失败前就已记录而sent_bytes与datapoints仅在成功响应后累加——这意味着监控指标能如实反映成功写入与尝试写入的差别便于区分因重试导致的指标波动。对应地Writer 日志中Cannot write N points for QUERY前缀的报错会附带 SSL / 连接 / 超时 / I/O 原因Connection error while writing ... reinitializing session and retrying则代表一次可重试的连接失败。实战在 vmanomaly 中配置并验证 Writer将上述知识点落到部署层面完整的vmanomaly配置含 Reader、Models、Scheduler 与 Writer可以参考 docs/anomaly-detection/components/README.md 与 docs/anomaly-detection/QuickStart.md 中的示例。一个最小的 Writer 段只需指定写入目标与指标模板writer: class: vm # use VictoriaMetrics as a data destination datasource_url: http://victoriametrics:8428/ # [YOUR_DATASOURCE_URL] # optional tenant ID # tenant_id: 0:0 metric_format: __name__: $VAR for: $QUERY_KEY部署与验证步骤建议如下用--dryRun校验配置vmanomaly在启动时会做配置校验自 v1.7.2 起。官方推荐在正式启动前使用--dryRun标志该参数仅做解析、合并与 schema 校验无需 license可尽早发现writer段中如metric_format缺__name__、datasource_url笔误等问题。命令行参数细节见 docs/anomaly-detection/QuickStart.md 的 command-line arguments 小节。Docker Compose 部署仓库提供了一整套 vmanomaly vmagent VictoriaMetrics vmalert Grafana 的集成示例见 deployment/docker/vmanomaly/vmanomaly-integration/compose.yml其中 vmanomaly 服务将配置文件挂载为/config.yaml命令形如[/config.yaml, --licenseFile/license]并将 8490 端口暴露给 UI / API。查询验证写入结果启动后可在目标 VictoriaMetrics 上用 MetricsQL 查询由metric_format生成的序列如vmanomaly_anomaly_score结合for、自定义标签与原始标签做过滤确认异常分数已正确落库同时可通过vmanomaly_writer_datapoints_sent等自监控指标确认写入计数持续增长。可选开启热加载配合--watch参数与-configCheckInterval默认 30s 的内容轮询可在不重启服务的情况下调整writer等配置段vmanomaly_config_reloads_total指标会以statussuccess或statusfailure记录每次重载结果。小结WriterVmWriter是vmanomaly异常检测流水线的收尾环节它决定了异常检测结果以什么名字、什么标签、以怎样的传输策略进入 VictoriaMetrics。掌握metric_format的$VAR/$QUERY_KEY占位符与自定义标签用法理解tenant_id多租户语义与 mTLS 证书配置并善用batch_max_series、batch_max_bytes、connection_retry_attempts等传输调优参数以及vmanomaly_writer_*自监控指标就能构建一条可靠、可观测、可扩展的异常检测结果落库链路。【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考