这可以通过一组连续查询在InfluxDB中完成 .
InfluxDB似乎的工作原理是存储很便宜,而且计划外的处理器时间很昂贵 . 设置存储结果的背景连续计算很容易,它可以让计算在后台悄然流失 . 在InfluxDB中进行实时计算很快就会变得笨拙(或者如果它们跨越测量结果则不可能) .
战略
每个例如五分钟,执行每个度量的总和,按时间分组,并将总和插入第四个度量,称为 myservice_summary .
而不是只有一个名为 value 的字段, myservice_summary 将有几个字段;一个用于调用的调用,一个用于已处理的调用,另一个用于有错误的调用 . 我们将字段命名为对读取数据的人有意义的字段,而不是默认名称 value .
请注意,使用 GROUP BY time(x) (在此示例中,每五分钟)压缩数据还可以减少存储开销和客户端查询时间(在客户端上检索,传输和显示的点数更少) . 它还降低了存储要求 . 在InfluxDB中使用至少两个保留策略是很常见的:原始数据在短时间内(例如30天)被修整,压缩和处理的数据可以保留更长时间(例如,几个月,几年......)
当然,选择太大的间隔意味着粗略的分辨率可能不利于故障查找 . 例如当你需要知道在哪个小时开始寻找特定的变化时,使用 GROUP BY time(1d) 没什么用处 .
最佳时间分组窗口可 balancer 对问题何时开始/停止的有效检测,以及客户端响应和存储负载的速度 . 找到这个最佳值是一个练习 . :)
示例
请注意,在使用CLI时,对于以下三个连续查询中的每一个,从 CREATE CONTINUOUS QUERY 到 END 的所有内容可能需要在一行上以避免语法错误 . 我只是为了提高可读性而设置换行符 .
方括号 [ ] 表示可选参数 . 括号本身不包含在字面上 .
在这种情况下,您可以使用额外的标签键来选择哪些键是重要的,并且应该在新的测量中 .
CREATE CONTINUOUS QUERY myservice_processed_sum_5m ON your_db_name
BEGIN
SELECT sum(value) AS processed_sum_5m
INTO myservice_summary
FROM myservice_processed GROUP BY time(5m)[, other_tag_keys e.g. vendor_id]
END
CREATE CONTINUOUS QUERY myservice_invoked_sum_5m ON your_db_name
BEGIN
SELECT sum(value) AS invoked_sum_5m
INTO myservice_summary
FROM myservice_invoked GROUP BY time(5m)[, other_tag_keys e.g. vendor_id]
END
CREATE CONTINUOUS QUERY myservice_error_sum ON your_db_name
BEGIN
SELECT sum(value) AS error_sum_5m
INTO myservice_summary
FROM myservice_error GROUP BY time(5m)[, other_tag_keys e.g. vendor_id]
END
所以现在我们有一个名为 myservice_summary 的新测量,有三个字段: processed_sum_5m , invoked_sum_5m 和 error_sum_5m (假设你想要5分钟的摘要) .
从那里,过去24小时的失败百分比查询将是:
SELECT (error_sum_5m / invoked_sum_5m) * 100.0
AS error_pct_5m
FROM myservice_summary
WHERE time > now() - 1d
[GROUP BY other_tags e.g. vendor_id]
或者以更表格的格式:
SELECT [vendor_id, etc, ](error_sum_5m / invoked_sum_5m) * 100.0
AS error_pct_5m
FROM myservice_summary
WHERE time > now() - 1d
使用 myservice_summary 中存储在另一个CQ中的结果是可能的,但我不是100%确定避免竞争条件,即如果依赖于 myservice_summary 的CQ在填充该测量的查询之前执行该怎么办?
希望有所帮助 .