像 AWS 这样的服务商，如 AWS、Azure、Google Cloud 等，都提供了丰富的资源监控服务，但这些服务通常成本相对较高，且各云平台上的监控服务各不兼容。使用多云部署的用户也不想锁定到某一家服务商，基于云平台的 IaaS 服务使用主流开源软件搭建一套监控系统，是一种运维最佳实践。
此文以 AWS 云为示例，介绍如何使用无托管服务搭建一套全球资源监控系统。其它云平台类似。
核心目标：监控AWS基础资源健康、自搭建数字系统运行状态，无托管服务依赖，全球高可用，99.99%可用性。
一、核心设计边界与原则
1. 监控对象（明确聚焦）
- AWS基础资源：EC2、VPC（子网/路由表/安全组）、ELB（NLB/ALB）、S3（存储桶）、EBS、Route53等；
- 自搭建数字系统：K8s集群（Master/Worker节点）、中间件（Kafka/EMQ X）、数据库（MySQL/InfluxDB）、应用服务（微服务容器）等；
- 核心监控维度：资源使用率（CPU/内存/磁盘/网络）、服务可用性（存活状态/响应延迟）、故障事件（重启/崩溃/连接失败）、性能指标（QPS/吞吐量/查询延迟）。
2. 设计原则
- 无托管依赖：仅使用AWS基础资源（EC2、VPC、ELB、S3、ASG、IAM、KMS），自搭建所有监控组件；
- 高可用架构：多区域（≥3个）+ 单区域多AZ（≥2个）部署，无单点故障；
- 全球覆盖：跨区域指标聚合、就近访问监控面板，全球延迟<1秒；
- 轻量化采集：最小化采集端资源消耗，避免监控本身影响业务系统；
- 快速告警：故障检测→告警触发≤30秒，支持多级告警路由。
二、整体架构分层设计
架构总览
监控对象（AWS资源+自搭系统）→ 指标采集层（自部署采集器）→ 传输转发层（自搭Kafka）→ 存储分析层（Prometheus+Thanos）→ 可视化告警层（Grafana+Alertmanager）
↓ ↓
跨区域数据同步（Kafka MirrorMaker） 容灾备份层（S3+跨区域复制）
三、各层详细设计（无托管服务依赖）
（一）指标采集层：全维度数据采集，无死角覆盖
核心目标：轻量化、多源采集，适配AWS资源+自搭系统
技术选型（纯自部署）： - 资源指标采集：Node Exporter（系统级）、AWS CLI自定义脚本（AWS资源）、cAdvisor（容器级）； - 服务指标采集：Blackbox Exporter（端口/HTTP存活）、JMX Exporter（中间件）、自定义Exporter（数据库/应用）； - 采集器部署：所有采集器以Docker容器形式运行在EC2或K8s节点上，无托管采集服务依赖。
分场景采集方案：
| 监控对象 | 采集工具/方式 | 核心采集指标 |
|---|---|---|
| AWS EC2/EBS | Node Exporter + AWS CLI脚本（定时调用AWS API） | CPU使用率、内存使用率、磁盘IO、网络吞吐量、EBS读写延迟、实例状态（运行/停止/重启） |
| AWS VPC/安全组 | 自定义Shell脚本（定时校验路由表可达性、安全组规则有效性）+ Route53健康检查 | 子网可用IP数、路由表关联状态、安全组端口开放状态、VPC流量丢弃率 |
| AWS ELB/S3 | AWS CLI脚本（定时查询ELB健康状态、S3存储量/请求成功率） | ELB后端健康实例数、请求量、响应延迟、S3存储使用率、PUT/GET成功率 |
| 自搭K8s集群 | cAdvisor + Kube-state-metrics（自部署） | Pod/Node资源使用率、Pod重启次数、Deployment副本就绪率、Node就绪状态 |
| 中间件（Kafka/MySQL） | JMX Exporter（Kafka）+ 自定义SQL脚本（MySQL） | Kafka分区健康、Topic堆积量、MySQL连接数、查询延迟、主从同步延迟 |
| 应用服务 | 自定义Exporter（埋点暴露/日志解析） | 接口响应时间、错误率、QPS、线程池状态 |
- 采集优化： - 采集频率：核心指标（CPU/内存/存活状态）10秒/次，非核心指标（存储使用率/S3状态）60秒/次； - 轻量化：采集器容器限制CPU≤0.2vCPU、内存≤256MB，避免占用业务资源； - 容错：采集失败时本地缓存指标（保留5分钟），恢复后批量上报，避免数据丢失。
（二）传输转发层：高可靠、低延迟的指标流转
核心目标：削峰填谷、跨区域传输、避免指标丢失
技术选型：自搭建Kafka集群（替代托管消息服务）+ Kafka MirrorMaker（跨区域同步）；
部署架构： - 单区域内：3个AZ各部署1台EC2（i3.large，本地SSD）作为Kafka Broker，1台EC2作为ZooKeeper（3节点集群），Topic设置3副本（跨AZ）； - 跨区域同步：部署Kafka MirrorMaker 2.0，将各区域Kafka的指标Topic同步至其他区域，确保跨区域数据一致性； - Topic设计：按指标类型拆分，如
monitor/aws/ec2、monitor/system/k8s、monitor/middleware/kafka，每个Topic分区数=区域内Broker数；关键保障： - 可靠性：Kafka Topic数据保留期24小时，支持指标重放；启用ACK=all，确保数据写入所有副本后才算成功； - 削峰：应对指标采集峰值（如系统重启时批量上报），Kafka缓冲队列避免后端存储过载； - 加密传输：Kafka节点间通信启用TLS 1.3，采集器→Kafka传输通过SASL认证+TLS加密。
（三）存储分析层：时序数据存储+跨区域聚合
核心目标：高吞吐写入、低延迟查询、长期存储、全球数据聚合
技术选型：自搭建Prometheus集群（实时指标）+ Thanos（长期存储+跨区域聚合）+ S3（冷数据归档）；
部署架构： - 区域级Prometheus：3个核心区域（美东、欧西、亚太）各部署1套Prometheus高可用集群（2个Server节点+共享存储），通过Kafka Adapter消费Kafka指标并写入Prometheus；
- 存储配置：本地SSD存储热数据（近7天），写入吞吐量支持10万指标/秒；
- 高可用：2个Prometheus Server配置相同采集规则，数据通过Thanos Sidecar同步，避免单点故障；
- Thanos集群（跨区域聚合）：
- Thanos Query：每个区域部署1台EC2（m5.large），接收Grafana查询请求，聚合本区域+其他区域的Prometheus数据；
- Thanos Store Gateway：部署在S3访问优化区域，对接S3冷数据存储（7天前指标），支持历史数据查询；
- Thanos Compactor：定期压缩S3中的历史指标，降低存储成本；
- 长期存储：Prometheus热数据7天后通过Thanos Uploader迁移至S3，S3开启跨区域复制（同步至2个备用区域），数据保留90天（可配置）。
查询优化： - 指标分片：按区域+指标类型分片存储，查询时仅路由至目标分片； - 缓存策略：Thanos Query启用本地缓存（缓存热点查询结果5分钟），降低跨区域查询延迟； - 索引优化：Prometheus启用倒排索引，支持按资源ID（如EC2实例ID、K8s Pod名称）快速过滤指标。
（四）可视化告警层：全球统一视图+实时告警
核心目标：直观展示、快速告警、故障定位
技术选型：自搭建Grafana（可视化）+ Alertmanager（告警）+ 自定义告警路由服务；
部署架构： - Grafana集群：3个区域各部署1台EC2（t3.medium），通过NLB+Route53智能DNS实现全球就近访问；
- 数据来源：对接所有区域的Thanos Query，支持“全球总览-区域详情-资源明细”三级仪表盘；
- 权限控制：启用LDAP认证（自搭建OpenLDAP集群），按角色（管理员/运维/开发）划分资源访问权限；
- Alertmanager集群：每个区域部署1台EC2（t3.small），与Prometheus集群关联，支持告警分组、静默、抑制；
- 告警路由：自开发告警转发服务（部署在K8s），支持将告警推送至邮件、协同办公系统及工单系统，按故障级别（P0-P3）路由至不同负责人。
核心功能适配： - 可视化仪表盘：
- 全局总览：各区域AWS资源可用率、系统服务健康度、TOP5告警类型；
- 资源详情：EC2/ELB/S3的实时指标曲线（CPU/内存/流量）、异常指标标记；
- 故障排查：关联指标+日志（对接自搭建ELK集群），支持按时间范围回溯故障前后数据；
- 告警规则：
- P0（致命）：区域级服务崩溃（如Kafka集群不可用）、核心EC2实例离线>30秒；
- P1（严重）：资源使用率超阈值（CPU>90%持续5分钟）、数据库连接数超上限；
- P2（一般）：非核心服务响应延迟>1秒、S3存储使用率超80%；
- P3（提示）：资源配置即将到期、非核心指标波动。
（五）容灾与高可用层：故障无感知切换
核心目标：单区域故障时监控不中断、数据不丢失
区域级故障转移： - Route53健康检查：监控各区域Grafana、Thanos Query的可用性，当某区域故障时，自动将用户请求转发至就近正常区域； - 数据冗余：Kafka跨区域同步确保指标不依赖单区域，Prometheus热数据跨AZ存储，S3冷数据跨区域备份；
服务级故障自愈： - 采集器：部署在ASG中，EC2节点故障时自动重启采集器容器； - Kafka/Prometheus：通过自写监控脚本（部署在EC2）检测服务状态，故障时自动重启，重启失败则触发ASG扩容新节点； - 数据库（OpenLDAP/MySQL）：主从复制+Keepalived自动切换，故障切换时间<10秒。
四、核心监控场景落地
1. AWS基础资源健康监控
- EC2故障检测：Node Exporter采集实例状态，Prometheus规则判断“实例状态≠running”或“CPU使用率=0且内存使用率<10%”，触发P1告警；
- VPC网络异常：自定义脚本定时校验子网路由可达性，若连续3次失败，告警并推送路由表配置快照；
- S3可用性监控：AWS CLI脚本定时执行S3 Put/GET操作，请求成功率<99.99%或延迟>500ms，触发P2告警。
2. 自搭建系统运行监控
- K8s集群健康：Kube-state-metrics采集Pod重启次数，10分钟内重启>3次触发P1告警；Node就绪状态异常>1分钟，自动触发ASG扩容新节点；
- Kafka故障监控：JMX Exporter采集分区副本同步状态，若“ISR副本数<2”或“Topic堆积量>10万条”，触发P0/P1告警；
- 应用服务监控：自定义Exporter采集接口错误率，5分钟内错误率>1%触发P2告警，错误率>5%触发P1告警并自动调用应用重启接口。
3. 故障根因定位
- 指标关联：Grafana支持“资源指标+服务指标”联动查询（如EC2 CPU 100% → 关联K8s Pod资源使用率 → 定位过载Pod）；
- 日志联动：自搭建ELK集群（EC2部署）收集系统/应用日志，Grafana嵌入ELK查询入口，可通过资源ID/时间范围关联指标与日志，快速定位故障原因。
五、安全与合规设计
- 数据安全：
- 传输加密：所有链路（采集器→Kafka、Kafka→Prometheus、Grafana→Thanos）均启用TLS 1.3；
- 存储加密：EC2磁盘EBS加密、S3存储桶启用SSE-KMS加密、Prometheus/MySQL数据文件加密；
- 权限控制：基于IAM角色限制EC2访问AWS资源（如仅允许采集器EC2调用EC2/S3 API），Grafana/LDAP按角色隔离监控数据访问权限。
- 合规适配：
- 日志审计：所有监控操作（告警触发、权限变更、仪表盘修改）记录日志，存储至S3保留1年，符合GDPR/CCPA审计要求；
- 数据脱敏：监控指标中隐藏敏感信息（如EC2实例密码、数据库连接串），仅保留资源ID、指标数值等必要信息。
六、运维自动化设计（无托管运维服务）
- 基础设施编排：
- Terraform IaC：编写模块化代码，批量创建EC2、VPC、ELB、Route53等基础资源，以及Kafka、Prometheus、Grafana等自搭建组件的部署配置；
- 环境一致性：通过Terraform工作区区分dev/test/prod，状态文件存储在S3+DynamoDB锁，避免配置冲突。
- 服务自动化运维：
- 自写Shell/Python脚本：监控采集器、Kafka、Prometheus的运行状态，异常时自动重启服务，重启失败则触发ASG扩容；
- 配置自动同步：通过Git+Ansible同步所有监控组件的配置文件（如Prometheus规则、Grafana仪表盘），修改后自动下发至所有节点；
- 版本升级：采用蓝绿部署模式升级监控组件（如Grafana/Prometheus），确保升级过程中监控不中断。
七、核心指标保障
| 指标类型 | 目标值 | 实现手段 |
|---|---|---|
| 系统可用性 | 99.99%（年故障<53分钟） | 多区域+多AZ部署、自动故障转移、服务多副本 |
| 指标采集延迟 | <30秒 | 轻量化采集器、Kafka低延迟传输 |
| 告警触发延迟 | <30秒 | Prometheus实时规则评估、Alertmanager秒级转发 |
| 跨区域查询延迟 | <1秒 | Thanos就近聚合、缓存优化 |
| 数据存储期限 | 热数据7天、冷数据90天 | Prometheus+S3分层存储 |
总结
该架构完全基于AWS基础资源自搭建，无任何托管服务依赖，通过“全维度采集→高可靠传输→分层存储→全球聚合→实时告警”的闭环设计，实现AWS基础资源与自搭建数字系统的统一监控。多区域+多AZ部署保障99.99%可用性，跨区域数据同步与就近访问适配全球业务，轻量化采集与优化存储平衡性能与成本，完全满足“系统+云资源”的全球监控需求，同时适配外资企业的安全合规要求。