企业官网建设流程全解析

VictoriaMetrics vmanomaly 组件配置完全指南：七大配置区块、数据流转与热重载实战

【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics

VictoriaMetrics Anomaly Detection（vmanomaly）是 VictoriaMetrics 生态中的智能异常检测服务，通过 YAML 配置将「数据读取—模型训练—调度推理—结果回写」串成一条完整的自动化流水线。本文以 components/README.md 为骨架，逐区块讲解settings、schedulers、models、reader、writer、monitoring、server七大配置区块的作用、必填/可选关系、最小可用配置、热重载机制与环境变量占位符，并结合仓库中的 reader.md、models.md、scheduler.md 等子文档给出源码级的参数细节。读完本文，你将能独立编写一份可运行的多对多 vmanomaly 配置，并掌握配置热更新与敏感信息注入的最佳实践。

七大配置区块：总览与必填/可选关系

vmanomaly的全部行为都由一份 YAML 配置驱动，配置按职责划分为七个独立区块，其中四个为必填、三个为可选：

有几点版本性约定值得注意（以当前仓库文档标注为准）：

• 自v1.7.2起，服务会在启动时对配置做校验，校验错误请查看容器日志，各字段说明见上方各区块文档。
• 自v1.13.0起，组件类支持用短别名代替完整导入路径，例如model.zscore.ZscoreModel可写为zscore，reader.vm.VmReader可写为vm，scheduler.periodic.PeriodicScheduler可写为periodic。本文所有示例均使用别名。
• 自v1.13.0起支持preset预设模式，见 Presets.md。

此外，Reader 与 Writer 还支持 多租户（multitenancy）：通过tenant_id参数可以分别从不同租户读取、向不同租户写入，适用于 VictoriaMetrics 集群版（详见 Cluster-VictoriaMetrics.md 的 Multitenancy 章节）。

组件交互与数据流向

下面这张图展示了vmanomaly各组件之间、以及与 VictoriaMetrics / VictoriaLogs / VictoriaTraces 数据源之间的交互关系（来源于仓库中的 vmanomaly-components-diagram.md）：

图中实线节点与箭头是必选的异常检测主链路，其核心路径为：

config.yml → Scheduler → Reader → Model → Writer

• Scheduler按时间表触发任务；
• Reader向配置好的 VictoriaMetrics / VictoriaLogs / VictoriaTraces 数据源发起查询；
• Model对查询结果执行拟合与推理；
• Writer把产出的异常分数写回 VictoriaMetrics。

图中虚线节点与箭头表示可选的**自监控（Monitoring）**集成——既可以把指标推送到 VictoriaMetrics，也可以暴露/metrics端点供抓取。若配置了 Server 区块，其本身也可作为自监控指标的发布端点，此时monitoring.pull可以省略。

最小完整配置示例：多对多的模型—查询—调度映射

下面的配置是文档给出的最小可用示例，完整展示了当前版本支持的多模型 × 多查询 × 多调度器的多对多映射能力（调度器负责"何时跑"，模型声明"跑哪个查询、用哪个调度器"）。为便于逐段讲解，各区块注释已保留。

settings: n_workers: 4 # number of workers to run models in parallel native_threads_per_worker: 0 # automatically divide container-aware CPU capacity across workers anomaly_score_outside_data_range: 5.0 # default anomaly score for anomalies outside expected data range restore_state: True # restore state from previous run, if available retention: # how long to keep stale models on disk/in memory ttl: "1d" # time-to-live duration, if the model was not used for inference within this duration, it will be considered stale check_interval: "1h" # how often to check for stale models and remove them # how and when to run the models is defined by schedulers schedulers: periodic_online: # alias class: 'periodic' # scheduler class infer_every: "30s" # how often to produce anomaly scores for new data scatter_infer_jobs: true # distribute infer jobs evenly across the infer interval to reduce synchronized bursts fit_every: "1000d" # bootstrap-only schedule; use a finite cadence if accumulated state must be reset fit_window: "3d" # how much historical data to use for fit stage start_from: "00:00" # align the bootstrap fit to midnight in the configured timezone tz: "Europe/Kyiv" # timezone to use for start_from periodic_online_weekly: class: 'periodic' infer_every: "15m" scatter_infer_jobs: true fit_every: "1000d" # bootstrap-only schedule; use a finite cadence if accumulated state must be reset fit_window: "14d" # if no start_from is specified, jobs will start immediately after service starts # what model types and with what hyperparams to run on your data models: zscore: # we can set up alias for model class: 'zscore_online' # model class z_threshold: 3.5 decay: 0.99 # weight for data points value should be in (0, 1], 1 means to give equal weight to all data provide_series: ['anomaly_score', 'y', 'yhat', 'yhat_upper'] # what series to produce as output of the model queries: ['host_network_receive_errors'] # what queries to run particular model on schedulers: ['periodic_online'] # will be fit once, used for infer every 30s clip_predictions: True # clip predictions to expected data range, i.e. [0, inf] for this query `host_network_receive_errors` envelope_weekly: # we can set up alias for model class: 'temporal_envelope' alpha: 0.005 # adapt the trend while using the bootstrap-only fit schedule loss_reactivity: 3 # allow new deviations to update the envelope provide_series: ['anomaly_score', 'y', 'yhat', 'yhat_lower', 'yhat_upper'] queries: ['cpu_seconds_total'] schedulers: ['periodic_online_weekly'] # fit on two weekly cycles, then update online every 15m anomaly_score_outside_data_range: 1.5 # override default anomaly score outside expected data range clip_predictions: True # clip predictions to expected data range, i.e. [0, inf] for this query `cpu_seconds_total` seasonalities: ['hod_smooth', 'dow_smooth'] # where to read data from reader: class: 'vm' datasource_url: "https://play.victoriametrics.com/" tenant_id: "0:0" sampling_period: "30s" # what data resolution to fetch from VictoriaMetrics' /query_range endpoint workers: 0 # automatically choose bounded datasource concurrency latency_offset: '1ms' query_from_last_seen_timestamp: False tz: "UTC" # timezone to use for queries without explicit timezone "offset": "0s" # offset to apply to all queries, e.g. to account for data delays, can be overridden on per-query basis queries: # aliases to MetricsQL expressions cpu_seconds_total: expr: 'avg(rate(node_cpu_seconds_total[5m])) by (mode)' # step: '30s' # if not set, will be equal to reader-level sampling_period data_range: [0, 'inf'] # query-level business policy from v1.30.2 detection_direction: 'above_expected' # query-level from v1.30.2; detect spikes only min_dev_from_expected: [0.01, 0.01] # query-level from v1.30.2 host_network_receive_errors: expr: 'rate(node_network_receive_errs_total[3m]) / rate(node_network_receive_packets_total[3m])' step: '15m' # here we override per-query `sampling_period` to request way less data from VM TSDB data_range: [0, 'inf'] # query-level business policy from v1.30.2 detection_direction: 'above_expected' # query-level from v1.30.2; detect spikes only min_dev_from_expected: 0.0 # query-level from v1.30.2; absolute-deviation filtering is disabled # where to write data to writer: datasource_url: "http://victoriametrics:8428/" tenant_id: "0:0" # for VictoriaMetrics cluster, can support "multitenant" metric_format: __name__: $VAR for: $QUERY_KEY # enable self-monitoring in pull and/or push mode monitoring: # pull: # Enable /metrics endpoint. # addr: "0.0.0.0" # port: 8490 push: # Enable pushing self-monitoring metrics url: "http://victoriametrics:8428" push_frequency: "15m" # how often to push self-monitoring metrics # configure vmanomaly server and UI settings server: port: 8490 path_prefix: '/vmanomaly' # optional path prefix for all HTTP routes max_concurrent_tasks: 4 # maximum number of concurrent anomaly detection tasks processed by backend use_reader_connection_settings: True # if True, use reader's datasource_url and credentials for UI requests to datasource uvicorn_config: # optional Uvicorn server configuration log_level: 'warning'

该配置的核心语义如下：

• schedulers定义两个调度器：periodic_online每 30 秒推理一次、以 3 天窗口做一次性引导拟合；periodic_online_weekly每 15 分钟推理一次、以 14 天窗口拟合（覆盖两个周周期）。
• models定义两个模型：zscore只跑在host_network_receive_errors查询上、由periodic_online驱动；envelope_weekly（Temporal Envelope 在线模型）只跑在cpu_seconds_total查询上、由periodic_online_weekly驱动，并额外配置了anomaly_score_outside_data_range: 1.5覆盖全局默认值。
• reader定义两个 MetricsQL 查询，host_network_receive_errors通过step: '15m'覆盖了 reader 级sampling_period，显著降低从 TSDB 读取的数据量。
• writer通过metric_format控制输出命名：__name__: $VAR使输出指标名为anomaly_score、y、yhat等，for: $QUERY_KEY添加查询别名标签。
• monitoring开启 push 自监控，每 15 分钟推送一次指标。
• server开启 vmanomaly 自带 UI/API，端口 8490，路径前缀/vmanomaly。

说明：本示例（以及 settings.md 中的示例）使用fit_every: "1000d"作为"仅引导一次（bootstrap-only）"的调度。这适用于自带遗忘/反应机制的在线模型，例如zscore_online配合decay < 1。如果需要显式丢弃过期历史，则应改用有限拟合周期——每次 fit 都会用配置的fit_window重置在线模型状态。

深入各区块：Reader 与 per-query 参数

Reader 是数据的入口。class: 'vm'（VmReader）通过 MetricsQL 从 VictoriaMetrics/Prometheus 读取，class: 'vlogs'（VLogsReader，v1.26.0 起）通过 LogsQL 的statspipe 从 VictoriaLogs/VictoriaTraces 读取。详见 reader.md。

自 v1.13.0 起，queries支持**按查询（per-query）**配置子字段并覆盖 reader 级参数，这正是上例中step: '15m'生效的原理。常用子字段包括：

• expr：MetricsQL/PromQL 表达式，即/query_range?query=%s接受的内容；
• step：该查询返回数据点的频率，覆盖 reader 级sampling_period；
• data_range（v1.15.1+）：合法数据范围。数据落在范围外会得到高异常分数（>1，默认1.01，可用模型级anomaly_score_outside_data_range调整），模型预测落在范围外则异常分数为 0；
• detection_direction（v1.30.2+）：both/above_expected/below_expected，控制只检测向上还是向下的偏差；
• min_dev_from_expected（v1.30.2+）：绝对偏差阈值，|y - yhat|小于该值时异常分数置 0，可配置标量或双元素列表（下/上两个方向）；
• min_rel_dev_from_expected（v1.30.2+）：相对偏差阈值，|y - yhat| / |yhat|小于该值时异常分数置 0；
• max_points_per_query（v1.17.0+）：拆分长fit_window查询的子区间上限，避免单个查询超时；
• tz（v1.18.0+）、tenant_id（v1.19.0+）、offset（v1.25.3+）：分别覆盖时区、租户与查询时间偏移。

reader 级还有workers（v1.30.2+，0表示按查询数与 CPU 自动选择有界并发）、fetch_timeout/processing_timeout（v1.30.0+，分别控制数据源请求与结果后处理超时）、series_processing_batch_size（v1.29.7+，高基数查询建议 4–16）等参数。

深入各区块：Scheduler 的三种工作模式

调度器决定多久跑一次、跑哪个时间范围的数据。class有三种取值：

• periodic（PeriodicScheduler）：生产环境常用。周期性地对新数据推理，并按fit_every周期性重训模型以对抗数据漂移。核心参数为fit_window（训练时间范围，至少 1 秒）、infer_every（推理频率，至少 1 秒）、fit_every（重训频率，缺省等于infer_every）、start_from/tz（v1.18.5+，指定首次 fit 的启动时间与时区，配合restore_state: true可避免重启后长时间空转）、scatter_infer_jobs（v1.29.7+，把推理任务均匀分散到推理间隔内，降低突发负载）。
• oneoff（OneoffScheduler）：运行一次即退出，适合测试或对历史数据一次性回填。通过fit_start_iso/fit_end_iso（或fit_start_s/fit_end_s）与infer_start_iso/infer_end_iso（或infer_start_s/infer_end_s）显式指定拟合与推理时间窗。
• backtesting（BacktestingScheduler）：模拟周期性调度但在历史数据上只跑一次后退出，用于评估模型在过去的实际表现。v1.22.1+ 推荐inference_only: true模式——由from/to定义仅用于推理的时间窗，训练窗自动取每个推理段之前的fit_window；v1.28.0+ 的exact: true使在线模型按infer_every的小批量时序精确回放生产行为。

自 v1.11.0 起，配置区块需命名为schedulers（复数），旧的扁平scheduler写法会被隐式转换为默认别名default_scheduler并保留向后兼容。

深入各区块：Model 的类型、公共参数与输出

模型是异常检测的核心。模型沿两个维度分类：

• 按输入处理方式：**单变量（univariate）**模型对每条时间序列各训练一个实例；**多变量（multivariate）**模型对一组对齐的时间序列共享一个实例，可捕获跨序列的集体异常。
• 按更新策略：**离线（offline）**模型仅在fit时全量重训；**在线（online）**模型（v1.15.0+）在每个infer_every步长上做增量更新，即使只有一个数据点也能更新参数，显著降低数据源读取压力。

内置模型包括auto（自动调参）、temporal_envelope（复杂运营数据的首选在线模型，支持趋势/日历/节假日/预测）、mad_online（基于 t-digest 的稳健中位数绝对偏差）、quantile_online（在线季节性分位数）、zscore_online（在线 Z 分数）、rolling_quantile、prophet、isolation_forest_multivariate、holtwinters、std等。其中 Prophet、Isolation Forest、Holt-Winters 已标记为计划弃用，文档建议新部署迁移到对应的 Temporal Envelope 形式。

所有模型共享的公共参数包括：

• queries（v1.10.0+）：选择该模型使用的 reader 查询；不写则默认使用 reader 中全部查询。
• schedulers（v1.11.0+）：选择驱动该模型的调度器；不写则默认挂到全部调度器。
• provide_series（v1.12.0+）：限制回写的输出列，如['anomaly_score']；timestamp列会被隐式加入。
• scale（v1.20.0+ 支持双向）：以[scale_lower, scale_upper]分别缩放下/上置信区间宽度。
• clip_predictions（v1.20.0+）：把yhat系列裁剪到data_range内。
• anomaly_score_outside_data_range（v1.20.0+）：覆盖数据越界时的异常分数（默认 1.01）。
• decay（v1.23.0+，仅在线模型）：指数遗忘因子，取值(0.0, 1.0]，1.0表示不衰减。
• groupby（v1.13.0+，仅多变量模型）：按标签值分组，每组各训一个独立多变量模型。

注意：data_range、detection_direction、min_dev_from_expected、min_rel_dev_from_expected在模型级配置已自v1.30.2起弃用，应迁移到reader.queries.<alias>下的查询级策略；查询级显式值具有权威性，模型级旧值仅在查询未定义时作为本地回退。

vmanomaly的标准输出指标为anomaly_score（主指标，0–1 视为正常，大于 1 判定异常且跨模型归一化）、yhat（预测期望值）、yhat_lower/yhat_upper（预测下/上界）、y（原始值）。若infer收到 NaN 或无穷大输入，对应anomaly_score为 NaN。

深入各区块：Writer 的指标格式化与多租户

Writer 负责把模型输出写回 VictoriaMetrics，其metric_format有两个必填键：

• __name__：必须包含$VAR占位符，用于区分输出指标类型，例如__name__: "vmanomaly_$VAR"会生成vmanomaly_anomaly_score、vmanomaly_yhat_lower等；
• for：通常填$QUERY_KEY，为每条输出附加查询别名标签。

其余键为用户自定义标签；输入查询自带的标签（如cpu=1, device=eth0, instance=node-exporter:9100）会被原样继承到输出指标上。此外 writer 还支持 mTLS（verify_tls/tls_cert_file/tls_key_file）、BasicAuth、bearer token，以及 v1.30.3 起的batch_max_series/batch_max_bytes/metric_prefix_cache_max_entries批量写入调优参数。多租户场景下，tenant_id支持multitenant端点跨租户写入，但需要注意聚合查询可能丢失vm_account_id路由标签而回落到默认租户0:0（会打印警告）。

深入各区块：Settings、Monitoring 与 Server

• Settings（settings.md）控制服务级行为：n_workers与native_threads_per_worker（v1.30.2+）控制进程级并行与数值库线程数；restore_state（v1.24.0+）使服务有状态，重启后从$VMANOMALY_MODEL_DUMPS_DIR/vmanomaly.db恢复模型与调度器状态（需开启磁盘模式，且模型签名变化时自动重训）；retention（v1.28.1+）以ttl+check_interval清理长期运行中累积的陈旧模型实例；logger_levels（v1.25.3+）支持按组件前缀设置日志级别并支持热更新。
• Monitoring（monitoring.md）提供 push 与 pull 两种自监控：push可配置url、push_frequency（默认 15m，置空字符串可禁用定时推送，仅保留 fit/infer 阶段推送）、extra_labels等；pull配置addr/port暴露/metrics。服务会产出vmanomaly_reader_*、vmanomaly_model_*、vmanomaly_writer_*、vmanomaly_config_reload*、vmanomaly_scheduler_*等系列自监控指标。
• Server（server.md）负责 REST API、/metrics端点与 Web UI：port默认 8490、path_prefix可为所有路由加前缀（如/vmanomaly后 UI 地址为http://localhost:8490/vmanomaly/vmui/）、max_concurrent_tasks默认 2、ui_default_state可指定 UI 默认状态、use_reader_connection_settings（v1.29.2+）让 UI 复用 reader 的数据源连接凭据。v1.30.0+ 还提供了GET /api/v1/timeseries/characteristics（序列特征分析）与POST/GET/DELETE /api/v1/autotune/tasks（异步共享调参任务）端点。

配置热重载（Hot Reload）

自v1.25.0起，vmanomaly支持无需重启进程地热重载配置文件。启用方式是在命令行加--watch参数（详见 QuickStart.md 的 Command-line arguments 一节）：

usage: vmanomaly.py [--license STRING | --licenseFile PATH] [--license.forceOffline] [--loggerLevel {DEBUG,INFO,WARNING,ERROR,FATAL}] [--watch] [-configCheckInterval DURATION] [--dryRun] [--outputSpec PATH] config [config ...]

热重载最好与有状态服务（stateful service）配合使用——通过restore_state保留模型与调度器状态，重启后无需重新训练模型、重新初始化调度器、重新读取数据，最大化复用已有成果。自监控指标vmanomaly_config_reload_enabled在启用热重载时为1，否则为0。

[!WARNING] 自v1.29.5起，基于文件系统事件的旧式热重载已被弃用，改为基于内容轮询的方式，原因是 Kubernetes ConfigMap 符号链接轮换等场景下事件投递不可靠。如果此前使用的是文件系统事件式热重载，请改用--watch标志并按要求配置-configCheckInterval。

热重载的工作原理

服务按-configCheckInterval（默认30s）轮询被监听的.yml/.yaml文件内容（v1.29.5+）。当检测到内容变化时，会先等待防抖窗口，然后重建全局配置并重新初始化各组件。vmanomaly_config_reloads_total指标会以status="success"或status="failure"递增，校验失败也会记录到日志。

关键稳定性保证是：如果重载失败，服务会记录失败原因日志，并继续沿用上一次有效的配置运行，直到某次重载成功。这意味着新配置即使有错误，服务也不会中断，而是保持最后一份有效配置继续工作。

在分片（sharded）部署中，每次全局配置变更都会重新计算当前分片的归属。自 v1.30.4 起，没有可运行任务的分片会保持存活但空闲；后续重载若分配了任务，它会在不重启进程的情况下恢复兼容的模型状态、创建调度器并开始执行。热重载使用的分片拓扑来自进程启动时的环境变量——变更分片数量、成员索引、副本因子或分配策略都需要编排层滚动升级或重启进程。分配策略方面：ROUND_ROBIN在增删实体时可能移动规范有序子配置的后缀；RENDEZVOUS在分片集合不变时保持无关分配的稳定性（见 Scaling-vmanomaly.md 的分配策略指引）。

热重载示例

假设服务以config.yaml启动，内容如下：

settings: n_workers: 4 # number of workers to run models in parallel anomaly_score_outside_data_range: 5.0 # default anomaly score for anomalies outside expected data range restore_state: True # restore state from previous run, if available schedulers: periodic: class: 'periodic' infer_every: "30s" fit_every: "1000d" # bootstrap-only schedule; use a finite cadence if accumulated state must be reset 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' # if not set, will be equal to reader-level 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 # gives more weight to recent data points, value should be in (0, 1], 1 means to give equal weight to all data provide_series: ['anomaly_score'] # if queries are not specified, all queries from reader will be used # if schedulers are not specified, all schedulers will be used writer: datasource_url: "http://victoriametrics:8428/" tenant_id: "0:0" monitoring: push: url: "http://victoriametrics:8428" push_frequency: "15m"

假设服务启动 15 分钟后，reader.queries中cpu_seconds_total的查询表达式与频率发生了变化：

# ... (rest of the config remains unchanged) reader: # ... (rest of the reader config remains unchanged) queries: cpu_seconds_total: expr: 'avg(rate(node_cpu_seconds_total[10m])) by (mode)' # changed lookback period data_range: [0, 'inf'] step: '60s' # changed step # ... (rest of the config remains unchanged)

保存改动后，热重载会自动检测config.yaml的内容变化并尝试重载。由于改动有效，服务会记录成功日志，并以status="success"递增vmanomaly_config_reloads_total。重载后的实际效果是按需复用、只重训受影响的部分：

• 所有在host_network_receive_errors上训练的zscore_online模型实例仍然有效，可继续直接对新数据点推理（直到下一个fit_every触发）；
• 所有在cpu_seconds_total上训练的zscore_online模型实例因查询表达式与频率变化而失效，会以新的查询表达式与频率重新训练。

环境变量占位符：安全注入敏感配置

自v1.25.0起，配置文件中可以直接引用环境变量，语法为标量字符串占位符%{ENV_NAME}。这对管理 API Key、数据库凭据等敏感信息特别有用——敏感值不必硬编码进配置文件，而是由部署环境注入。

例如，设置环境变量VMANOMALY_URL=http://localhost:8428后，可在 reader 区块中写datasource_url: %{VMANOMALY_URL}，启动时即被替换为实际值。

注意：如果引用的环境变量未设置或拼写有误，占位符不会被替换，可能导致配置校验失败或端点探测失败。因此建议在启动服务前确保所有必需的环境变量都已就绪。

环境变量示例

reader: class: 'vm' datasource_url: %{VMANOMALY_URL} # will be replaced with the value of VMANOMALY_URL environment variable tenant_id: %{VMANOMALY_TENANT_ID} # will be replaced with the value of VMANOMALY_TENANT_ID environment variable bearer_token: %{VMANOMALY_BEARER_TOKEN} # will be replaced with the value of VMANOMALY_BEARER_TOKEN environment variable sampling_period: "30s" writer: datasource_url: %{VMANOMALY_URL} # will be replaced with the value of VMANOMALY_URL environment variable tenant_id: %{VMANOMALY_TENANT_ID} # will be replaced with the value of VMANOMALY_TENANT_ID environment variable bearer_token: %{VMANOMALY_BEARER_TOKEN} # will be replaced with the value of VMANOMALY_BEARER_TOKEN environment variable # other config sections ...

上例中，同一组VMANOMALY_URL、VMANOMALY_TENANT_ID、VMANOMALY_BEARER_TOKEN被 reader 与 writer 同时引用，既避免了重复书写，也保证了读写两端凭据一致。

小结与延伸阅读

一份可用的vmanomaly配置可以归纳为四句话：reader决定"读什么"、schedulers决定"何时跑"、models决定"怎么判"、writer决定"写哪去"，再按需叠加settings（并行/状态/保留）、monitoring（自监控）与server（UI/API）。在此基础上，--watch+-configCheckInterval提供滚动更新能力，%{ENV_NAME}占位符保证敏感信息可安全注入，而--dryRun可在不启动服务、不需要 license 的前提下提前校验整份配置（含多 YAML 合并与 schema 校验），是上线前必做的检查步骤。

若想继续深入，建议依次阅读仓库中的：

• components/reader.md——VmReader 与 VLogsReader 的全部参数、per-query 参数与 MetricsQL/LogsQL 查询示例；
• components/models.md——内置模型矩阵、公共参数、模型输出与自定义模型指南；
• components/scheduler.md——periodic / oneoff / backtesting 三种调度器的完整参数；
• components/settings.md——并行化、状态恢复与保留策略；
• components/monitoring.md 与 components/server.md——自监控指标与 REST API/UI；
• QuickStart.md——命令行参数、Docker 部署与 license 配置。

【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics