如何在 Web 服务器上将全局系统指标分解为每个端点
How to Decompose Global System Metrics to a Per Endpoint Basis on a Webserver
我正在大规模地为后端 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 条路线，因此要获得准确的估计要困难得多。但是就像我之前说的，只要你的请求有足够的多样性（但不要太多），以至于它们在某些地方像上面那样重叠，至少应该可以得到一个粗略的估计。
我不得不想象这种东西有一些名字，或者至少有一些研究或这种方法的天真实现。在实践中，有没有什么方法可以达到这样的效果？
注意：考虑到请求可能会在这些时间步长上流血，这可能会更加困难，但几乎所有请求都需要 <250 毫秒。即使我们的系统统计数据轮询率是每 5 秒一次（这是激进的），这也不应该真正造成问题。也可以安全地假设我们将在每台服务器上至少实现 50 requests/second，因此数据的稀疏性不会造成问题。
我相信答案是通过线性方程进行求和分解。如果我们说一个系统指标，例如 CPU，是一个函数 CPU(t1)，那么对于已发布的示例，只需求解以下方程组即可：
|------|------|------|------|------|------|------|------|------|------|
| 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 | | | |
|------|------|------|------|------|------|------|------|------|------|
4a + b = CPU(t1)
a + 2b = CPU(t2)
5b = CPU(t3)
a = CPU(t4)
3a + 3b = CPU(t5)
4a + b = CPU(t6)
2a + 4b = CPU(t7)
a = CPU(t8)
2a + 2b = CPU(t9)
b = CPU(t10)
现在，解这个方程的方法不止一种（即a = CPU(t8)和a = CPU(t4)），但是如果你取a和b的平均值（AVG(a)）从他们相应的解决方案中，你应该得到一个非常可靠的指标。
我正在大规模地为后端 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 条路线，因此要获得准确的估计要困难得多。但是就像我之前说的，只要你的请求有足够的多样性（但不要太多），以至于它们在某些地方像上面那样重叠，至少应该可以得到一个粗略的估计。
我不得不想象这种东西有一些名字，或者至少有一些研究或这种方法的天真实现。在实践中，有没有什么方法可以达到这样的效果？
注意：考虑到请求可能会在这些时间步长上流血，这可能会更加困难，但几乎所有请求都需要 <250 毫秒。即使我们的系统统计数据轮询率是每 5 秒一次（这是激进的），这也不应该真正造成问题。也可以安全地假设我们将在每台服务器上至少实现 50 requests/second，因此数据的稀疏性不会造成问题。
我相信答案是通过线性方程进行求和分解。如果我们说一个系统指标，例如 CPU，是一个函数 CPU(t1)，那么对于已发布的示例，只需求解以下方程组即可：
|------|------|------|------|------|------|------|------|------|------|
| 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 | | | |
|------|------|------|------|------|------|------|------|------|------|
4a + b = CPU(t1)
a + 2b = CPU(t2)
5b = CPU(t3)
a = CPU(t4)
3a + 3b = CPU(t5)
4a + b = CPU(t6)
2a + 4b = CPU(t7)
a = CPU(t8)
2a + 2b = CPU(t9)
b = CPU(t10)
现在，解这个方程的方法不止一种（即a = CPU(t8)和a = CPU(t4)），但是如果你取a和b的平均值（AVG(a)）从他们相应的解决方案中，你应该得到一个非常可靠的指标。