Karl-Martin Karlson已经在Pipedrive的可观测性团队工作了四年多，实现并支持了几个可观测性平台，如Grafana、Prometheus、Graylog和New Relic。
在销售中，就像在生活中一样，你不能控制你的结果，但你可以控制你的行动。
考虑到这一点，一个销售专业团队于2010年开始构建一个客户关系管理(CRM)工具，帮助用户可视化他们的销售流程，并完成更多工作。所以，他们创造了Pipedrive这是第一个由销售人员为销售人员打造的CRM平台。Pipedrive是基于基于活动的销售，这是一种经过验证的方法，主要是关于安排、完成和跟踪活动。
然而，Pipedrive很快就有了另一个启示:如果你无法控制自己的可观察性，你就无法控制自己的行为(或扩大业务)。因此，我们在五年多以前实现了Prometheus，并且它很快成为了关于服务应该如何导出监视指标的公司标准。
在我们的堆栈中，当部署一个新的微服务时，开发人员所需要做的就是添加prometheus_exporter注释并将正确的库包含到它们的服务中。然后，这些指标将被自动拾取，并可以通过它们进行查询Grafana普罗米修斯在一件事上争得时间间隔。
问题:扩展联邦普罗米修斯部署
我们的监控设置也随着公司的发展而发展，从一个物理位置扩展到一个联邦设置，除了部署在五个产品区域和五个测试/开发区域的AWS之外，还有三个物理数据中心。我们整个公司都在使用Grafana，大约有500个活跃用户利用Grafana进行可视化和报警．
到今年为止，我们一直在使用联邦部署模型，在每个数据中心都有一个Prometheus联邦器，从所有服务、虚拟机、主机收集指标，两个主要的Prometheis(测试和实时)从这些联邦器收集指标到一个中央聚合位置。
但是大约8个月前，我们开始注意到Prometheus实例的问题，它开始崩溃，并且没有明显的原因导致内存不足。增加资源只能工作到32v CPU和256GB内存-除此之外，增加更多的资源是徒劳的，并没有解决我们的问题。普罗米修斯重启也花了15分钟重放WALs。这不是我们所能承受的延迟，因为我们的整个观察和警报策略都依赖于普罗米修斯的可用性。
对于聚合的Prometheus实例，当我们达到~ 800万个活动系列、~ 2000万个块和~200k个标签对时，问题就开始了。
大约在同一时间，我们开始考虑替换我们聚合的Prometheus实例Grafana Labsbob电竞频道Grafana Mimir推出．考虑到Mimir引入的所有功能，例如快速查询性能而且提高压实工具，我们决定直接执行Grafana米密尔放到我们的堆栈中。
在Pipedrive上配置Grafana Mimir
一个由两名工程师组成的团队花了大约两到三个月的时间在我们的设置中完全实现、扩展和优化Grafana Mimir。我们开始逐步实现Mimir，同时我们的整个Prometheus堆栈仍在运行，并在没有任何更改或服务中断的情况下复制了所有数据。
为了优雅地从Prometheus迁移到Mimir，我们配置了Prometheus联邦器以远程写入Mimir，并使Mimir作为Grafana中的新数据源供每个人在PoC期间进行测试。
在Mimir数据与我们所有的Prometheus同步之后，我们开始透明地将发送到聚合的Prometheus实例的查询请求重定向到Mimir，并且使用Prometheus度量逐步优化了所有用户和服务的Mimir配置和部署。特别是，我们花了一些时间微调每个Mimir租户的限制以及每个Mimir微服务的CPU和内存需求，根据我们的使用模式调整配置。
迁移对我们的用户来说是完全透明的——这对我们的可观察性团队来说是一个巨大的胜利。
Grafana Mimir (Pipedrive):通过数字
Pipedrive的Grafana Mimir生产集群目前运行在Kubernetes上，使用微服务部署模式，处理以下流量:
- 之间的1200万和1500万活跃系列，这取决于一天中的时间
- 400 k /秒的样品在写路径上接收
- 600查询/秒平均在读路径上成功执行
- 豆荚资源:
- 52个摄取器(1.5CPU / 9GB内存)
- 30个分配器(1.2CPU / 1.5GB内存)
- 10个store-gateway (3CPU / 5GB内存)
- 2台压缩机(2CPU / 3GB内存)
- 18个查询器(1.5CPU / 3GB内存)
- 18查询前端(0.3CPU / 0.5GB内存)
Grafana Mimir的好处
迁移到Mimir的最大好处是解决了我们所面临的Prometheus可伸缩性限制。以前，我们的主要Prometheus实例在高负载下内存不足。这导致随叫随到的工程师日夜不停地接收页面，整个公司失去了宝贵的可观测性数据，直到普罗米修斯恢复，这通常需要很长时间。迁移到Mimir给了我们更大的扩展空间，因为Pipedrive服务开始每天公开越来越多的指标。
此外，与Grafana Mimir的基数分析API而且主动系列定制跟踪器，我们已经能够检查哪些服务暴露了最高的基数指标，这使我们能够始终如一地对它们进行微调。
而且，如果有一个(无意的!)恶意查询，它也不能使整个Mimir堆栈瘫痪。我们在Mimir中观察到的最糟糕的情况是一些查询前端和/或查询器荚被OOM杀死，但这对同时发生的其他请求没有重大影响。在Prometheus中，同样的场景将导致重新启动整个服务，在我们的例子中，这意味着我们的整个指标堆栈大约有10分钟的停机时间，所有随叫随到的工程师都会收到错误的警报。
Mimir每个租户限制也非常有用。它们有助于限制在每个租户基础上摄入和查询的数据量，并防止整个系统在高负载下超载甚至崩溃。Limits让我们能够在产品服务级别上解决高基数度量的根本原因，而不会影响整个可观察性堆栈，直到问题得到解决。
Pipedrive的Grafana LGTM堆栈的未来
我们继续在堆栈中优化Grafana Mimir设置，并找到适合我们的配置和限制。我们还利用了预配置Grafana Mimir仪表板和警报．
Grafana和Grafana Mimir已经成为我们用来监控Pipedrive服务和流程的标准工具。我们从一开始就对我们的工程师进行灌输:每个加入Pipedrive的新工程师都会接受一个入门课程，解释Grafana和Mimir的基础知识，让他们开始使用我们的堆栈——它只会从这里扩展。到目前为止，我们已经有了很多使用Grafana平台的经验，所以我们计划进行测试Grafana洛基而且Grafana节奏在未来几个月内更换我们现有的日志和跟踪平台。
Grafana云是开始使用度量、日志、跟踪和仪表板的最简单方法。我们有一个慷慨的免费永远层和计划为每个bob体育手机二维码用例。现在免费注册！
