Hiya 迁移到 Grafana Cloud，以降低成本并更好地控制其指标

Hiya 成立于 2016 年，从一开始就是一家以容器为中心的 Kubernetes 公司。“对我们来说，拥抱容器化的技术套件至关重要，”Hiya 核心技术团队的高级软件工程师 Jake Utley 说道。

两年多以前，一组工程师开始使用 Prometheus，而公司其他部门仍然依赖于供应商产品进行监控。这组工程师最初之所以进行切换，是因为他们负责 Hiya 的大量指标，而且他们一直难以维持现有供应商产品的成本。

时间来到 2019 年。工程师们对 Prometheus 非常满意，他们对公司其他部门仍在使用的服务感到沮丧。“我们发现现有的解决方案无法提供我们想要的指标控制权，”Utley 说。“我们需要能够过滤或聚合指标的工具，这样可以帮助我们维护一个更小的指标集。否则，我们不得不摄取所有数据，无论我们是否使用它们。”

是时候进行全公司范围的切换了。

Cortex 为大多数 Prometheus 部署提供了缺失的元素：跨多个集群和区域的统一操作视图。

Dan Sabath，高级软件工程师，Hiya

选择 Grafana Labs

Hiya 选择 Grafana Labs 的 Grafana Cloud Hosted Prometheus 有几个原因。首先，Utley 表示，他们认为 Prometheus 和 Grafana 的组合是监控 Kubernetes 集群和容器的行业标准。

他们也喜欢 Prometheus 提供的高度控制和透明度，这是他们使用其他服务时所不具备的。高级软件工程师 Dan Sabath 说：“我们希望能够查看我们自己的信息并彻底了解它。”

与其他主要的指标收集器相比，Utley 喜欢您可以直接查询本地 Prometheus。“您可以使用复杂的远程写入规则来过滤或修改从 Prometheus 发送到外部系统的指标，”他说。“拥有这种程度的控制权是我们非常想要的。没有它，我们就必须去找已经很忙的工程团队，让他们对应用程序进行所有这些小改动。作为组织内的核心工程团队，我们希望控制这些改动，避免对其他团队进行微管理。”

但是，由于他们会将指标从 Prometheus 发送到另一个系统，Hiya 面临的一个大问题是：“接下来我们该怎么做？”

Utley 说，为了扩展 Prometheus，他们曾考虑过在内部运行 Cortex 或 Thanos（两者都是用于水平扩展 Prometheus 兼容监控系统的开源项目），或者使用其他提供商，但他们得出结论，Grafana Cloud“最符合我们想要实现的目标。”

事实上，对于 Hiya 来说，一个关键的卖点是 Grafana Cloud 由 Cortex 提供支持。“我们可以坚持使用开源工具，需要时可以进行深入的代码审计，并且可以依靠社区，”Utley 解释道。此外，他说，“我们不必担心管理和理解所有的基础设施。”

Hiya 团队还被 Cortex 的一些关键功能所吸引：拥有一个包含所有数据的集中地，能够去除重复的数据副本，以及能够拥有任意时间线的数据。

但真正的改变在于 Cortex“为大多数 Prometheus 部署提供了缺失的元素：跨多个集群和区域的统一操作视图，”Sabath 说道。

之前，Hiya 一直使用 HA 对进行操作——这是 Prometheus 的标准做法——这意味着每次运行查询时，结果可能会因命中的 Prometheus 而异。“我们有时间线限制，所有数据都在磁盘上，而且我们必须查询许多 Prometheus，这很麻烦，”Utley 说。

Thanos 和 Cortex 都为此提供了解决方案，Utley 认为 Thanos 似乎更容易运行，这使得它成为 Hiya 最初的首选。然而，当他深入研究 Cortex 的工作原理时，Utley 改变了主意：“它旨在处理大规模数据，而 Thanos 旨在成为现有 Prometheus 集之上的一个层。如果我们要将数据发送到外部提供商，我们更愿意使用 Cortex。”

我们可以审计我们的数据，查看哪些指标具有最高的基数，或者查看哪些服务发布了最多的指标序列。这为我们提供了机会，知道在哪里过滤掉指标以实现最大影响……我们多年来一直想要这种级别的可见性，直到现在才实现。

Jake Utley，高级软件工程师，Hiya

实施详情

Hiya 在实施阶段面临两大挑战：最大的挑战是将多年的仪表盘、告警、指标、遗留服务和遗留仪表盘从之前的提供商迁移到 Prometheus。编写自动化脚本来迁移初始仪表盘是 Hiya 得以在一个季度内完成向 Grafana Cloud 迁移的主要原因之一。

另一个问题是 cron 作业指标。此前，有一个非常直接的集成，允许 Hiya 的所有 Kubernetes cron 作业以一种方式实现，使其能够直接将其作业结束指标发送给服务提供商。对于大多数非 cron 作业的服务，Hiya 使用 Prometheus endpoints，并让之前的公司抓取数据。

需要做一些工作才能使一切在 Prometheus 范式下顺利运行。Utley 解释说：“我们通过使用 Prometheus Pushgateway 将这些指标重新连接到标准工具集中解决了这个问题。”

Hiya 的一些团队在从基于 Web、点点鼠标的服务切换到使用 PromQL 的服务时也遇到了困难。Utley 说：“Grafana 有很多小功能可以帮助更容易地编写 Prometheus 查询。”但是，仍然需要大量的培训、动手调试、指导和 Slack 消息交流，因为团队需要学习理解 PromQL 的差异，并弄清楚他们为什么看到那些数据。

此外，Hiya 最初在告警选项方面遇到问题。他们对旧的 Prometheus 告警设定了基准，但新的 Grafana 告警不符合他们的要求。

得益于 Grafana Labs 团队的支持，他们通过提前体验 Grafana 提供的 Cortex Ruler 和 Hosted Alertmanager 服务解决了这个问题。Utley 说：“这使得我们可以使用 Prometheus 告警，这非常好。”然而，由于该服务是新推出的，并不完美。“因此，我们与一位在 Cortex 工作的 Grafana Labs 工程师合作，调整产品以满足我们的需求。这是一种非常亲力亲为的关系，我们对此非常感激。”

结果

Hiya 切换到 Grafana Cloud 在许多方面都取得了回报。

核心技术团队的工程经理 Jorge Barrios 表示，与之前相比，公司“节省了可观的资金”，Sabath 补充说，他们现在“对我们实际付费的指标有了深入的了解。”

Hiya 正在利用 Prometheus 中的功能来获取这种洞察。Utley 说：“我们可以审计我们的数据，查看哪些指标具有最高的基数，或者查看哪些服务发布了最多的指标序列。这为我们提供了机会，知道在哪里过滤掉指标以实现最大影响。这些审计可以通过 PromQL 或使用 Prometheus API 完成，以获取系统中每个指标的完整数据转储。我们多年来一直想要这种级别的可见性，直到现在才实现。”

因此，他们过滤掉了一些几乎从不使用的非常简单的指标，Utley 还进行了审计以寻找潜在的未来节省机会。他说：“如果服务以六个不同的百分位数发布延迟，我们可能只需要其中的三个。”“或者我们可以为高基数指标编写规则，以去除每个 pod 的粒度。这类改动通常会带来显著的节省。”

完全集成 Grafana 后，Hiya 在 Grafana Cloud 中约有 56 万个活跃序列。自那时以来，他们已成功将指标数量减少到约 40 万个活跃序列。

深入仪表盘

Hiya 的工程团队在使用 Grafana Cloud 仪表盘方面拥有很棒的体验。

Utley 说：“许多工程师都很兴奋地分享他们创建的仪表盘。”饼图插件是许多团队的最爱；他们也大量使用文本面板。这项功能在他们之前的服务中可用，但他们很少使用。

Utley 指出：“这是一项简单的功能，却能带来惊人的效果。”通过能够解释图表是什么、它们的含义以及为何重要，这使得不擅长阅读图表的人也能更容易理解。

核心技术团队响应了许多操作告警，因此 Barrios 表示，如果他值班并且对另一个团队的系统了解不深，文本功能也非常有用：“查看他们的图表以了解他们的服务是否正常运行，并且随时随地都能获取这种上下文信息，这非常有用。”

展望未来

展望未来，Sabath 表示，他希望将标准化的仪表盘添加到 Hiya 的基本部署框架中。

Utley 也期待使用即将推出的支持嵌套在表格中的可视化的 Grafana 功能。“我希望有一个所有 Kubernetes 集群的清晰列表，显示每个集群的高级健康概览，”Utley 说。“拥有一个恰当的可视化，而不仅仅是一个数字，将会非常令人兴奋。”

最终，选择 Grafana Cloud 对 Hiya 来说是一个明智的决定。Utley 说：“我们长期以来对 Prometheus 和 Grafana 作为开源工具印象深刻，现在我们拥有一个基于它们的托管服务。”