在亚马逊云科技上构建多区域的统一资源监控平台 – Part 1

浏览本文需要约 15 分钟，建议按照章节分段阅读。

作为企业的运维团队，在维护大规模云基础设施时，需要深入了解系统的性能和健康状况，有效地检测和解决问题，并为最终用户提供更好的体验，而可观测性是基础设施管理中的一个关键方面。不管是监控基于虚拟机的应用程序，还是基于容器的应用程序，都会面临诸多挑战。首先，需要监控的指标会很多，监控数据的基数会变的非常大，既需要一个节省空间的存储模型，又需要满足高效的查询返回结果。其次，基于容器的系统是不断变化的，在多样化的环境下摄取、处理和存储监控数据本身也是一种挑战。

本文以企业客户的使用场景为例，将监控系统部署在新加坡区域（ap-southeast-1），同时监控北京区域（cn-north-1）和东京区域（ap-northeast-1），通过架构选型，指标采集，平台配置，面板展示，邮件告警五部分，介绍如何构建多区域的统一资源监控平台的过程。

1. 监控系统选型

基于上述需求，需构建一套多方位的监控系统，能够集业务服务、中间件、云上资源于一体，既简单易用，又便于维护。

1.1 监控数据的特点

监控系统的数据通常与时间强相关，这些数据是具有时间戳的数据流，属于某个度量指标（Metric）和该度量指标下的多个标签（Label），如下图所示，如果使用关系型数据库存储这类数据，不但性能差，而且压力也较大，而时序数据库良好的读写性能与数据压缩比可以很好的支撑这些数据。

1.2 监控系统的选择

如下图所示在 DB-Engines 中排名前三的时序数据库分别是 Prometheus、InfluxDB 和 Kdb，这三款也是业内比较知名，且在生产中被使用的时序数据库，可参考 DB-Engines 查看更多介绍。

Kdb 主要是为处理金融、物联网等领域的大量时间序列数据而构建的，国内许多证券公司和私募基金，全球的投行、高盛和摩根大通都有在使用，其更具有行业属性。Kdb 列式存储的特性，使得它对于某个列的统计分析操作非常方便。作为一款内存数据库，Kdb 对服务器的配置要求较高，需要较大的内存来存储所有的数据；但 Kdb 开发生态不够成熟，虽然其社区在不断发展，但是相比较于 InfluxDB 和 Prometheus，其开源库和工具还是比较少。

InfluxDB 和 Prometheus 是在生产中被广泛使用的时序数据库，其监控体系也已经很完善，开源库和工具也非常的丰富。从功能上比较两者之间不分伯仲，如下图所示，可以从数据采集、数据存储和数据查询三个维度适配不同的监控需求，国内监控系统使用 Prometheus 会更多一些。客户因为之前就在使用 Prometheus 监控传统网络指标，所以继续延用这套系统监控云上资源。

	Prometheus	InfluxDB
监控体系	Exporter+ Prometheus+ Grafana + Alertmanager	Telegraf + InfluxDB + Grafana + Kapacitor
高可用和集群功能	商业版本支持集群功能开源版只支持单机	开源版只支持单机
数据采集	Exporter/Pull or Push	Telegraf/ Push
数据存储	数据无法长久保存，基于本地存储监控系统扩展比较难；数据存储在基于主机或 URL 等标签，并按各种维度分组的时间序列表	数据可以长久保存，使用Influx-Relay将写入查询代理到多个InfluxDB 实例；将数据存储在称为存储桶的逻辑命名空间中，每个存储桶都配置了一个保留期
数据查询（1分钟内存使用率）	100 – (node_memory_MemAvailable_bytes{job=”node1″}[1m])	select 100 – usage_idle from “autogen”.”mem” where time > now() -1m

2. Prometheus 的能力

2.1 Prometheus 的架构和生态

Prometheus 是一套开源的监控解决方案，是集监控、报警、时间序列数据库的组合，它具有多维数据模型，适合从容器和虚拟机收集时间序列数据。除了提供存储功能，Prometheus 还可以利用查询表达式来执行非常灵活和复杂的查询，更多关于 Prometheus 的介绍请参考官网链接。

Prometheus 基本原理是通过 HTTP 协议周期性抓取被监控组件的状态，对应的组件只要提供 HTTP 接口（也称为 Exporter）就可以接入监控，目前企业中常用的系统组件大部分都有对应的 Exporter 可以直接使用，比如 Linux OS，Windows OS，MySQL，Nginx，HAProxy 等，具体可查看被支持组件的官方列表。利用这些 Exporter，可以快速构建监控体系。

2.2 Prometheus 的组件

Prometheus 系统主要有下列组件构成，如下图所示：

Prometheus Sever：核心组件，负责实现对监控数据的抓取，存储和查询。包含了 Retrieval，TSDB，HTTP Server 和 Storage
Exporter：将监控数据采集的端点通过 HTTP 服务的形式暴露给 Prometheus Server，Prometheus Server 通过访问该 Exporter 提供的端点，获取需要采集的数据
Service Discovery：服务发现，Prometheus 支持多种服务发现选项，包括 Kubernetes、Consul 和文件等
AlertManager：在 Prometheus Server 中基于 PromQL 创建告警规则，如果满足定义的规则，则会产生一条告警。从 Prometheus server 端接收到 alerts 后，AlertManager 会进行去除重，分组，路由到对应的接受方式，发出告警
PushGateway：Prometheus 数据采集默认是基于 Prometheus Server 从 Exporter Pull 数据，但某些条件下不允许 Prometheus Server 和 Exporter 进行通信，可以使用 PushGateway 来进行中转，将监控数据主动 Push 到 PushGateway后，再将数据从 PushGateway Pull 到 Prometheus Server

2.3 数据采集是 Pull 还是 Push

Prometheus 默认采用定时 Pull 模式拉取目标端的数据，即被监控的 EC2 安装 Node_Exporter 程序，并暴露出一个 HTTP 接口，Prometheus 通过基于 HTTP 的 Pull 的方式来周期性的采集数据。但是如果 EC2 所在的安全组做了入栈流量的限制，就需要在所有 EC2 对应的安全组上都打开 8080 端口，操作比较繁琐。如果 EC2 对出栈流量没有限制，可以采用各个 EC2 往 Pushgateway 上 Push 数据，然后 Prometheus 去 Pushgateway 上定时 Pull 数据，可以省去修改安全组出栈流量的步骤。

但是 Pushgateway 本身存在一些弊端，比如通过单个 Pushgateway 监控多个实例时，Pushgateway 将会成为单点故障和潜在瓶颈；Pushgateway 会持久化推送给它的所有监控数据，需要定时手动清理不需要的数据。基于上述原因，客户试图寻找一种通过 Push 方式且比较稳定的指标采集工具。

2.4 采集工具的选择

Categraf 是一款 All-in-One 的开源 telemetry 数据采集器，不同于 Prometheus 的各种 Exporter，所有的采集工作用一个 Agent 就可以搞定。支持指标、日志采集；支持虚拟机、交换机、容器、K8s、多种中间件和数据库的数据采集；支持混合云架构、云原生架构和多云架构，其更多功能和特点可以查看 Categraf 介绍。

Categraf 是以 Push 的方式将指标推送给 Prometheus Sever，对于已有安全组的出栈流量不用再做额外的设置。Categraf 一个关键优势是支持 Remote_write 写入协议，可以将数据写入 Promethues、M3DB、VictoriaMetrics 或者 InfluxDB 。

3. 架构选型

3.1 自建还是托管

在业务发展初期，自建 Prometheus 监控是大多数客户的选择，各个服务 Push 监控数据到其对应的指标，由 Prometheus Server 定时采集数据并存储，配置 Grafana 展示数据和配置告警规则进行告警。但随着业务量的增长，监控指标的增多，意味着更多资源的投入，监控也有更高的要求。自建 Prometheus 会暴露出可扩展性差、性能瓶颈等一系列问题，比如仪表板加载慢或者加载失败，监控查询慢甚至失败，计算和存储资源开销大，指标需要存储更长时间，这些都给企业运维带来不必要的挑战。

Prometheus 自带单机版的时序数据库（TSDB），无法满足持久化存储历史告警信息的需求。Prometheus 提供了 remote_write 和 remote_read，将数据存储到远端和从远端读取数据。当配置 remote_write 特性后，Prometheus 会将采集到的数据通过 HTTP 的形式发送给适配器（Adaptor），由适配器对接外部的任意服务并将数据写入。目前在 Prometheus 社区中，已经有十二种远程存储的支持组件，InfluxDB 也是其中的一种后端存储，完整内容可参见 Prometheus 官网。

相比较自建的监控系统，亚马逊云科技推出 Amazon Managed Service for Prometheus（AMP），是完全托管的 Prometheus 服务。AMP 与 Prometheus 支持相同的指标、相同的 PromQL 查询，跨多个可用区运行实现高可用性，并由 CNCF Cortex（对 Prometheus 进行了扩展，提供多租户方式）提供支持实现水平可扩展性。托管的 AMP 是一个安全的，兼容 Prometheus 的环境来摄取、查询和存储监控数据，并随着业务量的增长自动扩展各项指标。

Prometheus 本身也可以作为远程存储的组件，托管的 Prometheus 默认启用 Remote Write 功能，接受从各种数据源 Push 过来的数据，包括 Prometheus Server 端发送过来的监控指标，如下图 Endpoint 所示，AMP 分别提供了 remote write URL with https 和 query URL with https。

Categraf 支持 remote_write 写入协议，可以直接将指标数据 Push 到 AMP 中，理想中的监控系统如下图所示，直接在客户端安装 Categraf Agent，在托管的 Grafana 查看 Dashboard。

3.2 remote_write URL 安全认证

如上图所示，AMP Remote Write URL 类似 https://aps-workspaces.ap-southeast-1.amazonaws.com/workspaces/ws-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/api/v1/remote_write，默认启用了 IAM 身份验证，需要通过 AWS Signature Version 4（SigV4）对所有 HTTPS 请求进行签名。当使用 HTTPS 向 AWS API 发出请求时，SigV4 会向 AWS 请求添加身份验证的信息。但是 Categraf 暂不支持 SigV4，即不知道如何对这个请求进行签名，如下图所示，可以使用 SigV4 side-car proxy container 的方式实现签名的过程，但实际部署中不可能在每个监控节点都去运行一个 proxy container。

考虑到上述问题，和实现多区域资源的监控目标，决定构建一套控制平面，如下图所示，即使用一套独立的 Prometheus Server 接收本区域和其他区域的采集指标，并从高可用和可扩展性上使用容器将其部署在 EKS（Amazon Elastic Kubernetes Service）平台。

如下图所示，Prometheus Server on EKS 作为控制平面将监控的指标源源不断的发送给数据平面 AMP，AMP 定时运行规则进行数据聚合产生新的时序数据或告警，采集到的指标会存储 150 天，然后自动删除。本文后续将使用手工方式部署 Prometheus 到 Kubernetes，如果对 Kubernetes 中的 Prometheus 的自动化部署、管理和配置不是很熟悉，可以使用 Prometheus Operator。

3.3 可视化展示

Grafana 是一个跨平台的开源度量分析和可视化工具，通过将采集的数据查询然后进行可视化的展示，而且提供了丰富的事件提醒接口。由于 Prometheus 自带的图形展示并不够强大，通常会将 Grafana 作为 Dashboard 配合 Prometheus 一起使用。

Amazon Managed Grafana （AMG）是由亚马逊云科技推出的可扩展、高可用的托管的开源 Grafana 服务，为监控和运营提供交互式的数据可视化。使用 AMG，对从可观测系统中的多个数据源收集的指标、日志和跟踪数据进行可视化、分析和告警。

AMG 会随着使用需求的增加自动扩展计算和数据库基础设施，以及自动化的更新版本和安全补丁。AMG 与 AWS IAM Identity Center 集成并支持 SAML 2.0，可以方便的为企业目录中的某些用户设置对特定控制面板和数据源的访问权限。

3.4 方案架构

经过上述讨论，在海外区域构建一套集中监控平台，使用控制平面（Prometheus Server on EKS）接收采集指标，海外其他区域和国内区域可以把各种指标通过互联网发送到数据平面（AMP），由展示平面（AMG）做可视化，并通过 Amazon Simple Notification Service（SNS）和 AWS Lambda 实现邮件告警，整体方案具备高可用和资源可扩展的能力。

在网络延时上，北京区域到新加坡区域的平均网络延时在 75ms，东京区域到新加坡区域的平均网络延时在 69ms，从上述两个区域基于互联网将采集数据 Push 到新加坡区域控制平面，从近半年的展示平面实际的可观测性效果来看，可以满足对北京区域和东京区域资源的实时监控需求。

4. AMP 与 CloudWatch 的比较

AWS 提供云原生的监控方案 CloudWatch 用于监控 AWS 托管服务的度量指标，同时提供了基于 CloudWatch Agent 的 EC2 实例监控解决方案。那 CloudWatch 和 AMP 有什么区别呢？

在功能方面，AMP 的优势在于它支持更丰富、更细粒度的数据采集场景，客户可基于自身需求定制监控指标。在成本方面，CloudWatch 基于采集指标数量及次数（API）收费，而 AMP 按照计算和存储进行收费。CloudWatch 价格和 AMP 价格对比如下图所示，假设有 100 台 EC2，每台 10 个采集指标/详细监控，每分钟收集一次，相比之下监控的指标越多，采集的频率越高，AMP+AMG（假设按一个 Workspace 供 2 个 Editor 和 3 个 Viewer 访问）在成本上就会更有优势。

5. 总结

本文主要讲述了在亚马逊云科技上构建多区域的统一资源监控平台的过程，包括监控系统选型，Prometheus 系统的能力，整体架构的选型，以及采用 AMP+AMG 方案和 CloudWatch 在成本上的比较。整体架构既支持国内区域的资源监控，也满足海外多区域的资源监控，基于统一展示平面有效地发现和解决问题，赋能运维团队，保障运营和业务团队。

在本系列第二篇文章中，我们会探讨指标采集和平台配置部分，包括批量部署 Categraf Agent，部署 Prometheus Server on EKS 和 AMP+AMG 的配置，从而构建一个完整的资源监控平台。