Prometheus 抓取模型:pull、间隔与过期

  抓取间隔 | 样本数 | 相邻样本间隔 最小(ms) | 中位(ms) | 最大(ms) | 标准差(ms)
  -----+-----+---------------+--------+--------+--------
  1 s  | 61  | 998           | 1000   | 1002   | 1.5    
  5 s  | 13  | 4998          | 5000   | 5002   | 1.4    
  Prometheus 按固定的间隔调度抓取(每个 target 有一个由哈希决定的起始偏移,不会所有 target 同时抓取);相邻样本的间隔几乎恰好等于抓取间隔,偏差在几毫秒以内

  情形                    | 从停止/消失到即时查询查不到 | 那时 up 的值
  ----------------------+----------------+---------
  (a)target 进程停了        | 1.9 s          | 0       
  (b)target 还在,一条序列消失   | 1.9 s          | 1       
  (c)样本带显式时间戳,target 停了 | 29.9 s         | 0       
  (d)对照:不带时间戳,target 停了 | 2.0 s          | 0       
  抓取失败(a)或者序列从成功的抓取结果里消失(b)时,Prometheus 在下一次抓取时写一个 staleness 标记,即时查询马上查不到(不超过一个抓取间隔);带显式时间戳的样本没有 staleness 标记,要等 lookback-delta 过去才查不到

  target 响应延迟 | up | scrape_duration_seconds | 近 1 分钟 m 的样本数 | 近 1 分钟 up 的样本数
  ------------+----+-------------------------+---------------+---------------
  0.5 s       | 1  | 0.51 s                  | 4             | 4             
  1.5 s       | 1  | 1.50 s                  | 4             | 4             
  3.0 s       | 0  | 2.00 s                  | 0(没有样本)       | 4             
  响应超过 scrape_timeout 的抓取算失败:up 变成 0,这次的数据一条都不收(m 没有样本),但 up 和 scrape_duration_seconds 这些元数据照样记录

  活 2 s 的 20 个任务里被抓到过的有 1 个;活 12 s 的 20 个任务里被抓到过的有 20 个
  被抓到的活 12 s 的任务:从登记到第一个样本 最小 1.9 s、中位 5.9 s、最大 10.7 s;每个任务被抓到 1~3 次(中位 2 次)
  抓取间隔只是一个因素:新登记的 target 从写入 file_sd 文件到出现第一个样本要等几秒(上面的“登记到第一个样本”那一行;延迟的构成我印象里是服务发现的更新有批量节流加上 target 自己的第一次抓取,没有逐项验证),任务比这个延迟还短就一次都抓不到。这类任务应该主动把指标推给 Pushgateway 之类的中间层,或者在退出前自己上报
ERRORS {}