使用 InfluxDB 堆栈构建指标和警报即服务 (MaaS) 监控解决方案

作者：Chris Churilo / 产品, 用例, 开发者
2020 年 6 月 25 日

企业规模越大，需要监控的系统和应用程序就越多，其监控系统也必须更具可扩展性，才能跟上业务增长的步伐。这是 RingCentral 面临并解决的挑战，RingCentral 为企业提供基于云的通信和协作解决方案。

RingCentral 使用 InfluxDB Enterprise、Kapacitor 和 Telegraf 构建了一个 监控解决方案，该解决方案支持其产品四大支柱（云 PBX、联络中心、视频和会议以及团队消息）以及构建在这些支柱之上的功能的可见性、集成配置和警报，以提高运营效率和加快 DevOps 周期。RingCentral 构建的监控解决方案还通过 DIY 框架为其开发人员和运维工程师提供指标和警报即服务 (MaaS)，以便他们能够自助服务其监控需求。

以下是 RingCentral 解决方案开发历程中的一些亮点，首先从其业务性质以及他们着手解决的问题开始。

通过指标和警报即服务获得可见性

RingCentral 是一家总部位于加利福尼亚的全球 IP 电信公司，致力于与其客户一起重新构想业务通信和协作。在一个对停机时间零容忍的苛刻行业中，RingCentral 正在提供可靠的解决方案，协作通信是其一切工作的核心。

随着 RingCentral 的发展以及其 IT 基础设施变得更加复杂，跟踪和理解 IT 环境中的信息变得越来越重要。“我们目前的监控团队规模很小，而工程团队却在不断壮大，因为我们必须满足所有业务需求和所有新功能，”RingCentral 的首席系统架构师 Yuri Ardulov 说。

尽管监控团队规模很小，但公司的监控基础设施必须应对其不断增长的运营和电信服务业务。

此外，RingCentral 制定了一个目标，即精简其流程，以更有效地管理开发、配置更改以及其不断增长的应用程序环境（该环境由 400 多个不同的“自制”组件组成，由 1,500 名开发人员的团队持续开发）的指标和事件收集。

RingCentral 决定为开发人员和运维工程师提供一种可编程的方式来自助服务其监控需求：监控他们的“自制”系统及其操作层。监控团队着手为其他团队提供一个平台和工具集，以便他们发送指标并设置他们感兴趣的警报。

具有高可用性和指标粒度的监控解决方案

为了实现他们的自助式 (DIY) 框架，必须满足某些技术要求

• 警报和仪表板即代码
• 发送没有结构要求的应用程序指标
• 具有高可用性集群的水平可扩展基础设施
• 在发布新代码之前用于测试新代码的沙箱
• 对基数或指标类型没有硬性限制
• 与部署系统完全集成的自动化服务
• 无单点故障

当时，他们正在使用 Zabbix 监控工具集，但已超出其容量，需要用提供高可用性 (HA) 和指标粒度的解决方案来替换它。第一步，他们迁移到了 开源 InfluxDB 平台。经过初步评估，他们部署了

• InfluxDB Enterprise，以处理他们的指标和事件量增长（InfluxDB 的 Enterprise 版本提供了 Zabbix 缺乏的高可用性、可扩展性和指标粒度）
• Telegraf 作为安装在每台主机（物理或虚拟）上的代理，用于收集监控数据
• 一个 Kapacitor 池，用于实现零停机时间，以满足他们的警报要求（因此不会错过任何触发事件）
• 一个内部构建的 Kapacitor Manager，用于管理他们的 Kapacitor 实例池

InfluxDB 作为 RingCentral 的指标和警报即服务平台

为了满足上述 DIY 技术要求，RingCentral 决定向其所有工程团队引入他们所谓的“服务清单”。通过此功能，开发人员和运维工程团队将能够以代码的形式表达他们的指标和警报要求。

清单由 RingCentral 的系统编译，并与代码本身一起发布。它依次经历每个阶段，然后自动进入生产系统，无需任何单独的安装或配置。

RingCentral 的监控解决方案架构

RingCentral 拥有单独的开发、性能测试和暂存环境。下图显示了他们计划在每个环境中安装的系统设计

• InfluxDB Enterprise 集群和 HAProxy 位于前端，以确保所有传入的指标都将在此处进行平衡。
• Telegraf 安装在每台主机（虚拟或物理）上，用于收集所有指标。
• 通过部署系统，服务清单在发布周期内编译所有将在主机端交付的适当配置。
• 所有数据都应该交付给 Kapacitor 以进行警报。

由于要求之一是无单点故障，因此在不同的 Kapacitor 上运行两个 Kapacitor 任务，以便在必要时复制警报。因此，他们拥有一个 Kapacitor 池，以满足每个环境 50,000 多个触发器。

内部构建 Kapacitor Manager

为了满足 Kapacitor 池的警报要求，RingCentral 设计了 Kapacitor Manager。

Kapacitor Manager 由几个实例组成，这些实例被组合并基于持久队列。它提供三种类型的 API，如上图所示：任务管理 API、Kapacitor 节点管理 API 和作业 API。

有相当多的队列工作进程能够从队列中选取不同的任务并执行它们，因此队列是持久的。RingCentral 计划为其每个位置运行 Kapacitor Manager。

检测和生成更改事件

RingCentral 的 OCP 系统是单核处理系统，性能非常低且可扩展性非常差。这要求他们在 Kapacitor 池周围构建一种机制来检测事件本身（从而检测事件状态的变化）。他们还需要减轻事件处理器上的负载，因此决定将事件状态保存在 InfluxDB 内部。

因此，他们在 InfluxDB 集群内部署了两个数据库：指标数据库（所有指标都在其中收集）和事件数据库。因此，他们的 Kapacitor 节点分为两个类别。在他们创造性的节流解决方案中，InfluxDB 和 Kapacitor 调节事件流，以避免阻塞复杂事件处理 (CEP) 系统，并为事件记录提供安全网。

与业务增长保持同步的监控基础设施

自从迁移到 InfluxDB 以来，RingCentral 的监控系统已经取得了长足的进步。他们的可扩展性模型需要与他们应用程序环境的动态特性相匹配，而他们选择 InfluxDB 平台对他们很有帮助，因为它的组件可以与其他现代系统（如 Kubernetes）结合使用。

选择 InfluxDB Enterprise 使 RingCentral 的监控基础设施能够跟上其业务增长的步伐。这种选择，结合部署 Telegraf 进行指标收集和 Kapacitor 进行警报，使他们的小规模监控团队能够构建 Kapacitor Manager，并为其复杂运营实现自动化实时警报系统。要了解有关此引人注目的 DevOps 监控用例的更多信息，请阅读完整的案例研究。

如果您有兴趣分享您的 InfluxDB 故事，请点击此处。