【问题标题】:Prometheus and frequent counter discontinuitiesPrometheus 和频繁的计数器不连续性
【发布时间】:2021-04-10 12:25:10
【问题描述】:

我之前一直在做一个使用 prometheus 和 grafana 来收集和显示指标的服务器端项目。效果很好。

我现在正在开发一个客户端应用程序。那是一个运行在 android 和 iphone 设备上的应用程序。我还被要求使用 prometheus 和 grafana 来收集和显示来自应用程序的指标。

在这项任务中需要克服多个挑战。首先,我们需要弄清楚 prometheus 服务器如何抓取所有客户端应用程序。虽然对于服务器端项目,服务器数量有限且已知(比如 10 个位于已知 IP 地址的服务器),但对于客户端应用程序,将有 1000 多个应用程序在许多智能手机上运行。我已经解决了第一个挑战,这不是我的问题的重点。

我面临的最重要的问题是用户可以随时在他们的智能手机上启动和关闭应用程序。这意味着,可能会有 1000 多个客户端应用同时运行,并且这些应用会非常频繁地上线/下线。

与服务器端服务相比,我只有 10 个服务实例长时间运行,prometheus 每 30 秒抓取一次。

为了把事情放在上下文中,假设我有一个简单的 prometheus 计数器,它的值总是增加:

requests_total{status="success"}
requests_total{status="failure"}

我可以通过以下方式可视化失败请求的数量:

sum(increase(requests_total{status="failure"}[1m]))

这对于我运行很长时间的服务器端服务来说效果很好。当我重新启动服务时,曾经在一个蓝月亮。计数器会出现不连续性,但这种情况很少发生。 increase 函数的普罗米修斯文档说:

... Breaks in monotonicity (such as counter resets due to target restarts) are automatically adjusted for.

但对于我的客户端应用程序,将有 1000 多个应用程序实例在运行,并且它们会频繁上线/下线。这意味着我的柜台可能有很多不连续性。

我在这里向 prometheus 社区寻求建议。使用 prometheus 从可以频繁上线/下线的客户端应用程序收集指标是否有意义?或者,prometheus 可能从未设计为与客户端应用程序一起使用。

【问题讨论】:

    标签: prometheus


    【解决方案1】:

    感谢@sskrlj。这是有关我的情况的更多信息。为了从所有客户端收集数据,我可以使用 prometheus pushgateway,正如您所指出的。但相反,我将首先在弹性搜索中收集所有数据。也就是说,每 30 秒,所有客户端都会将一个小的 JSON 文档推送到具有其计数器值的弹性搜索中。

    然后我将运行一个充当适配器的内部服务实例...类似于 prometheus 弹性搜索导出器 (https://github.com/braedon/prometheus-es-exporter) 以聚合来自弹性搜索的所有值并公开单个 prometheus 计数器要抓取的 prometheus 服务器。

    所以会有一个长寿命的普罗米修斯计数器一直刮。但问题是计数器不会单调增加。因为应用程序的用户可以随时打开/关闭应用程序。该计数器会上下波动很多。所以我不知道sum(increase(counter...)) 是否会给我任何有意义的东西。当单调性频繁中断时,increase 的行为如何?

    附带说明一下,我实现的内部适配器服务还可以聚合来自弹性搜索的值以生成普罗米修斯直方图。直方图只是计数器的集合,直方图中的单调性也会有很多突破。所以不知道prometheus和grafana是怎么显示的。

    【讨论】:

      【解决方案2】:

      短命的计数器一定是你在 Prometheus 中能做的最糟糕的事情之一。即使我们不考虑容量过度使用(存储、RAM、CPU),当考虑到 Prometheus 在速率/增量中使用的外推时,您根本无法获得这些短期计数器速率或增量的适当聚合。我遇到了完全相同的事情,当它在服务器端时,我正在跟踪一个实体,在某些情况下,它是为单个事件创建的。

      如果您决定采用这种方式,至少确保在实例化您的“实体”实例时以 0 开始计数器,而不仅仅是在第一个事件发生时,因为您可能最终将计数器卡在 1 上一直到他们死。 sum(rate()) 对于那些人来说仍然是 0,即使你每秒可能有 100 万个。

      我不确定是否可以建议在许多短期实例的情况下进行客户端监控的最佳方法是什么。但我有兴趣向其他人学习在这种情况下该怎么做。

      有两个问题需要解决:

      • 使用抓取策略,您可能会错过现有的一小部分信息。
      • 如前所述的短寿命计数器,即使正确刮擦也通常无用。

      鉴于上述情况,我认为您的解决方案将围绕推送方法(不一定是 Prometheus PushGateway,请参阅 https://prometheus.io/docs/practices/pushing/)和/或一些中间聚合,即使这通常违反 Prometheus 原则。我想。

      将您的事件推送到中间计数器将确保您不会在两次刮擦之间丢失事件,并且由于该中间计数器将长期存在,因此它们的计数器也将长期存在,然后可以被 Prometheus 愉快地刮擦。

      所以,让我们听听别人的意见。

      【讨论】:

        猜你喜欢
        • 2021-04-21
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2019-08-11
        • 1970-01-01
        • 1970-01-01
        • 2014-08-10
        相关资源
        最近更新 更多