【发布时间】:2021-01-23 17:57:34
【问题描述】:
我正在大规模实现后端 API 的指标系统,但遇到了两难境地:使用 statsd,应用程序本身正在记录每个端点的请求指标,但 CPU 指标位于全局服务器上等级。目前每台服务器有 10 个线程,这意味着一次可以处理 10 个请求(是的,是的,它实际上是串行的)。
例如,如果我们有两个端点,/user 和 /item,statsd 实现是区分每个端点的统计信息(DB/Redis I/O 等)。但是,假设我们正在查看每个 N seconds 的 linux-metrics,这些统计数据本质上并没有分隔端点。
我相信这是可能的,假设您的轮询时间 ("N seconds") 足够小并且您的请求具有足够的多样性,以分解全局系统指标以在端点级别创建估计值.
想象这样一个场景:
注意:我们会说 a 代表 GET 到 /user,b 代表 GET 到 /item
|------|------|------|------|------|------|------|------|------|------|
| t1 | t2 | t3 | t4 | t5 | t6 | t7 | t8 | t9 | t10 |
|------|------|------|------|------|------|------|------|------|------|
| a | b | b | a | a | b | b | a | b | b |
| b | a | b | | b | a | b | | b | |
| a | b | b | | a | a | b | | a | |
| a | | b | | b | a | a | | a | |
| a | | b | | a | a | b | | | |
| | | | | a | | a | | | |
|------|------|------|------|------|------|------|------|------|------|
在每个时间步,t(即t1、t2 等),我们还会对我们的系统指标进行快照。我觉得应该有一种方法(可能通过某种信号分解)来估计每个a/b 请求的平均负载。现在,实际上我有大约 20 条路线,因此要获得准确的估计要困难得多。但就像我之前说的,只要你的请求有足够的多样性(但不是太多),以至于它们在上面的某些地方重叠,至少应该有可能得到一个粗略的估计。
我不得不想象这种东西有一些名字,或者至少有一些研究或这种方法的幼稚实现。在实践中,有没有什么方法可以达到这样的效果?
注意:考虑到请求可能会超过这些时间步长,这可能会更加困难,但几乎所有请求都需要
【问题讨论】:
标签: server metrics usage-statistics statsd