VictoriaMetrics 异常检测与告警实战vmanomaly 集成 vmalert、Alertmanager 与 Grafana 完整指南【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics本篇技术指南以 VictoriaMetrics 开源仓库中「Anomaly Detection and Alerting Setup」教程为主体系统讲解企业级组件vmanomalyVictoriaMetrics Anomaly Detection与vmalert告警引擎的完整集成方案。你将学会如何用 Docker Compose 一键搭建由 VictoriaMetrics Single-Node、vmagent、vmanomaly、vmalert、Alertmanager、Node Exporter 与 Grafana 组成的可观测性流水线如何基于 CPU 时序数据配置异常检测模型与 anomaly score 告警规则以及如何在 Grafana 中解读模型输出并验证告警触发。读完本指南你将具备一套开箱即用的「数据采集 → 异常评分 → 告警通知 → 可视化」完整链路实战能力。本文所有配置文件均可在仓库 deployment/docker/vmanomaly/vmanomaly-integration/ 目录下找到对应实体其中compose.yml、vmanomaly_config.yml、vmalert_config.yml、prometheus.yml、alertmanager.yml与文档示例一脉相承可直接对照使用。上图展示了本教程的典型 vmanomaly 可观测性管道监控目标如 Node Exporter→ vmagent 抓取 → VictoriaMetrics 存储 → vmanomaly 读取时序并计算异常分数 → 写回 VictoriaMetrics → vmalert 基于 anomaly score 触发告警 → Alertmanager 处理通知 → Grafana 可视化。1. 前置条件与组件清单开始之前需要准备以下环境与组件vmanomaly 许可证vmanomaly 属于 VictoriaMetrics 企业包的一部分使用前需要 license key。可以从 VictoriaMetrics 企业试用页面申请试用 key用于本教程或企业生产使用。VictoriaMetrics 组件本教程使用 v1.151.0 版本VictoriaMetrics Single-Node时序数据库vmalert告警引擎vmagent指标采集与远程写入代理Grafana v12.2.0可视化与看板工具Docker 与 Docker Compose容器编排运行环境Node Exporter v1.9.1与Alertmanager v0.28.1分别为节点指标暴露器与告警通知服务从 v1.13.0 起vmanomaly 内置了node-exporter观测性预设preset相关用法可参考 docs/anomaly-detection/Presets.md 中的 node-exporter 章节本教程仍以手写配置的方式讲解完整原理。2. 什么是 vmanomalyVictoriaMetrics Anomaly Detection简称 vmanomaly是一个持续扫描 VictoriaMetrics 中时序数据的服务它通过用户可配置的机器学习模型实时检测数据模式中未预期的变化。服务的全部参数都定义在一个配置文件YAML中。vmanomaly 的核心工作循环是周期性地查询用户指定的指标通过reader从 VictoriaMetrics 拉取对查询结果计算anomaly score异常分数将计算出的anomaly score 推回 VictoriaMetrics通过writer写入。vmanomaly 的配置体系具备良好的演进性从v1.10.0开始单个配置文件可以声明多个模型类型无需再为不同模型分别运行多个 vmanomaly 进程详见 models 组件文档从v1.11.0开始每个模型还可以挂载到一个或多个scheduler上从而在同一进程内让不同模型搭配不同的调度策略详见 scheduler 组件文档 与 models 组件文档。2.1 什么是 anomaly scoreAnomaly score是一个计算得出的非负数值取值区间为 [0, inf)。它综合衡量了数据点对预测分布的拟合程度、周期性模式、趋势、季节性等因素。该值的判读设计如下当模型认为数据点遵循正常模式时分值落在 0 到 1 之间当数据点异常时分值超过 1。随后用户就可以借助 vmalert 基于anomaly score配置告警规则例如anomaly_score 1.0实现智能告警。3. 什么是 vmalertvmalert 是 VictoriaMetrics 的告警工具。它针对配置的-datasource.url执行一组给定的告警规则或预计算recording规则。其中告警规则alerting rules允许你定义当满足某种条件时通知用户。告警条件通过 MetricsQL 查询语言以表达式形式定义。以本教程为例表达式anomaly_score 1.0会在计算出的异常分数超过阈值1.0时通知用户。4. vmanomaly 与 vmalert 如何协同工作与传统告警规则相比异常检测更加放手且数据感知data-aware传统告警需要用户在事前想清楚哪些关键条件需要监控例如 CPU 90%这要求对系统行为有充分的预判而异常检测则捕捉任何偏离历史行为模式的偏差无需预先穷举可能的故障形态。因此一个非常实用的组合是把 vmanomaly 生成的 anomaly score 作为告警规则的输入并设定合适的阈值。这样你无需提前知道什么样的值算异常模型会基于数据自己学习正常的边界。本教程的实践目标配置包含全部所需服务的 docker-compose 文件VictoriaMetrics Single-Node、vmalert、vmagent、Grafana、Node Exporter 和 vmanomaly深入解析 vmanomaly 与 vmalert 的配置文件运行自己的 VictoriaMetrics 数据库并抓取 Node Exporter 的指标数据在 Grafana 中探索待分析的数据查看 vmanomaly 的异常检测结果查看 vmalert 触发的告警。5. 待分析的数据本教程使用Node Exporter采集的 CPU 使用数据将其写入 VictoriaMetrics 数据库作为异常检测的输入。在 Node Exporter 的指标页面输出的一部分形如下文# HELP node_cpu_seconds_total Seconds the CPUs spent in each mode. # TYPE node_cpu_seconds_total counter node_cpu_seconds_total{cpu0,modeidle} 94965.14 node_cpu_seconds_total{cpu0,modeiowait} 51.25 node_cpu_seconds_total{cpu0,modeirq} 0 node_cpu_seconds_total{cpu0,modenice} 0 node_cpu_seconds_total{cpu0,modesoftirq} 1682.18 node_cpu_seconds_total{cpu0,modesteal} 0 node_cpu_seconds_total{cpu0,modesystem} 995.37 node_cpu_seconds_total{cpu0,modeuser} 12378.05 node_cpu_seconds_total{cpu1,modeidle} 94386.53 node_cpu_seconds_total{cpu1,modeiowait} 51.22 ...在这个场景中node_cpu_seconds_total提供了每个 CPU 核心在各运行模式下所耗费时间的详细拆解。这些模式包括user、system、iowait、idle、irqsoftirq、guest和steal。这几种模式互斥各自反映不同的 CPU 活动特征。例如iowait占比偏高 → 暗示磁盘或网络瓶颈user或system数值升高 → 表示显著的 CPU 利用率。node_cpu_seconds_total属于counter计数器类型指标。要分析每个 CPU 核心在各个模式下的耗时比例需要先用 rate 函数 计算每秒的变化率rate(node_cpu_seconds_total)。为了按模式得到更平滑的聚合结果再叠加sum函数。最终查询表达式为sum(rate(node_cpu_seconds_total[5m])) by (mode, instance, job)下图是该查询在 Grafana 中的示例可视化该查询会产出8 条时序每个 CPU 模式各一条。由于使用了by聚合时序数量不受 CPU 核心数影响。这些时序将作为 vmanomaly 的输入——服务会对每一条时序独立拟合一份所配置模型类型的实例。6. vmanomaly 配置与参数详解6.1 配置文件的五大区块vmanomaly 的配置文件包含以下核心区块scheduler决定模型推理inference与训练fit的频率以及模型训练所使用的时间范围。从 v1.11.0 起单个配置中支持为每个模型类型配置多个独立的 scheduler详见 scheduler 组件文档models定义用于异常检测的模型及其具体参数。从 v1.10.0 起单个配置支持多个模型配置详见 models 组件文档reader规定数据读取的方式与数据源位置详见 reader 组件文档writer指定生成输出的写入目标与写入方式详见 writer 组件文档monitoring可选描述如何监控与暴露 vmanomaly 自身的健康检查指标详见 monitoring 组件文档。6.2 各区块核心参数说明schedulers本教程使用 PeriodicSchedulerinfer_every指定已训练模型对新数据执行推理的频率本质上是决定多久生成一个新的 anomaly score 数据点。格式示例30s、4m、2h、1d时间单位s秒、m分钟、h小时、d天。这个参数实际回答的问题是每隔一个固定周期例如每 1 分钟基于历史数据判断最新数据点是否异常。fit_every设置重新训练模型的频率。在线模型online models 会从每次推理批次中学习因此可设置较大的值如1000d使拟合仅在初始引导bootstrap时执行。若希望模型适应演变的行为可以配置模型的遗忘forgetting或反应性reactivity机制或选择有限的拟合节奏来重置累积状态。格式与infer_every类似。fit_window定义模型训练所用的数据时间区间。更长的窗口可以捕获更广泛的历史行为、更好地检测季节性模式但也可能降低模型对指标永久变化的响应速度并增加资源消耗。建议至少包含两个完整的季节性周期。格式示例3h表示使用三小时的数据。在仓库实际配置中使用了fit_window: 2w两周覆盖两个周级周期进行初始引导。modelsclass指定使用的模型。可选包括自定义模型或一系列内置模型。对于具有日历行为特征如小时级、周级波动的运维指标推荐使用在线模型Temporal Envelope。模型专属参数直接配置在模型别名之下见下文示例。关于本教程使用的temporal_envelope模型仓库 models 组件文档 给出了丰富的参数语义便于理解配置意图alpha默认0.005——趋势反应度Trend Reactivity。数值越高跟随持久性水平与趋势变化越快数值越低期望值越平稳。实践调参区间为0.0025~0.02。在 bootstrap-only 的拟合节奏下正是靠它来持续适应当前趋势loss_reactivity默认5.0——控制新偏差影响模型的容易程度。数值越高适应越快数值越低则削弱尖峰spike的影响。起始调参区间为1~5iqr_threshold默认2.0——主要的数据派生区间宽度控制。数值越高普通残差包络越宽、检测越少。实际实验区间为1~4seasonalities默认[hod_smooth, dow_smooth]——要建模的重复性日历模式。支持的小时级预设hod_smooth、hod_spiky、hod_plateau周级预设dow_smooth、dow_spiky、dow_plateau工作日/周末weekpart_plateau月度month_smooth、month_plateau。后缀描述预期分布形态smooth平滑渐变曲线、spiky窄相位尖峰、plateau持续日历水平provide_series限制写入 writer 的模型输出。例如默认可能产出[anomaly_score, yhat, yhat_lower, yhat_upper]配置provide_series: [anomaly_score]则只写回异常分数。readerdatasource_url数据源 URL通常是一个提供/api/v1/query_range的 HTTP 端点queries用于异常检测的 MetricsQLPromQL 的超集表达式。多个查询可写成QUERY_ALIAS: QUERY的形式其中QUERY_ALIAS会作为标签出现在生成的指标与异常分数中。仓库 reader 组件文档 还说明从 v1.13.0 起每个查询别名支持更细粒度的子字段如exprMetricsQL 表达式、step该查询的采样步长默认继承 reader 级sampling_period、data_range合法数据范围约束越界数据直接产生高分异常、detection_directionboth/above_expected/below_expected控制单边或双边检测、min_dev_from_expected/min_rel_dev_from_expected最小绝对/相对偏离阈值过滤微小波动、tz查询级时区对季节敏感模型尤其重要以及tenant_id集群版租户级查询隔离等可在需要时按业务策略逐查询定制。writerdatasource_url输出数据的端点通常是一个提供/api/v1/import的 HTTP 端点。仓库 writer 组件文档 还提到class默认vm即 VmWriter、集群版的tenant_id如0:0、multitenant以及metric_format自定义输出指标名格式如__name__: vmanomaly_$VAR等参数。monitoring可选pull模式下的addr与port用于启用/metrics端点暴露 vmanomaly 自身的健康检查指标供 vmagent 抓取。6.3 完整配置示例vmanomaly_config.yml下面是一份完整的vmanomaly_config.yml示例与仓库 deployment/docker/vmanomaly/vmanomaly-integration/vmanomaly_config.yml 保持一致仅将fit_window由2w展开为等价的14d并补充注释schedulers: periodic: infer_every: 1m fit_every: 1000d # bootstrap-only schedule; use a finite cadence if accumulated state must be reset fit_window: 14d # two weekly cycles for initial bootstrap models: temporal_envelope: class: temporal_envelope alpha: 0.005 # adapt the trend while using the bootstrap-only fit schedule loss_reactivity: 5 # allow new deviations to update the envelope seasonalities: [hod_smooth, dow_smooth] provide_series: [anomaly_score, y, yhat, yhat_lower, yhat_upper] 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: # Enable /metrics endpoint. addr: 0.0.0.0 port: 8490配置要点解读schedulers.periodic每1 分钟推理一次infer_every而拟合采用bootstrap-only策略fit_every: 1000d用14 天两个周级周期的历史数据进行初始训练models.temporal_envelope挂载到全部查询未显式指定queries时默认作用于 reader 中所有查询alpha、loss_reactivity、seasonalities共同定义了包络的自适应行为reader.sampling_period: 60s与infer_every: 1m匹配确保每次推理都有新的数据点monitoring.pull在8490端口暴露/metrics与下文prometheus.yml中vmanomaly:8490的抓取目标对应。注意从 v1.30.2 起data_range、detection_direction、min_dev_from_expected、min_rel_dev_from_expected等 KPI 策略应配置在reader.queries.alias下模型级配置仅作为查询未显式定义时的兼容性回退。7. vmanomaly 的输出指标运行 vmanomaly 后它会产出以下指标anomaly_score—— 核心指标。理想情况下介于 0.0 与 1.0 之间视为正常大于 1.0 视为异常当然你可以在告警配置中重新定义阈值yhat—— 预测的期望值yhat_lower—— 预测下边界yhat_upper—— 预测上边界y—— 初始查询结果值。输出指标写入 VictoriaMetrics 的示例anomaly_score{fornode_cpu_rate, instancenode-exporter:9100, jobnode-exporter, modeidle} 0.85可以看到输出指标完整保留了输入查询by聚合产生的标签mode、instance、job并额外带有for标签标识来源查询别名此处为node_cpu_rate这使得在 Grafana 中能够按 CPU 模式分别查看异常分数。8. vmalert 告警配置以下是 vmalert 的配置文件vmalert_config.yml示例与仓库 deployment/docker/vmanomaly/vmanomaly-integration/vmalert_config.yml 一致groups: - name: AnomalyExample rules: - alert: HighAnomalyScore expr: anomaly_score 1.0 labels: severity: warning annotations: summary: Anomaly Score exceeded 1.0. sum(rate(node_cpu_seconds_total)) is showing abnormal behavior.在查询表达式expr中关键是基于 vmanomaly 生成的异常分数设定判定标准。通常anomaly score 介于 0.0 与 1.0 表示分析值处于正常行为范围内分数超过 1.0 则表明模型越来越确信观测值异常。如何选择恰当的阈值这取决于你的具体需求与数据上下文。一个有效的做法是可视化分析将anomaly_score指标与预测的期望区间由yhat_lower和yhat_upper界定一起绘制从而做出更明智的决策。本教程后续将用一个实战示例演示这一过程。9. Docker Compose 编排所有配置与docker-compose.yml均已收录在仓库 deployment/docker/vmanomaly/vmanomaly-integration/其中编排文件名为compose.yml目录下。本教程将运行以下服务vmanomaly—— VictoriaMetrics 异常检测服务victoriametrics—— VictoriaMetrics 时序数据库vmagent—— 指标采集代理从各种数据源采集指标、进行 relabel 与过滤并通过 Prometheus remote_write 协议存储到 VictoriaMetrics 或其它存储系统grafana—— 可视化工具node-exporter—— Prometheus Node Exporter暴露丰富的硬件与内核相关指标vmalert—— VictoriaMetrics 告警服务alertmanager—— 通知服务处理来自 vmalert 的告警。9.1 Grafana 配置创建数据源清单在provisioning/datasources/目录下创建名为datasource.yml的文件内容如下默认用户名/密码为admin:adminapiVersion: 1 datasources: - name: VictoriaMetrics type: prometheus access: proxy url: http://victoriametrics:8428 isDefault: true jsonData: prometheusType: Prometheus prometheusVersion: 2.24.0该文件对应仓库 provisioning/datasources/datasource.yml。定义看板提供器在provisioning/dashboards/目录下创建名为dashboard.yml的文件内容如下apiVersion: 1 providers: - name: Prometheus orgId: 1 folder: type: file options: path: /var/lib/grafana/dashboards该文件对应仓库 provisioning/dashboards/dashboard.yml。9.2 vmagent 抓取配置prometheus.yml创建prometheus.yml文件作为 vmagent 的抓取配置对应仓库 prometheus.ymlglobal: scrape_interval: 10s scrape_configs: - job_name: vmagent static_configs: - targets: - vmagent:8429 - job_name: vmalert static_configs: - targets: - vmalert:8880 - job_name: victoriametrics static_configs: - targets: - victoriametrics:8428 - job_name: node-exporter static_configs: - targets: - node-exporter:9100 - job_name: vmanomaly static_configs: - targets: - vmanomaly:8490该配置以10s间隔抓取全部 5 个目标其中vmanomaly:8490正是 vmanomaly 配置中monitoring.pull暴露的/metrics端点。9.3 vmanomaly 许可证挂载教程使用本地文件vmanomaly_license存储 license key仓库目录中已放置占位文件 vmanomaly_license使用时必须替换为有效许可证内容。更多许可选项请参阅 docs/anomaly-detection/QuickStart.md 的 Licensing 章节。9.4 Alertmanager 配置创建alertmanager.yml文件用于 Alertmanager 配置对应仓库 alertmanager.ymlroute: receiver: blackhole receivers: - name: blackhole本教程将告警路由到blackhole接收器丢弃通知便于专注演示告警生成过程生产环境应替换为邮件、Webhook、Slack 等真实接收器。9.5 完整 docker-compose.yml将以上全部内容整合到docker-compose.yml文件中与仓库 compose.yml 一致services: vmagent: container_name: vmagent image: victoriametrics/vmagent:v1.151.0 depends_on: - victoriametrics ports: - 8429:8429 volumes: - vmagentdata-guide-vmanomaly-vmalert:/vmagentdata - ./prometheus.yml:/etc/prometheus/prometheus.yml command: - --promscrape.config/etc/prometheus/prometheus.yml - --remoteWrite.urlhttp://victoriametrics:8428/api/v1/write networks: - vm_net restart: always victoriametrics: container_name: victoriametrics image: victoriametrics/victoria-metrics:v1.151.0 ports: - 8428:8428 volumes: - vmdata-guide-vmanomaly-vmalert:/storage command: - --storageDataPath/storage - --httpListenAddr:8428 - --vmalert.proxyURLhttp://vmalert:8880 - -search.disableCache1 # for guide only, do not use in production networks: - vm_net restart: always grafana: container_name: grafana image: grafana/grafana:12.2.0 depends_on: - victoriametrics ports: - 3000:3000 volumes: - grafanadata-guide-vmanomaly-vmalert:/var/lib/grafana - ./provisioning/datasources:/etc/grafana/provisioning/datasources - ./provisioning/dashboards:/etc/grafana/provisioning/dashboards - ./vmanomaly_guide_dashboard.json:/var/lib/grafana/dashboards/vmanomaly_guide_dashboard.json networks: - vm_net restart: always vmalert: container_name: vmalert image: victoriametrics/vmalert:v1.151.0 depends_on: - victoriametrics ports: - 8880:8880 volumes: - ./vmalert_config.yml:/etc/alerts/alerts.yml command: - --datasource.urlhttp://victoriametrics:8428/ - --remoteRead.urlhttp://victoriametrics:8428/ - --remoteWrite.urlhttp://victoriametrics:8428/ - --notifier.urlhttp://alertmanager:9093/ - --rule/etc/alerts/*.yml # display source of alerts in grafana - --external.urlhttp://127.0.0.1:3000 # grafana outside container # when copypaste the line be aware of $$ for escaping in $expr - --external.alert.sourceexplore?orgId1left[now-1h,now,VictoriaMetrics,{expr: },{mode:Metrics},{ui:[true,true,true,none]}] networks: - vm_net restart: always vmanomaly: container_name: vmanomaly image: victoriametrics/vmanomaly:v1.30.4 depends_on: - victoriametrics ports: - 8490:8490 networks: - vm_net restart: always volumes: - ./vmanomaly_config.yml:/config.yaml - ./vmanomaly_license:/license platform: linux/amd64 command: - /config.yaml - --licenseFile/license alertmanager: container_name: alertmanager image: prom/alertmanager:v0.28.1 volumes: - ./alertmanager.yml:/config/alertmanager.yml command: - --config.file/config/alertmanager.yml ports: - 9093:9093 networks: - vm_net restart: always node-exporter: image: quay.io/prometheus/node-exporter:v1.9.1 container_name: node-exporter ports: - 9100:9100 pid: host restart: unless-stopped networks: - vm_net volumes: vmagentdata-guide-vmanomaly-vmalert: {} vmdata-guide-vmanomaly-vmalert: {} grafanadata-guide-vmanomaly-vmalert: {} networks: vm_net:docker-compose.yml中几个值得注意的设计细节victoriametrics的--vmalert.proxyURLhttp://vmalert:8880让 Grafana 可以通过 VM 的数据源代理跳转到 vmalert 页面查看告警来源-search.disableCache1仅用于本教程生产环境请勿使用避免缓存影响实时查询演示vmalert的--external.alert.source用于在 Grafana 中展示告警来源跳转到 Explore 执行对应表达式注意复制该行时$$是对$expr的转义vmanomaly服务指定platform: linux/amd64以兼容部分环境下的镜像架构command第一个参数/config.yaml为配置文件路径--licenseFile/license指定许可证文件node-exporter使用pid: host以访问宿主机进程的 CPU 统计从而采集到真实的节点 CPU 数据。9.6 启动与验证在运行 docker-compose 之前请确保你的目录中包含所有必需文件docker-compose.ymlprometheus.ymlvmalert_config.ymlvmanomaly_config.ymlvmanomaly_license已替换为有效 licensealertmanager.ymlprovisioning/datasources/datasource.ymlprovisioning/dashboards/dashboard.ymlvmanomaly_guide_dashboard.jsonGrafana 指南看板对应仓库 vmanomaly_guide_dashboard.json这个 docker-compose 文件会拉取镜像、配置各个服务并一起启动它们。执行docker-compose up -d要检查 vmanomaly 是否正常运行可以查看其日志docker logs vmanomaly -f10. 查看模型结果要查看模型结果访问 Grafanalocalhost:3000。vmanomaly 需要一些时间生成足够的数据用于可视化。在 Grafana 的Vmanomaly Guide看板上针对每个 CPU 模式你可以查看初始查询结果 ——sum(rate(node_cpu_seconds_total[5m])) by (mode, instance, job)anomaly_score—— 异常分数yhat—— 预测值yhat_lower—— 预测下边界yhat_upper—— 预测上边界上述每个指标都会包含输入查询sum(rate(node_cpu_seconds_total[5m])) by (mode, instance, job)返回的相同标签。10.1 各指标的异常分数带对应标签查询anomaly_score上图为多模式聚合的异常分数面板可以对照你认为是异常的数据点检查异常分数是否偏高。如果分数与预期不符可以调整配置文件中的参数或尝试其它模型类型。你可能注意到大量数据点显示异常分数大于 1。这是符合预期的因为我们刚开始抓取并存储数据可用于训练的数据点不足。只需等待更长时间积累更多数据就能看出这个特定模型发现异常的能力。本教程的配置中设置了14 天两个周级周期的拟合窗口模型需要这些数据才能被正确拟合。10.2 上下边界与预测值查询yhat_lower、yhat_upper和yhat上图展示模型推理得出的正常指标值边界绿色曲线为预测值yhat黄色曲线为预测下边界蓝色阴影区域为预测上边界与下边界之间的包络。当真实值y突破该包络时模型即认为出现异常。10.3 告警查看在页面http://localhost:8880/vmalert/groups上可以看到我们配置的告警规则根据 vmalert 配置的规则当异常分数超过 1 时就会看到告警。在 Alert 标签页http://localhost:8880/vmalert/alerts上查看触发的告警11. 结论我们完整探索了VictoriaMetrics Anomaly Detectionvmanomaly与 vmalert 的集成与实际应用。本教程带你走过了异常检测所需的全部前置条件、环境搭建与配置步骤。核心要点如下理解 vmanomaly 与 vmalert我们讨论了 vmanomaly 与 vmalert 的功能以及它们如何各自独立工作、又如何协同检测时序数据中的异常——vmanomaly 负责数据感知地计算异常分数vmalert 负责基于分数触发告警实际的配置与部署通过 docker-compose 环境搭建演示了如何配置并运行 VictoriaMetrics 及其关联服务包括 vmanomaly 与 vmalert数据分析与监控指南提供了使用 Grafana 采集、分析与可视化数据的方法以及如何解读 vmanomaly 生成的异常分数等指标告警配置我们展示了如何基于异常分数在 vmalert 中配置与定制告警规则从而实现主动监控与对潜在问题的及时响应。在持续使用 VictoriaMetrics Anomaly Detection 与 vmalert 时请记住异常检测的效果很大程度上取决于所选模型的恰当性、配置的准确性以及所观察到的数据模式。本指南是一个起点鼓励你针对自身数据特点与业务场景尝试不同的配置与模型组合。若需进一步探索仓库中还提供了开箱即用的node-exporter观测性预设自 v1.13.0 起可用参见 docs/anomaly-detection/Presets.md 的 node-exporter 章节完整的组件参数手册则可参考 docs/anomaly-detection/components/README.md。【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
VictoriaMetrics 异常检测与告警实战：vmanomaly 集成 vmalert、Alertmanager 与 Grafana 完整指南
VictoriaMetrics 异常检测与告警实战vmanomaly 集成 vmalert、Alertmanager 与 Grafana 完整指南【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics本篇技术指南以 VictoriaMetrics 开源仓库中「Anomaly Detection and Alerting Setup」教程为主体系统讲解企业级组件vmanomalyVictoriaMetrics Anomaly Detection与vmalert告警引擎的完整集成方案。你将学会如何用 Docker Compose 一键搭建由 VictoriaMetrics Single-Node、vmagent、vmanomaly、vmalert、Alertmanager、Node Exporter 与 Grafana 组成的可观测性流水线如何基于 CPU 时序数据配置异常检测模型与 anomaly score 告警规则以及如何在 Grafana 中解读模型输出并验证告警触发。读完本指南你将具备一套开箱即用的「数据采集 → 异常评分 → 告警通知 → 可视化」完整链路实战能力。本文所有配置文件均可在仓库 deployment/docker/vmanomaly/vmanomaly-integration/ 目录下找到对应实体其中compose.yml、vmanomaly_config.yml、vmalert_config.yml、prometheus.yml、alertmanager.yml与文档示例一脉相承可直接对照使用。上图展示了本教程的典型 vmanomaly 可观测性管道监控目标如 Node Exporter→ vmagent 抓取 → VictoriaMetrics 存储 → vmanomaly 读取时序并计算异常分数 → 写回 VictoriaMetrics → vmalert 基于 anomaly score 触发告警 → Alertmanager 处理通知 → Grafana 可视化。1. 前置条件与组件清单开始之前需要准备以下环境与组件vmanomaly 许可证vmanomaly 属于 VictoriaMetrics 企业包的一部分使用前需要 license key。可以从 VictoriaMetrics 企业试用页面申请试用 key用于本教程或企业生产使用。VictoriaMetrics 组件本教程使用 v1.151.0 版本VictoriaMetrics Single-Node时序数据库vmalert告警引擎vmagent指标采集与远程写入代理Grafana v12.2.0可视化与看板工具Docker 与 Docker Compose容器编排运行环境Node Exporter v1.9.1与Alertmanager v0.28.1分别为节点指标暴露器与告警通知服务从 v1.13.0 起vmanomaly 内置了node-exporter观测性预设preset相关用法可参考 docs/anomaly-detection/Presets.md 中的 node-exporter 章节本教程仍以手写配置的方式讲解完整原理。2. 什么是 vmanomalyVictoriaMetrics Anomaly Detection简称 vmanomaly是一个持续扫描 VictoriaMetrics 中时序数据的服务它通过用户可配置的机器学习模型实时检测数据模式中未预期的变化。服务的全部参数都定义在一个配置文件YAML中。vmanomaly 的核心工作循环是周期性地查询用户指定的指标通过reader从 VictoriaMetrics 拉取对查询结果计算anomaly score异常分数将计算出的anomaly score 推回 VictoriaMetrics通过writer写入。vmanomaly 的配置体系具备良好的演进性从v1.10.0开始单个配置文件可以声明多个模型类型无需再为不同模型分别运行多个 vmanomaly 进程详见 models 组件文档从v1.11.0开始每个模型还可以挂载到一个或多个scheduler上从而在同一进程内让不同模型搭配不同的调度策略详见 scheduler 组件文档 与 models 组件文档。2.1 什么是 anomaly scoreAnomaly score是一个计算得出的非负数值取值区间为 [0, inf)。它综合衡量了数据点对预测分布的拟合程度、周期性模式、趋势、季节性等因素。该值的判读设计如下当模型认为数据点遵循正常模式时分值落在 0 到 1 之间当数据点异常时分值超过 1。随后用户就可以借助 vmalert 基于anomaly score配置告警规则例如anomaly_score 1.0实现智能告警。3. 什么是 vmalertvmalert 是 VictoriaMetrics 的告警工具。它针对配置的-datasource.url执行一组给定的告警规则或预计算recording规则。其中告警规则alerting rules允许你定义当满足某种条件时通知用户。告警条件通过 MetricsQL 查询语言以表达式形式定义。以本教程为例表达式anomaly_score 1.0会在计算出的异常分数超过阈值1.0时通知用户。4. vmanomaly 与 vmalert 如何协同工作与传统告警规则相比异常检测更加放手且数据感知data-aware传统告警需要用户在事前想清楚哪些关键条件需要监控例如 CPU 90%这要求对系统行为有充分的预判而异常检测则捕捉任何偏离历史行为模式的偏差无需预先穷举可能的故障形态。因此一个非常实用的组合是把 vmanomaly 生成的 anomaly score 作为告警规则的输入并设定合适的阈值。这样你无需提前知道什么样的值算异常模型会基于数据自己学习正常的边界。本教程的实践目标配置包含全部所需服务的 docker-compose 文件VictoriaMetrics Single-Node、vmalert、vmagent、Grafana、Node Exporter 和 vmanomaly深入解析 vmanomaly 与 vmalert 的配置文件运行自己的 VictoriaMetrics 数据库并抓取 Node Exporter 的指标数据在 Grafana 中探索待分析的数据查看 vmanomaly 的异常检测结果查看 vmalert 触发的告警。5. 待分析的数据本教程使用Node Exporter采集的 CPU 使用数据将其写入 VictoriaMetrics 数据库作为异常检测的输入。在 Node Exporter 的指标页面输出的一部分形如下文# HELP node_cpu_seconds_total Seconds the CPUs spent in each mode. # TYPE node_cpu_seconds_total counter node_cpu_seconds_total{cpu0,modeidle} 94965.14 node_cpu_seconds_total{cpu0,modeiowait} 51.25 node_cpu_seconds_total{cpu0,modeirq} 0 node_cpu_seconds_total{cpu0,modenice} 0 node_cpu_seconds_total{cpu0,modesoftirq} 1682.18 node_cpu_seconds_total{cpu0,modesteal} 0 node_cpu_seconds_total{cpu0,modesystem} 995.37 node_cpu_seconds_total{cpu0,modeuser} 12378.05 node_cpu_seconds_total{cpu1,modeidle} 94386.53 node_cpu_seconds_total{cpu1,modeiowait} 51.22 ...在这个场景中node_cpu_seconds_total提供了每个 CPU 核心在各运行模式下所耗费时间的详细拆解。这些模式包括user、system、iowait、idle、irqsoftirq、guest和steal。这几种模式互斥各自反映不同的 CPU 活动特征。例如iowait占比偏高 → 暗示磁盘或网络瓶颈user或system数值升高 → 表示显著的 CPU 利用率。node_cpu_seconds_total属于counter计数器类型指标。要分析每个 CPU 核心在各个模式下的耗时比例需要先用 rate 函数 计算每秒的变化率rate(node_cpu_seconds_total)。为了按模式得到更平滑的聚合结果再叠加sum函数。最终查询表达式为sum(rate(node_cpu_seconds_total[5m])) by (mode, instance, job)下图是该查询在 Grafana 中的示例可视化该查询会产出8 条时序每个 CPU 模式各一条。由于使用了by聚合时序数量不受 CPU 核心数影响。这些时序将作为 vmanomaly 的输入——服务会对每一条时序独立拟合一份所配置模型类型的实例。6. vmanomaly 配置与参数详解6.1 配置文件的五大区块vmanomaly 的配置文件包含以下核心区块scheduler决定模型推理inference与训练fit的频率以及模型训练所使用的时间范围。从 v1.11.0 起单个配置中支持为每个模型类型配置多个独立的 scheduler详见 scheduler 组件文档models定义用于异常检测的模型及其具体参数。从 v1.10.0 起单个配置支持多个模型配置详见 models 组件文档reader规定数据读取的方式与数据源位置详见 reader 组件文档writer指定生成输出的写入目标与写入方式详见 writer 组件文档monitoring可选描述如何监控与暴露 vmanomaly 自身的健康检查指标详见 monitoring 组件文档。6.2 各区块核心参数说明schedulers本教程使用 PeriodicSchedulerinfer_every指定已训练模型对新数据执行推理的频率本质上是决定多久生成一个新的 anomaly score 数据点。格式示例30s、4m、2h、1d时间单位s秒、m分钟、h小时、d天。这个参数实际回答的问题是每隔一个固定周期例如每 1 分钟基于历史数据判断最新数据点是否异常。fit_every设置重新训练模型的频率。在线模型online models 会从每次推理批次中学习因此可设置较大的值如1000d使拟合仅在初始引导bootstrap时执行。若希望模型适应演变的行为可以配置模型的遗忘forgetting或反应性reactivity机制或选择有限的拟合节奏来重置累积状态。格式与infer_every类似。fit_window定义模型训练所用的数据时间区间。更长的窗口可以捕获更广泛的历史行为、更好地检测季节性模式但也可能降低模型对指标永久变化的响应速度并增加资源消耗。建议至少包含两个完整的季节性周期。格式示例3h表示使用三小时的数据。在仓库实际配置中使用了fit_window: 2w两周覆盖两个周级周期进行初始引导。modelsclass指定使用的模型。可选包括自定义模型或一系列内置模型。对于具有日历行为特征如小时级、周级波动的运维指标推荐使用在线模型Temporal Envelope。模型专属参数直接配置在模型别名之下见下文示例。关于本教程使用的temporal_envelope模型仓库 models 组件文档 给出了丰富的参数语义便于理解配置意图alpha默认0.005——趋势反应度Trend Reactivity。数值越高跟随持久性水平与趋势变化越快数值越低期望值越平稳。实践调参区间为0.0025~0.02。在 bootstrap-only 的拟合节奏下正是靠它来持续适应当前趋势loss_reactivity默认5.0——控制新偏差影响模型的容易程度。数值越高适应越快数值越低则削弱尖峰spike的影响。起始调参区间为1~5iqr_threshold默认2.0——主要的数据派生区间宽度控制。数值越高普通残差包络越宽、检测越少。实际实验区间为1~4seasonalities默认[hod_smooth, dow_smooth]——要建模的重复性日历模式。支持的小时级预设hod_smooth、hod_spiky、hod_plateau周级预设dow_smooth、dow_spiky、dow_plateau工作日/周末weekpart_plateau月度month_smooth、month_plateau。后缀描述预期分布形态smooth平滑渐变曲线、spiky窄相位尖峰、plateau持续日历水平provide_series限制写入 writer 的模型输出。例如默认可能产出[anomaly_score, yhat, yhat_lower, yhat_upper]配置provide_series: [anomaly_score]则只写回异常分数。readerdatasource_url数据源 URL通常是一个提供/api/v1/query_range的 HTTP 端点queries用于异常检测的 MetricsQLPromQL 的超集表达式。多个查询可写成QUERY_ALIAS: QUERY的形式其中QUERY_ALIAS会作为标签出现在生成的指标与异常分数中。仓库 reader 组件文档 还说明从 v1.13.0 起每个查询别名支持更细粒度的子字段如exprMetricsQL 表达式、step该查询的采样步长默认继承 reader 级sampling_period、data_range合法数据范围约束越界数据直接产生高分异常、detection_directionboth/above_expected/below_expected控制单边或双边检测、min_dev_from_expected/min_rel_dev_from_expected最小绝对/相对偏离阈值过滤微小波动、tz查询级时区对季节敏感模型尤其重要以及tenant_id集群版租户级查询隔离等可在需要时按业务策略逐查询定制。writerdatasource_url输出数据的端点通常是一个提供/api/v1/import的 HTTP 端点。仓库 writer 组件文档 还提到class默认vm即 VmWriter、集群版的tenant_id如0:0、multitenant以及metric_format自定义输出指标名格式如__name__: vmanomaly_$VAR等参数。monitoring可选pull模式下的addr与port用于启用/metrics端点暴露 vmanomaly 自身的健康检查指标供 vmagent 抓取。6.3 完整配置示例vmanomaly_config.yml下面是一份完整的vmanomaly_config.yml示例与仓库 deployment/docker/vmanomaly/vmanomaly-integration/vmanomaly_config.yml 保持一致仅将fit_window由2w展开为等价的14d并补充注释schedulers: periodic: infer_every: 1m fit_every: 1000d # bootstrap-only schedule; use a finite cadence if accumulated state must be reset fit_window: 14d # two weekly cycles for initial bootstrap models: temporal_envelope: class: temporal_envelope alpha: 0.005 # adapt the trend while using the bootstrap-only fit schedule loss_reactivity: 5 # allow new deviations to update the envelope seasonalities: [hod_smooth, dow_smooth] provide_series: [anomaly_score, y, yhat, yhat_lower, yhat_upper] 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: # Enable /metrics endpoint. addr: 0.0.0.0 port: 8490配置要点解读schedulers.periodic每1 分钟推理一次infer_every而拟合采用bootstrap-only策略fit_every: 1000d用14 天两个周级周期的历史数据进行初始训练models.temporal_envelope挂载到全部查询未显式指定queries时默认作用于 reader 中所有查询alpha、loss_reactivity、seasonalities共同定义了包络的自适应行为reader.sampling_period: 60s与infer_every: 1m匹配确保每次推理都有新的数据点monitoring.pull在8490端口暴露/metrics与下文prometheus.yml中vmanomaly:8490的抓取目标对应。注意从 v1.30.2 起data_range、detection_direction、min_dev_from_expected、min_rel_dev_from_expected等 KPI 策略应配置在reader.queries.alias下模型级配置仅作为查询未显式定义时的兼容性回退。7. vmanomaly 的输出指标运行 vmanomaly 后它会产出以下指标anomaly_score—— 核心指标。理想情况下介于 0.0 与 1.0 之间视为正常大于 1.0 视为异常当然你可以在告警配置中重新定义阈值yhat—— 预测的期望值yhat_lower—— 预测下边界yhat_upper—— 预测上边界y—— 初始查询结果值。输出指标写入 VictoriaMetrics 的示例anomaly_score{fornode_cpu_rate, instancenode-exporter:9100, jobnode-exporter, modeidle} 0.85可以看到输出指标完整保留了输入查询by聚合产生的标签mode、instance、job并额外带有for标签标识来源查询别名此处为node_cpu_rate这使得在 Grafana 中能够按 CPU 模式分别查看异常分数。8. vmalert 告警配置以下是 vmalert 的配置文件vmalert_config.yml示例与仓库 deployment/docker/vmanomaly/vmanomaly-integration/vmalert_config.yml 一致groups: - name: AnomalyExample rules: - alert: HighAnomalyScore expr: anomaly_score 1.0 labels: severity: warning annotations: summary: Anomaly Score exceeded 1.0. sum(rate(node_cpu_seconds_total)) is showing abnormal behavior.在查询表达式expr中关键是基于 vmanomaly 生成的异常分数设定判定标准。通常anomaly score 介于 0.0 与 1.0 表示分析值处于正常行为范围内分数超过 1.0 则表明模型越来越确信观测值异常。如何选择恰当的阈值这取决于你的具体需求与数据上下文。一个有效的做法是可视化分析将anomaly_score指标与预测的期望区间由yhat_lower和yhat_upper界定一起绘制从而做出更明智的决策。本教程后续将用一个实战示例演示这一过程。9. Docker Compose 编排所有配置与docker-compose.yml均已收录在仓库 deployment/docker/vmanomaly/vmanomaly-integration/其中编排文件名为compose.yml目录下。本教程将运行以下服务vmanomaly—— VictoriaMetrics 异常检测服务victoriametrics—— VictoriaMetrics 时序数据库vmagent—— 指标采集代理从各种数据源采集指标、进行 relabel 与过滤并通过 Prometheus remote_write 协议存储到 VictoriaMetrics 或其它存储系统grafana—— 可视化工具node-exporter—— Prometheus Node Exporter暴露丰富的硬件与内核相关指标vmalert—— VictoriaMetrics 告警服务alertmanager—— 通知服务处理来自 vmalert 的告警。9.1 Grafana 配置创建数据源清单在provisioning/datasources/目录下创建名为datasource.yml的文件内容如下默认用户名/密码为admin:adminapiVersion: 1 datasources: - name: VictoriaMetrics type: prometheus access: proxy url: http://victoriametrics:8428 isDefault: true jsonData: prometheusType: Prometheus prometheusVersion: 2.24.0该文件对应仓库 provisioning/datasources/datasource.yml。定义看板提供器在provisioning/dashboards/目录下创建名为dashboard.yml的文件内容如下apiVersion: 1 providers: - name: Prometheus orgId: 1 folder: type: file options: path: /var/lib/grafana/dashboards该文件对应仓库 provisioning/dashboards/dashboard.yml。9.2 vmagent 抓取配置prometheus.yml创建prometheus.yml文件作为 vmagent 的抓取配置对应仓库 prometheus.ymlglobal: scrape_interval: 10s scrape_configs: - job_name: vmagent static_configs: - targets: - vmagent:8429 - job_name: vmalert static_configs: - targets: - vmalert:8880 - job_name: victoriametrics static_configs: - targets: - victoriametrics:8428 - job_name: node-exporter static_configs: - targets: - node-exporter:9100 - job_name: vmanomaly static_configs: - targets: - vmanomaly:8490该配置以10s间隔抓取全部 5 个目标其中vmanomaly:8490正是 vmanomaly 配置中monitoring.pull暴露的/metrics端点。9.3 vmanomaly 许可证挂载教程使用本地文件vmanomaly_license存储 license key仓库目录中已放置占位文件 vmanomaly_license使用时必须替换为有效许可证内容。更多许可选项请参阅 docs/anomaly-detection/QuickStart.md 的 Licensing 章节。9.4 Alertmanager 配置创建alertmanager.yml文件用于 Alertmanager 配置对应仓库 alertmanager.ymlroute: receiver: blackhole receivers: - name: blackhole本教程将告警路由到blackhole接收器丢弃通知便于专注演示告警生成过程生产环境应替换为邮件、Webhook、Slack 等真实接收器。9.5 完整 docker-compose.yml将以上全部内容整合到docker-compose.yml文件中与仓库 compose.yml 一致services: vmagent: container_name: vmagent image: victoriametrics/vmagent:v1.151.0 depends_on: - victoriametrics ports: - 8429:8429 volumes: - vmagentdata-guide-vmanomaly-vmalert:/vmagentdata - ./prometheus.yml:/etc/prometheus/prometheus.yml command: - --promscrape.config/etc/prometheus/prometheus.yml - --remoteWrite.urlhttp://victoriametrics:8428/api/v1/write networks: - vm_net restart: always victoriametrics: container_name: victoriametrics image: victoriametrics/victoria-metrics:v1.151.0 ports: - 8428:8428 volumes: - vmdata-guide-vmanomaly-vmalert:/storage command: - --storageDataPath/storage - --httpListenAddr:8428 - --vmalert.proxyURLhttp://vmalert:8880 - -search.disableCache1 # for guide only, do not use in production networks: - vm_net restart: always grafana: container_name: grafana image: grafana/grafana:12.2.0 depends_on: - victoriametrics ports: - 3000:3000 volumes: - grafanadata-guide-vmanomaly-vmalert:/var/lib/grafana - ./provisioning/datasources:/etc/grafana/provisioning/datasources - ./provisioning/dashboards:/etc/grafana/provisioning/dashboards - ./vmanomaly_guide_dashboard.json:/var/lib/grafana/dashboards/vmanomaly_guide_dashboard.json networks: - vm_net restart: always vmalert: container_name: vmalert image: victoriametrics/vmalert:v1.151.0 depends_on: - victoriametrics ports: - 8880:8880 volumes: - ./vmalert_config.yml:/etc/alerts/alerts.yml command: - --datasource.urlhttp://victoriametrics:8428/ - --remoteRead.urlhttp://victoriametrics:8428/ - --remoteWrite.urlhttp://victoriametrics:8428/ - --notifier.urlhttp://alertmanager:9093/ - --rule/etc/alerts/*.yml # display source of alerts in grafana - --external.urlhttp://127.0.0.1:3000 # grafana outside container # when copypaste the line be aware of $$ for escaping in $expr - --external.alert.sourceexplore?orgId1left[now-1h,now,VictoriaMetrics,{expr: },{mode:Metrics},{ui:[true,true,true,none]}] networks: - vm_net restart: always vmanomaly: container_name: vmanomaly image: victoriametrics/vmanomaly:v1.30.4 depends_on: - victoriametrics ports: - 8490:8490 networks: - vm_net restart: always volumes: - ./vmanomaly_config.yml:/config.yaml - ./vmanomaly_license:/license platform: linux/amd64 command: - /config.yaml - --licenseFile/license alertmanager: container_name: alertmanager image: prom/alertmanager:v0.28.1 volumes: - ./alertmanager.yml:/config/alertmanager.yml command: - --config.file/config/alertmanager.yml ports: - 9093:9093 networks: - vm_net restart: always node-exporter: image: quay.io/prometheus/node-exporter:v1.9.1 container_name: node-exporter ports: - 9100:9100 pid: host restart: unless-stopped networks: - vm_net volumes: vmagentdata-guide-vmanomaly-vmalert: {} vmdata-guide-vmanomaly-vmalert: {} grafanadata-guide-vmanomaly-vmalert: {} networks: vm_net:docker-compose.yml中几个值得注意的设计细节victoriametrics的--vmalert.proxyURLhttp://vmalert:8880让 Grafana 可以通过 VM 的数据源代理跳转到 vmalert 页面查看告警来源-search.disableCache1仅用于本教程生产环境请勿使用避免缓存影响实时查询演示vmalert的--external.alert.source用于在 Grafana 中展示告警来源跳转到 Explore 执行对应表达式注意复制该行时$$是对$expr的转义vmanomaly服务指定platform: linux/amd64以兼容部分环境下的镜像架构command第一个参数/config.yaml为配置文件路径--licenseFile/license指定许可证文件node-exporter使用pid: host以访问宿主机进程的 CPU 统计从而采集到真实的节点 CPU 数据。9.6 启动与验证在运行 docker-compose 之前请确保你的目录中包含所有必需文件docker-compose.ymlprometheus.ymlvmalert_config.ymlvmanomaly_config.ymlvmanomaly_license已替换为有效 licensealertmanager.ymlprovisioning/datasources/datasource.ymlprovisioning/dashboards/dashboard.ymlvmanomaly_guide_dashboard.jsonGrafana 指南看板对应仓库 vmanomaly_guide_dashboard.json这个 docker-compose 文件会拉取镜像、配置各个服务并一起启动它们。执行docker-compose up -d要检查 vmanomaly 是否正常运行可以查看其日志docker logs vmanomaly -f10. 查看模型结果要查看模型结果访问 Grafanalocalhost:3000。vmanomaly 需要一些时间生成足够的数据用于可视化。在 Grafana 的Vmanomaly Guide看板上针对每个 CPU 模式你可以查看初始查询结果 ——sum(rate(node_cpu_seconds_total[5m])) by (mode, instance, job)anomaly_score—— 异常分数yhat—— 预测值yhat_lower—— 预测下边界yhat_upper—— 预测上边界上述每个指标都会包含输入查询sum(rate(node_cpu_seconds_total[5m])) by (mode, instance, job)返回的相同标签。10.1 各指标的异常分数带对应标签查询anomaly_score上图为多模式聚合的异常分数面板可以对照你认为是异常的数据点检查异常分数是否偏高。如果分数与预期不符可以调整配置文件中的参数或尝试其它模型类型。你可能注意到大量数据点显示异常分数大于 1。这是符合预期的因为我们刚开始抓取并存储数据可用于训练的数据点不足。只需等待更长时间积累更多数据就能看出这个特定模型发现异常的能力。本教程的配置中设置了14 天两个周级周期的拟合窗口模型需要这些数据才能被正确拟合。10.2 上下边界与预测值查询yhat_lower、yhat_upper和yhat上图展示模型推理得出的正常指标值边界绿色曲线为预测值yhat黄色曲线为预测下边界蓝色阴影区域为预测上边界与下边界之间的包络。当真实值y突破该包络时模型即认为出现异常。10.3 告警查看在页面http://localhost:8880/vmalert/groups上可以看到我们配置的告警规则根据 vmalert 配置的规则当异常分数超过 1 时就会看到告警。在 Alert 标签页http://localhost:8880/vmalert/alerts上查看触发的告警11. 结论我们完整探索了VictoriaMetrics Anomaly Detectionvmanomaly与 vmalert 的集成与实际应用。本教程带你走过了异常检测所需的全部前置条件、环境搭建与配置步骤。核心要点如下理解 vmanomaly 与 vmalert我们讨论了 vmanomaly 与 vmalert 的功能以及它们如何各自独立工作、又如何协同检测时序数据中的异常——vmanomaly 负责数据感知地计算异常分数vmalert 负责基于分数触发告警实际的配置与部署通过 docker-compose 环境搭建演示了如何配置并运行 VictoriaMetrics 及其关联服务包括 vmanomaly 与 vmalert数据分析与监控指南提供了使用 Grafana 采集、分析与可视化数据的方法以及如何解读 vmanomaly 生成的异常分数等指标告警配置我们展示了如何基于异常分数在 vmalert 中配置与定制告警规则从而实现主动监控与对潜在问题的及时响应。在持续使用 VictoriaMetrics Anomaly Detection 与 vmalert 时请记住异常检测的效果很大程度上取决于所选模型的恰当性、配置的准确性以及所观察到的数据模式。本指南是一个起点鼓励你针对自身数据特点与业务场景尝试不同的配置与模型组合。若需进一步探索仓库中还提供了开箱即用的node-exporter观测性预设自 v1.13.0 起可用参见 docs/anomaly-detection/Presets.md 的 node-exporter 章节完整的组件参数手册则可参考 docs/anomaly-detection/components/README.md。【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
