今天,我们宣布Grafana云代理(编者按:现在称为Grafana代理)的一个子集,普罗米修斯建立托管指标运行依靠记忆和使用相同的代码,使普罗米修斯那么棒。
Grabob电竞频道fana实验室,我们爱普罗米修斯。我们的内部监控,部署它与Alertmanager使用它,并让它向皮层通过其数据配置remote_write。不幸的是,当我们处理规模超过400万个活跃系列在一个普罗米修斯,我们部署变得越来越难以管理。虽然大多数组织没有许多系列,我们越来越需要垂直规模运行普罗米修斯的节点来处理日益增长的内存使用。
大内存需求导致它被一个风险点故障。如果它耗尽内存,我们不再监视我们的基础设施。一个常见的解决方案是分片普罗米修斯实例开始,但我们更喜欢每个集群操作一个普罗米修斯实例,并适当添加分片可以不平凡的。一般来说,我们需要仔细看普罗米修斯保持监测系统运行。
来说,这是一个常见的问题组织运行在同一大规模普罗米修斯,和感觉更大的负担当使用托管指标皮层等解决方案。皮质的用户不需要本地存储和查询;数据已经发送到皮层remote_write,还有一个Prometheus-compatible查询API。此外,如果它是容易切分我们整个集群范围的普罗米修斯配置,我们就不会有相同的规模问题前面提到的。所以我们创建Grafana云代理,建立简化运行Prometheus-style基础设施在使用托管标准的解决方案。
它是什么?
正如这篇文章的标题所暗示的那样,Grafana云代理是普罗米修斯的子集没有任何查询或本地存储,使用相同的服务发现、重新确认,,和remote_write代码中发现的普罗米修斯。感谢削减到只需要部分与皮层,测试我们的第一个版本已经看到了内存使用减少40%相比,一个等价的普罗米修斯的过程。
代理可以部署有或没有我们要求的东西主机过滤。主机过滤,启用时,忽略了任何目标发现,发现在不同的机器上的一个代理上运行。这是特别有用,当部署代理Kubernetes DaemonSet:每个代理只能勉强从豆荚和发送指标,运行在相同的节点代理。这允许分配内存使用跨集群而不是在一个节点上,但这也意味着,如果节点本身开始出现问题,指标显示这些问题不会交付remote_write和报警系统。
无论主机启用过滤,迁移到Grafana云代理相对无痛的,只有一点点的迁移工作。我们已经写了简短的指南解释如何配置代理普罗米修斯从现有的配置。
我可以用它没有Grafana云吗?
尽管名字相似Grafana云,我们的托管平台指标和日志,您可以使用Grafana云代理与任何平台,支持普罗米修斯remote_writeAPI。在未来,我们打算捆绑可选特性,使代理与Grafana云合作的天衣无缝,但它总是可以使用它与任何remote_write兼容的服务。
另一个代理商吗?
之前我们冒险向世界释放另一个代理,我们认真审视今天是可用的。而其他收集代理可以用来收集普罗米修斯指标,它们也有同样的问题。这些代理不感觉像普罗米修斯,丢失的特性我们依靠像服务发现或重新确认规则。最后,替代方案觉得万事通,不精。bob彩票中奖计划
我们采取了不同的方法。通过直接关注普罗米修斯,我们可以让它觉得一等公民。让更少的妥协与我们的代理,我们希望用户相比减少摩擦在迁移到代理。简而言之,而其他代理做刮Prometheus-style指标的支持,我方的代理感觉就像普罗米修斯因为它是基于普罗米修斯。
权衡
通过优化Grafana云代理来减少资源需求,我们不得不做一些权衡在普罗米修斯和删除一些功能标准。最重要的是,代理不支持录音或报警规则。乍一看,这似乎是完全矛盾的普罗米修斯的主要目的(当然,这是提醒)。然而,我们现在支持记录规则和警报在皮层和Grafana云。这有助于平衡决定移除在代理的支持,尽管它还瓶颈的可靠性警告托管解决方案的可靠性。
路线图
我们打算扩展Grafana云代理收集所有类型的数据,支持Grafana云。支持两种石墨和洛基最终将包含在代理。
同时,我们计划在另一个部署模式我们已经调用的代理抓取服务模式,一群特工将沟通和其他代理之间刮负载平衡集群中。这将有助于解决一些权衡前面提到的这篇文章,重新捕捉的能力指标等问题当分片代理节点。留意关于未来的更多信息。
试一试!
码头工人图像和静态二进制文件是可用的GitHub发布页面。我们一直满意代理给我们的好处,我们兴奋的让别人去试试,。让我们知道你的想法!
了解更多关于皮质
如果你发现更多关于皮质感兴趣,报名参加我们的研讨会定于3月31日上午九时三十分于PT。会有一个预览即将到来的皮层1.0版本新特性的一个示范,问答与皮层汤姆·威尔基和高Veeramachaneni维护者。
