使用 InfluxDB 堆栈构建指标与警报即服务（MaaS）监控解决方案

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

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

使用 InfluxDB 企业版、Kapacitor 和 Telegraf，RingCentral 构建了一个支持其产品（云 PBX、接触中心、视频和会议、团队消息）及其构建在这些支柱之上的功能可见性、集成配置和警报，以及操作效率的监控解决方案。RingCentral 构建的监控解决方案还通过 DIY 框架向其开发者和运维工程师提供指标与警报即服务（MaaS），使他们能够自助满足其监控需求。

以下是RingCentral解决方案开发历程的一些亮点，从其业务性质和旨在解决的问题开始。

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

RingCentral是一家全球性的美国加州IP电信公司，与客户合作重新构想商业通讯和协作。在客户对停机时间零容忍的行业中，RingCentral提供可靠的解决方案，将协作通讯作为其所有工作的核心。

随着RingCentral的增长和IT基础设施的日益复杂，跟踪和理解IT环境中的信息变得越来越重要。“与不断增长的工程团队相比，我们目前的监控团队规模很小，因为我们必须解决所有业务需求和所有新功能，”RingCentral的首席系统架构师Yuri Ardulov说。

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

此外，RingCentral设定了一个目标，即通过更有效地管理开发、配置变更以及不断增长的应用环境（由1500名开发人员不断开发的400多个不同“自制”组件组成）的指标和事件收集，简化其流程。

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

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

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

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

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

• InfluxDB企业版来处理他们的指标和事件量增长，（InfluxDB企业版提供了Zabbix缺乏的高可用性、可扩展性和指标粒度）
• Telegraf作为安装在每个主机（物理或虚拟）上的代理来收集监控数据
• 一个没有停机时间的

  Kapacitor池来满足他们的警报要求（因此不会错过任何触发事件）

• 一个内部构建的

  Kapacitor Manager来管理他们的Kapacitor实例池

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

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

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

RingCentral的监控解决方案架构

RingCentral有单独的开发、性能测试和预发布环境。下表显示了他们的系统设计，他们计划将其安装在每个环境中

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

由于有一个要求是无单点故障，因此在一个Kapacitors上运行两个Kapacitor任务以在必要时复制警报。因此，他们有一个Kapacitor池来满足每个环境50K+触发器的需求。

内部构建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企业释放了RingCentral的监控基础设施，使其能够跟上其业务增长。这个选择，结合部署Telegraf进行指标收集和Kapacitor进行警报，使他们的小型监控团队能够构建Kapacitor Manager，并为其复杂的操作实现自动化的实时警报系统。要了解更多关于这个引人入胜的DevOps监控用例的信息，请阅读完整的案例研究。

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