问题描述
我有包含多月 PDP 数据的 RRD 文件（5 分钟间隔）。
对于一般用途的图形来说很好，当 rrdtool 自动决定使用哪个 RRA 来显示图形时。
但是我的一些图表在图例中包含 95-percentile 数据，我需要根据“精确”的 5 分钟间隔数据计算这些数据，因为从聚合数据点计算 percentile 可以（本质上）导致显着的不正确的值。'
- 我可以
fetch从 RRD 文件中获取数据，步长为 300，我将获得正确的数据来自行计算百分位数 -
问题：当图表以 300 为步长时，显示的百分比值会根据图表的
width而变化，即使时间-Range 是一样的，整个 Time-Range 都有 300s 的数据 - 如果 1 个月图表的宽度为 800 像素，则显示的百分比（以及最大值，例如）是错误的
- 如果 1 个月图表的宽度为 8000 像素，则值是正确的（与提取的数据中的自计算值匹配）
图表：
...
--step 300
...
"VDEF:perca=a,95,PERCENT",...
创建方式：
'-s','300',...
"RRA:AVERAGE:0.5:1:53568",# 6 months pdp
"RRA:AVERAGE:0.5:12:8904",# 1 hour,1 year.
"RRA:AVERAGE:0.5:288:730",# 1 day,2 years.
"RRA:AVERAGE:0.5:2016:520",# 1 week,10 years.
"RRA:MAX:0.5:1:600",# 5 min: 2 days
"RRA:MAX:0.5:12:8904",1 year.
"RRA:MAX:0.5:288:730",2 years.
"RRA:MAX:0.5:2016:520",10 years
解决方法
这是由于在 VDEF 计算之前执行了数据整合。
尽管您的 rrdtool graph 参数指定了 300 秒的步长，但这比图形的像素宽度要小，因此在到达 VDEF 之前，数据系列会进一步平均。所有 CDEF 和 VDEF 函数将始终使用每像素一个 cdp 的时间序列。来自 RRDTool 手册：
注意：小于一个像素的步长将被静默忽略。
这意味着，虽然您可以降低数据的分辨率，但不能提高它。遗憾的是，要获得准确的 95%，您需要更高分辨率的数据。
因此，如果您在窄图中省略 --step 300，将会发生以下情况：
- 您要求 1 个月的时间窗口
- RRDTool 计算 1 个像素大约为 1 小时
- DS 从 1 小时 RRA 中检索平均时间序列，每像素 1 cdp（IE 小时）
- VDEF 然后将其合并到第 95 个百分位
- 第 95 个百分位的计算不准确
使用 --step 300 的过程略有不同，但结果相同：
- 您要求 1 个月的时间窗口，步骤 300
- RRDTool 计算 1 个像素大约为 1 小时
- RRDTool DS 从 300 年代的 RRA 中检索一个月的数据
- RRDTool 使用平均值将此数据进一步整合到每像素 1cdp（IE 每小时）
- VDEF 然后将其合并到第 95 个百分位
- 第 95 个百分位的计算不准确
因此，您可以看到最终结果是相同的 - 就在 300 秒 -> 1 小时合并发生的地方，无论是在 RRA 中还是在图形时间。
当使用宽图时，每个像素的时间变小，RRDTool 不再需要对数据进行额外的合并，从而获得更准确的计算：
- 您要求 1 个月的时间窗口
- RRDTool 计算 1 个像素大约是 5 分钟
- RRDTool DS 从 300 年代的 RRA 中检索一个月的数据
- 无需进一步整合
- VDEF 然后将其合并到第 95 个百分位
- 95% 的计算是准确的！
当您使用 rrdtool fetch1 检索原始数据时，不会发生这种额外的合并，因此您会得到：
- 您在第 300 步要求 1 个月的时间窗口
- RRDTool DS 从 300 年代的 RRA 中检索一个月的数据
- 输出这些数据
- 然后您的电子表格计算第 95 个百分位数
- 第 95 个百分位数的计算是正确的（嗯，尽可能接近，间隔 5 分钟）
您的下一个问题可能是，我如何阻止这种情况发生？不幸的答案是你不能。 RRDTool 没有 Percentile 类型的 CF，因此无法在 RRA 中执行正确的计算（这将是唯一真正的解决方案）。
MRTG 的 Routers2 前端计算图形的第 95 个百分位数，它的方法是执行高分辨率 fetch 以获取原始数据并在内部计算值，然后将其传递到 {{ 1}} 制作图表时。换句话说，由于您遇到的这个问题，它根本不使用 HRULE。