【问题标题】:Micrometer Counter vs DistributionSummaryMicrometer Counter vs Distribution总结
【发布时间】:2021-10-20 14:12:01
【问题描述】:

使用我要跟踪的请求大小的摘要

  • 请求总数
  • 总请求大小
  • 最大请求大小

我可以这样做

meterRegistry.summary("request.size", <tag for url>).record(<size>);

但是我可以使用计数器和最大尺寸的量规来达到同样的效果

meterRegistry.counter("request.size.total", <tag for url>).increment(<size>);
meterRegistry.counter("request.size.count", <tag for url>).increment();
meterRegistry.gauge("request.size.max", <tag for url>).set(<new value if needed>);
// and the gauge value will be stored in atomic variable

问题是,除了更短之外,总结比更长的解决方案有什么好处吗?

【问题讨论】:

    标签: java prometheus monitoring metrics micrometer


    【解决方案1】:

    使用DistributionSummary 表示:

    • 编写和维护更少的代码
    • 使用 Micrometer 的命名约定
    • 随时间推移的衰减值(参见:distributionStatisticExpirydistributionStatisticBufferLength
    • 你可以有histograms and percentiles
    • 您可以定义 SLO

    【讨论】:

      【解决方案2】:

      除了@Jonatan Ivanov 的回答。

      使用带有tag = &lt;request size&gt; 的计数器意味着将为每个请求大小创建一个 指标。这意味着您最终可能会得到大量计数器。

      如果您认为区分标记是具有较少可能值的东西,并且不会创建太多计数器指标,您仍然可以使用计数器并制作摘要提供的所有聚合。 (分位数除外)。

      如果我感兴趣,我会使用计数器,例如大小为 450 的请求数,这是不可能的摘要。

      TLDR

      如果您只对总计数和平均大小感兴趣,请使用摘要

      如果尺寸差异不是太大并且您对给定尺寸的确切计数感兴趣,请使用计数器。

      【讨论】:

      • 但是如果你使用counter with tag = &lt;request size&gt; means a new metric will be created for every request size,由于基数大,你可能会创建很多仪表,并且可能会出现OOM。
      猜你喜欢
      • 2015-03-04
      • 1970-01-01
      • 2020-04-22
      • 2016-05-26
      • 1970-01-01
      • 2015-12-07
      • 2022-11-23
      • 2014-04-22
      • 1970-01-01
      相关资源
      最近更新 更多