编排器 API 的指标命名约定
Metric naming convention for orchestrator APIs
我有一个带有端点的 Web 服务 POST /coffee
这需要一个具有一些支持标志的主体：
- 糖（给咖啡加糖）
- 盐（一小撮盐……）
- 焦糖（在咖啡中加糖）
- 巧克力（添加巧克力）
- milk（加牛奶）
- 生奶油（添加生奶油）
随着我们的扩展，可能会有更多。但关键是你可以制作任何这样的咖啡组合，包括没有标志（也许是浓缩咖啡）。
这些标志中的每一个都对应于一个单独的操作（假设 API 调用另一个服务）——因此我想测量它。
衡量这些指标的最佳方式是什么？我关心的是指标名称。所以我可以想到两种方法。
选项 1：每个组合的唯一指标
专业人士： 我具体了解特定 combination/pattern 调用的延迟和错误。
缺点： 不可维护。随着新标志的引入，指标名称模式的数量将激增。在仪表板上阅读所有这些内容很困难。
选项 2：仅针对“POST /coffee”的一个指标将包括任何组合。
专业版： 可维护。仪表板是理智的。
缺点： 将无法分析特定组合的缓慢性。我可能有针对调用服务的单独指标，但我无法将该指标与任何特定的标志组合相关联。
也许在指标中使用标签？ Dropwizard-metrics 不支持标签，但我不知道这是否也是一个不错的选择（在这种情况下标签爆炸。）
就像我开始在评论中解释的那样，我会使用 coffee_ingredients_count 和一个标签 ingredient。然后我增加（如果不存在则创建）成分总数。它会增加标签的数量，你是对的，但它只是一种标签。在某个时候它会停止生长。然后是计数器的问题。我会测量 rate(coffee_ingredients_count[5m])，这样我就能看到最后 5 分钟发生了什么。
would that mean you would consider the addition of 4 ingredients to coffee equivalent to 4 calls to making an espresso (no ingredients)?
是的。因为柜台是按成分计算的。
那么你说的问题就来了
Con: Will not be able to disect the slowness on a specific combination
我不确定速度有多慢，但你仍然可以数出成分。您可以执行与 rate 函数相反的操作，以获得每个指标的实际值。在我们的理想情况下，相反的计算也是正确的：rate(coffee_ingredients_count[5m]) * 60 = real_value 然而，在一些样本没有理想地覆盖整个范围，或者样本没有排列的情况下，这种相反的计算并不总是正确的完全是由于刮擦之间引入的随机延迟 reference.
我有一个带有端点的 Web 服务 POST /coffee 这需要一个具有一些支持标志的主体：
- 糖（给咖啡加糖）
- 盐（一小撮盐……）
- 焦糖（在咖啡中加糖）
- 巧克力（添加巧克力）
- milk（加牛奶）
- 生奶油（添加生奶油）
随着我们的扩展，可能会有更多。但关键是你可以制作任何这样的咖啡组合，包括没有标志（也许是浓缩咖啡）。
这些标志中的每一个都对应于一个单独的操作（假设 API 调用另一个服务）——因此我想测量它。
衡量这些指标的最佳方式是什么？我关心的是指标名称。所以我可以想到两种方法。
选项 1：每个组合的唯一指标
专业人士： 我具体了解特定 combination/pattern 调用的延迟和错误。
缺点： 不可维护。随着新标志的引入，指标名称模式的数量将激增。在仪表板上阅读所有这些内容很困难。
选项 2：仅针对“POST /coffee”的一个指标将包括任何组合。
专业版： 可维护。仪表板是理智的。
缺点： 将无法分析特定组合的缓慢性。我可能有针对调用服务的单独指标，但我无法将该指标与任何特定的标志组合相关联。
也许在指标中使用标签？ Dropwizard-metrics 不支持标签，但我不知道这是否也是一个不错的选择（在这种情况下标签爆炸。）
就像我开始在评论中解释的那样，我会使用 coffee_ingredients_count 和一个标签 ingredient。然后我增加（如果不存在则创建）成分总数。它会增加标签的数量，你是对的，但它只是一种标签。在某个时候它会停止生长。然后是计数器的问题。我会测量 rate(coffee_ingredients_count[5m])，这样我就能看到最后 5 分钟发生了什么。
would that mean you would consider the addition of 4 ingredients to coffee equivalent to 4 calls to making an espresso (no ingredients)?
是的。因为柜台是按成分计算的。
那么你说的问题就来了
Con: Will not be able to disect the slowness on a specific combination
我不确定速度有多慢，但你仍然可以数出成分。您可以执行与 rate 函数相反的操作，以获得每个指标的实际值。在我们的理想情况下，相反的计算也是正确的：rate(coffee_ingredients_count[5m]) * 60 = real_value 然而，在一些样本没有理想地覆盖整个范围，或者样本没有排列的情况下，这种相反的计算并不总是正确的完全是由于刮擦之间引入的随机延迟 reference.