[FR] Support recording the response and rrt metrics using the request timestamp (application_1m)
pegasusljn opened this issue · comments
Search before asking
- I had searched in the issues and found no similar feature requirement.
Description
flow_metric数据中只有timestamp，即统计窗口开始时间(如果没理解错的话)，无法了解各个metric指标对应请求真正发生的时间。（需求：例如在异常和超时流量的监控分析时，以请求开始时间进行聚合，观察异常流量的影响面和传播路径）
因此需要在维度项中添加request_time, 方便给指标建立时序关系，做进一步分析
Use case
No response
Related issues
No response
Are you willing to submit a PR?
- Yes I am willing to submit a PR!
Code of Conduct
- I agree to follow this project's Code of Conduct
经讨论，需求变更为“添加一个可配置长度的窗口延迟时间”
以flow_metric 1m粒度指标为例，如果设置窗口延迟时间为3min（可配置），则：
- t0-t1时刻统计窗口结束后，不立即上报，而是继续等待3min;
- 3min延迟时间内，若收到response返回，且对应的request是在t0-t1范围内，则response、rrt等相关指标仍然记录在t0-t1窗口内，到达3min延迟时间后， 上报指标数据；
- 在此基础上，指标统计的窗口长度、步长不发生变化
如果在 ClickHouse 中创建一个 5min 的物化视图（基于 1min 的数据）的话，能解决你的需求吗。
也就是说，基础数据依然是一分钟一个点：
- 20:20:00 ~ 20:20:59
- 20:21:00 ~ 20:21:59
- 20:22:00 ~ 20:22:59
- 20:23:00 ~ 20:23:59
- 20:24:00 ~ 20:24:59
- 20:25:00 ~ 20:25:59
- 20:26:00 ~ 20:26:59
- 20:27:00 ~ 20:27:59
- 20:28:00 ~ 20:28:59
- 20:29:00 ~ 20:29:59
额外提供一个 5min 聚合的数据表，每 5min 的数据聚合为一个点：
- 20:20:00 ~ 20:24:59
- 20:25:00 ~ 20:29:59
这个支持起来会比较快，对 agent 的改动也比较小。
增加一个 request-response-distance 的 tag，表示当前这一行数据中的 response 与对应的 request 距离有多远（有多少个自然分钟）：
| time | pod | request-response-distance | total_request | total_response | rrt |
|---|---|---|---|---|---|
| 20:20:00 ~ 20:20:59 | my-pod | 0 | 45 | 20 | 30 |
| 20:21:00 ~ 20:21:59 | my-pod | 0 | 11 | 5 | 31 |
| 20:21:00 ~ 20:21:59 | my-pod | 1 | 0 | 20 | 32 |
| 20:22:00 ~ 20:22:59 | my-pod | 0 | 12 | 12 | 32 |
| 20:22:00 ~ 20:22:59 | my-pod | 1 | 0 | 6 | 32 |
| 20:22:00 ~ 20:22:59 | my-pod | 2 | 0 | 5 | 32 |
- 我们根据第 1、3、6 行数据，可以得知 20:20:00 ~ 20:20:59 有 45 个请求、20+20+5 个响应。
- 根据第 2、5 行数据，可以得知 20:21:00 ~ 20:21:59 有 11 个请求，5+6 个响应。
- 根据第 4 行数据，可以得知 20:22:00 ~ 20:22:59 有 12 个请求，12 个响应。
另外，上述是 agent 输出数据的逻辑。server 拿到这样的数据以后，对于 request-response-distance 大于 0 的行，可以将时间戳减去对应的分钟数之后再存储，便于查询。