短执行周期任务场景下，如何选Victoria Metrics并精准统计在途任务数？

一、更优的在途任务数统计方案 #

1. 事件累计+速率差计算（推荐） #

放弃直接依赖瞬时在途数的上报，转而维护两个计数器：

• 任务提交总次数（task_submitted_total）
• 任务完成总次数（task_completed_total）

每次任务提交时递增task_submitted_total，完成时递增task_completed_total。在Victoria Metrics中通过以下查询得到30秒周期内的平均在途数：

rate(task_submitted_total[30s]) - rate(task_completed_total[30s])

这种方式无需缓存，事件会被持久化记录，即便任务秒级完成，累计值的速率差也能准确反映这段时间内的平均负载，从根源上避免了瞬时采样为0的问题。

2. 瞬时采样+滑动窗口峰值记录 #

若需要保留瞬时值的直观性，可以在任务提交/完成时实时更新当前在途数，同时维护一个与上报周期（30秒）匹配的滑动窗口，记录窗口内的最大在途数。上报时同时提交两个值：

• 当前值用于实时查看当前负载
• 峰值用于反映上报周期内的最高负载，避免采样时任务已全部完成导致的0值问题

滑动窗口可通过环形队列实现，每1秒记录一次当前在途数，窗口保留30个样本，上报时取最大值即可，内存占用极低。

3. 优化现有缓存策略 #

如果坚持使用缓存，不要用固定5分钟的静态缓存，改为滑动窗口缓存：仅保留最近30秒内的在途数样本，上报时计算窗口内的平均值或最大值。既解决了采样为0的问题，又避免了不必要的内存浪费。

二、Victoria Metrics指标类型选型 #

1. Counter（首选，适配短任务场景） #

用两个Counter分别统计任务提交和完成的总次数，通过速率差计算平均在途数。该类型天生适合短周期任务，因为它记录的是累计事件，不会丢失任何任务的提交/完成记录，计算出的结果能准确反映一段时间内的负载趋势。

2. Gauge（配合峰值记录使用） #

用Gauge记录当前在途数，同时额外用一个Gauge记录滑动窗口内的峰值。这种方式适合需要直观看到当前负载和周期内最高点的场景，但单独使用Gauge会存在采样为0的问题，必须配合峰值记录。

3. Histogram（用于负载分布分析） #

若需要分析在途任务数的分布情况（比如95%的时间内峰值不超过多少），可以用Histogram。每次在途数变化时，将当前值作为样本存入Histogram，之后可通过histogram_quantile(0.95, rate(task_in_flight_histogram_bucket[5m]))查询95分位的峰值，适合深入分析负载波动规律的场景。

内容的提问来源于stack exchange，提问作者Karl Chertoff