VictoriaMetrics 中文教程（09）VictoriaMetrics 18 条 Troubleshooting 建议和提示

VictoriaMetrics 中文教程系列文章：

• VictoriaMetrics 中文教程（01）简介
• VictoriaMetrics 中文教程（02）安装
• VictoriaMetrics 中文教程（03）如何配置 Prometheus 使其把数据远程写入 VictoriaMetrics
• VictoriaMetrics 中文教程（04）对接 Grafana 同时介绍 vmui
• VictoriaMetrics 中文教程（05）对接各类监控数据采集器
• VictoriaMetrics 中文教程（06）容量规划
• VictoriaMetrics 中文教程（07）高可用（High availability）方案
• VictoriaMetrics 中文教程（08）VictoriaMetrics 的存储

VictoriaMetrics 18 条 Troubleshooting 建议和提示

1. 建议使用默认的命令行标志值（即不要明确设置它们），直到需要调整这些标志值。VictoriaMetrics 的启动参数默认就是最佳实践。
2. 建议在故障排除期间检查日志，因为它们可能包含有用的信息。（只要会看日志，已经胜过 80% 的人了）。
3. 建议升级到最新版，最新版在 github releases 页面可以找到。
4. 建议至少为 CPU、磁盘 IO 和 RAM 保留 50% 的备用资源，这样 VictoriaMetrics 才能处理工作负载的短暂高峰，而不会出现性能问题。
5. VictoriaMetrics 需要可用磁盘空间来将数据文件合并为更大的文件。当剩余可用空间不足时，它可能会变慢。因此，请确保 -storageDataPath 目录至少有 20% 的可用空间。剩余的可用空间量可以通过 vm_free_disk_space_bytes 指标进行监控。磁盘上存储的数据总大小可以通过 vm_data_size_bytes 指标的总和进行监控。
6. 如果您在具有 16 个或更多 CPU 核心的主机上运行 VictoriaMetrics，则可能需要调整 -search.maxWorkersPerQuery 命令行标志以提高查询性能。如果 VictoriaMetrics 处理大量并发选择查询，请尝试降低此标志的值。如果 VictoriaMetrics 处理大量查询，即每个查询选择 >10K 的时间序列和/或处理 >100M 的原始样本，则尝试将此标志的值设置为可用的 CPU 核心数。
7. VictoriaMetrics 会将传入的数据在内存中缓冲几秒钟，然后再将其刷新到持久存储中。这可能会导致以下“问题”：
   • 插入后几秒钟内即可查询数据。可以通过请求 /internal/force_flush 接口将内存缓冲区刷新到可搜索部分。此接口主要用于测试和调试目的。
   • 不正常关机（即 OOM、kill -9 或硬件重置）可能会导致最后几秒插入的数据丢失。-inmemoryDataFlushInterval 命令行标志允许控制将内存数据刷新到持久存储的频率。
8. 如果 VictoriaMetrics 运行缓慢，并且每秒每 100K 个数据点消耗超过一个 CPU 核心，那么很可能是您的活跃时间序列数量超出了当前的 RAM 容量。VictoriaMetrics 公开了 vm_slow_* 指标，例如 vm_slow_row_inserts_total 和 vm_slow_metric_name_loads_total，这些指标可用作 RAM 容量不足的指标。在这种情况下，建议增加使用 VictoriaMetrics 的节点上的 RAM 容量，以提高提取和查询性能。
9. 如果相同指标的标签顺序会随时间而改变（例如，如果 metric{k1="v1",k2="v2"} 可能变成 metric{k2="v2",k1="v1"}），那么建议使用 -sortLabels 命令行标志运行 VictoriaMetrics，以减少内存使用量和 CPU 使用量。
10. VictoriaMetrics 优先考虑数据采集，而不是数据查询。因此，如果没有足够的资源进行数据采集，那么数据查询可能会显著减慢。
11. 如果由于磁盘错误导致某些 part 损坏而导致 VictoriaMetrics 无法工作，则只需删除损坏 part 的目录即可。当 VictoriaMetrics 未运行时，删除 <-storageDataPath>/data/{big,small}/YYYY_MM 目录下的子目录是安全的。这会恢复 VictoriaMetrics，但会丢失存储在已删除损坏 part 中的数据。损坏 part 的名称应出现在错误消息中。如果您发现错误消息被截断并且不包含所有信息，请尝试将 -loggerMaxArgLen 命令行标志增加到更高的值以避免错误消息被截断。
12. 如果您发现图表上有间隙，请尝试通过向 /internal/resetRollupResultCache 发送请求来重置缓存。如果这可以消除图表上的间隙，则很可能是时间戳早于 -search.cacheTimestampOffset 的数据被提取到 VictoriaMetrics 中。确保数据源的时间与 VictoriaMetrics 同步。如果间隙与样本之间的不规则间隔有关，则尝试调整 -search.minStalenessInterval 命令行标志以接近样本之间最大间隔的值。
13. 如果您从 InfluxDB 或 TimescaleDB 切换，则可能需要设置 -search.setLookbackToStep 命令行标志。这将抑制 VictoriaMetrics 使用的默认间隙填充算法 - 默认情况下，它假设每个时间序列都是连续的而不是离散的，因此它会以规则的间隔填充真实样本之间的间隙。
14. 可以通过基数浏览器和 /api/v1/status/tsdb 端点确定导致高基数或高流失率的指标和标签。
15. 如果将 -logNewSeries 命令行标志传递给 VictoriaMetrics，则可以记录新的时间序列。
16. 📌 VictoriaMetrics 使用 -maxLabelsPerTimeseries 命令行标志限制每个指标的标签数量并删除多余的标签。这可以防止提取带有太多标签的指标。建议监控 vm_metrics_with_dropped_labels_total 指标，以确定是否必须根据您的工作负载调整 -maxLabelsPerTimeseries。
17. 如果您将 Graphite 指标（例如 foo.bar.baz）存储在 VictoriaMetrics 中，则可以使用 {__graphite__="foo.*.baz"} 过滤器来选择此类指标。
18. VictoriaMetrics 在数据摄取期间忽略 NaN 值。