最近在帮一个团队梳理监控体系时刚好把 AWS 的 Prometheus 托管服务完整过了一遍从工作区创建到采集配置落地踩了几个不大不小的坑。顺手把这一整套操作记下来给同样在用 Amazon Managed Service for Prometheus以下简称 AMP做监控的同学一个参考。无论你是刚接触托管 Prometheus还是已经在用自建方案想迁到云上这篇文章都适合花几分钟看一遍里面每一步都有控制台实操记录和配置说明照着做就能跑通。1. 内容整体设计与思路拆解1.1 为什么需要“工作区”这个概念它到底解决了什么问题用过自建 Prometheus 的朋友应该都有体会一个 Prometheus 实例除了要管采集还要管存储、告警、数据留存随着规模上来磁盘、内存、高可用全都得自己操心。AMP 把这块抽象成了“工作区”Workspace可以把它理解成一个完全托管的 Prometheus 数据平面。你不用再关心后端存储长什么样也不用部署 Thanos 或 VictoriaMetrics 做长期存储AMP 天然把 Prometheus 的远程写入协议接了过来把指标数据落在托管存储里。工作区在这个体系里充当的是隔离单元每个工作区有独立的实例 ID、独立的写入端点Remote Write Endpoint、独立的查询端点Query Endpoint。团队 A 和团队 B 就算共用同一个 AWS 账号只要分属不同工作区数据彼此不可见权限上也能用 IAM 做独立管控。这跟 Kubernetes 里的 Namespace 思路很像——资源上做逻辑隔离安全上做权限边界。1.2 整个配置链路的基本盘控制台、工作区、采集配置三者的关系用 AMP 搭一套监控核心链路其实就三条数据怎么写进去、数据存在哪、数据怎么查出来。其中“数据存在哪”就是工作区“数据怎么写进去”靠的是采集端的 Remote Write 配置“数据怎么查出来”则是通过工作区里的查询端点对接 Grafana。这篇文章重点落在前两步。控制台负责创建和管理工作区相当于总入口工作区 ID 是后续所有操作的钥匙因为 AMP 的 API、AWS CLI 命令、采集器配置里都要用到它“提取/收集”里的配置说白了就是告诉采集器“你要把数据推到哪个地址用什么身份认证”这个配置能保存成 Prometheus 原生格式的 YAML也可以导出成 CloudFormation 模板或 Terraform 配置方便后面做基础设施即代码管理。1.3 方案选型的几条经验什么时候用托管什么时候自建如果你在犹豫是不是要把自建 Prometheus 迁到 AMP我个人建议按下面几个维度评估存储成本自建方案里存储是最头疼的Prometheus 本地的 TSDB 数据文件一旦膨胀运维量指数级上升。AMP 的存储按量计费数据留存时间灵活调整省去了卷容量规划。采集规模单机 Prometheus 在几百万时间序列时就开始吃力AMP 对写入吞吐做了水平扩展接入层压力小很多。查询性能Grafana 里跑大范围聚合查询时AMP 的查询引擎是分布式的比单机 Prometheus 快不少特别是长时间范围的 rate、histogram_quantile 这类重查询。定制化需求如果你的告警规则、SD 发现、远程写下游有大量定制自建 Prometheus 会更灵活。AMP 的告警规则是支持的但整体受托管平台限制不太适合做深度改造。就我自己的感觉中小团队从零起步、又不想投入太多运维精力的情况下AMP 这条路是性价比很高的选择。2. 核心细节解析与实操要点2.1 创建 AMP 工作区的前置条件IAM 权限、网络环境、区域选择创建 AMP 工作区虽然控制台点几下就完成但有几项前置条件没准备好后面往往要返工。第一是 IAM 权限。负责创建和控制台操作的 IAM 用户至少需要具备AmazonPrometheusFullAccess或等效的自定义策略。这个策略覆盖的权限包括aps:CreateWorkspace、aps:DescribeWorkspace、aps:UpdateWorkspace等。如果你的团队走的是最小权限原则可以只授这几个 Create/Describe/List 权限后续采集端写入用的是独立的 IAM Role跟控制台操作权限分开管理。第二是网络环境。AMP 的端点默认是公网可访问的但生产环境建议走 PrivateLink 或者 VPC Endpoint让采集器和查询端都在内网完成通信。如果你在控制台创建完工作区之后发现写入超时先别怀疑配置优先检查一下采集器所在的子网到 AMP VPC Endpoint 的路由表这个问题我后面会专门讲。第三是区域选择。AMP 服务目前在多个区域可用但不同区域的写入和查询端点域名不一样工作区一旦创建就不能跨区域迁移。我建议按照业务部署的区域就近创建优先选择离采集目标最近的区域能显著降低写入延迟和网络抖动。2.2 分步骤演示控制台创建工作区的完整流程登录 AWS 管理控制台在服务搜索框里输入“Prometheus”进入 Amazon Managed Service for Prometheus 的首页。左侧菜单选“工作区”Workspaces右侧会看到当前区域已有的工作区列表刚开通账号时这里是空的直接点右上角的“创建工作区”按钮。创建工作区的表单字段不算多按我的操作经验核心就三项工作区名称这个名称主要方便你在控制台里辨认建议按“业务-环境”的规则命名比如order-service-prod、eks-cluster-dev后续算账单、看监控一眼就能对应上。工作区别名Alias同样用于标识可以跟名称保持一致。标签Tags强烈建议在创建时就打上环境、Owner、成本中心这几个标签。AWS 的账单明细里会按标签聚合费用如果后面接入多个团队没有标签的成本分摊会非常痛苦。点“创建工作区”之后状态会从“创建中”变成“运行中”这个过程通常只需要几十秒。创建完成后列表里会出现一行记录包含工作区 ID、别名、创建时间等信息状态列显示为绿色。2.3 保存工作区配置的正确姿势控制台的文件下载与配置导出工作区创建成功之后列表里那一行就是你的“黄金配置入口”。点击工作区 ID 进入详情页页面里能看到工作区配置的几个关键区域状态、工作区 ID、端点信息、标签以及一个集中展示“提取/收集”和“查询”配置的区块。这里特别说一下配置的保存。在详情页中可以找到 Remote Write Endpoint远程写入端点和 Query Endpoint查询端点两个信息AMP 也支持直接把工作区配置导出成 CloudFormation 模板这样后续做基础设施即代码管理就非常方便。如果用的是 AWS CLI创建工作区的对应命令是aws amp create-workspace \ --alias order-service-prod \ --tags Environmentprod,Ownerplatform创建完返回的 JSON 里会有workspaceId字段后面所有操作都需要引用它。查看已有工作区可以用aws amp describe-workspace \ --workspace-id ws-xxxxxxxxxxxx这里workspaceId就是控制台里点击进入详情页时 URL 上那一串ws-开头的标识。我的习惯是创建完工作区之后先把 ID、写入端点、查询端点三个值单独存到一个本地笔记里后续配置 Grafana 数据源、配置采集器都要反复用到每次去控制台里翻效率太低。2.4 详细解读“提取/收集”配置里的每一项参数进入工作区详情页找到“提取/收集”这个区块AMP 会展示当前工作区的采集配置摘要。这里其实是采集器的接入信息核心就是 Remote Write Endpoint 和认证方式但这几个参数背后的逻辑值得仔细解释。Remote Write Endpoint 的格式一般是https://aps-workspaces.region.amazonaws.com/workspaces/workspace-id/api/v1/remote_write注意这个端点是 AMP 工作区的标准写入地址Prometheus、Grafana Agent、OpenTelemetry Collector 等采集器都能直接对接。你可能会好奇为什么路径里带api/v1/remote_write其实这就是 Prometheus 远程写入协议的标准路径AMP 完全兼容官方协议所以市面上的采集器基本即插即用。“提取/收集”配置里同时会显示对应的 IAM Role 或 Access Key 配置入口。AMP 的认证方式用的是 AWS SigV4 签名这是 AWS 服务统一的认证机制。意思是采集器在向 Remote Write Endpoint 发送数据时请求头里必须带上用 Access Key 或 IAM Role 生成的签名。AWS 官方提供了一个签名代理SigV4 Proxy或者配置采集器内置的 AWS 认证插件比如 Grafana Agent 和 Prometheus 的aws_sigv4配置段都是原生支持的。保存这些配置的时候最好以 YAML 格式完整保存下来。下图这份配置就是典型的 Prometheus 写入 AMP 的配置样例global: scrape_interval: 15s scrape_configs: - job_name: node-exporter static_configs: - targets: [localhost:9100] remote_write: - url: https://aps-workspaces.region.amazonaws.com/workspaces/workspace-id/api/v1/remote_write queue_config: max_samples_per_send: 1000 max_shards: 200 capacity: 2500 aws_sigv4: region: region service: aps access_key: ACCESS_KEY secret_key: SECRET_KEY上面这份配置里aws_sigv4段落就是 AMP 与其他 Prometheus 兼容后端最大的不同点。如果是自建 Prometheus 或者其他兼容服务一般只需要 URL 和 token 认证而 AMP 必须做 SigV4 签名少这一段会直接报 403 错误。2.5 配置从“临时使用”到“持久保存”的思路我在团队内部推 AMP 配置管理时制定了一条规则任何人通过控制台创建或修改了工作区配置必须在当天把它同步到代码仓库里。控制台里的点击操作虽然方便但它不具备审计和版本回溯能力一旦有人改了配置然后又改回去很难定位是谁在什么时间做的操作。具体做法是在代码仓库里建一个prometheus/amp-workspaces/目录每个工作区一个子目录里面放两个文件一个是workspace.json记录工作区 ID、别名、标签、区域信息另一个是remote-write.yaml是采集器端的完整配置。后续要用新的采集器接入时直接从这个目录里取配置而不是去控制台复制。3. 实操过程与核心环节实现3.1 完整实操场景从零创建一个生产级工作区并保存配置下面以一个实际的业务场景来描述整个过程。假设我们有一个跑在 EKS 上的订单服务现在要给它的 Pod 指标做长期监控决定用 AMP 承载存储和查询。第一步创建专用目录把后续要用的文件分类这是我的习惯也方便之后做脚本化处理mkdir -p ~/amp-demo/{cloudformation,scrape-config,iam}第二步在 AWS 控制台创建 AMP 工作区。进入 Amazon Managed Service for Prometheus 控制台点“创建工作区”名称填order-service-prod别名填order-service-prod标签打上Environmentprod、Ownerplatform、CostCenterorder。点击创建后等待状态变成“运行中”。第三步记录关键端点信息。在列表里找到刚创建的工作区点击工作区 ID 进入详情页复制以下内容到本地记录表中资源项示例值工作区 IDws-0123456789abcdef0Remote Write Endpointhttps://aps-workspaces.ap-northeast-1.amazonaws.com/workspaces/ws-0123456789abcdef0/api/v1/remote_writeQuery Endpointhttps://aps-workspaces.ap-northeast-1.amazonaws.com/workspaces/ws-0123456789abcdef0/api/v1/query第四步配置采集端。既然采集目标是 EKS 集群内的 Pod 指标这里可以直接用 Prometheus 官方 Helm Chart 或者 Grafana Agent。Helm 的values.yaml里最关键的一段配置如下serviceAccounts: server: name: amp-iamproxy-ingest server: remoteWrite: - url: https://aps-workspaces.ap-northeast-1.amazonaws.com/workspaces/ws-0123456789abcdef0/api/v1/remote_write queue_config: max_samples_per_send: 1000 max_shards: 200 capacity: 2500 sigv4: region: ap-northeast-1 service: aps这里注意sigv4这个配置段是 Prometheus 2.28 及以上版本原生支持的。如果在更老的版本里需要额外部署一个 sigv4 proxy 来做签名转发。用 Helm 部署时对应的 serviceAccount 注解需要关联一个有aps:RemoteWrite权限的 IAM Role。3.2 采集器配置的关键选择为什么推荐用 sigv4 原生支持而不是代理在 AMP 的采集方案里写入认证有两种常见实现方式一种是采集器原生支持 SigV4 签名比如新版本 Prometheus、Grafana Agent另一种是部署一个本地代理做签名转发。我强烈建议能用前者就用前者理由很简单少一个组件就少一个故障点。之前在一个项目里见过这样的架构Prometheus 先写入本地的 SigV4 代理代理再转发到 AMP看起来没什么问题但代理进程一旦重启或者 OOM采集链路中间就断开监控数据出现断档。而原生 SigV4 支持则是采集器直接跟 AMP 通信链路短、无中间态。排查问题的时候也省事直接在 Prometheus 日志里就能看到 AMP 返回的 HTTP 状态码。3.3 用 AWS CLI 验证工作区配置是否生效控制台操作完成后建议用 CLI 再做一次验证确认工作区真的可按预期访问。下面这几个命令我每次配置完都会跑一遍简单有效查看当前区域下的所有工作区aws amp list-workspaces --alias-prefix order-service获取指定工作区的详细信息包括端点和状态aws amp describe-workspace --workspace-id ws-0123456789abcdef0检查 IAM 权限能否正常访问工作区aws amp list-rules-management-namespaces \ --workspace-id ws-0123456789abcdef0第一次执行这些命令之前要先配置 AWS CLI 的凭证这个就不展开说了。重点提醒下如果用的是临时凭证注意AWS_SESSION_TOKEN也要一起配置很多权限报错都是漏了这个导致的。3.4 将配置保存到代码仓库的最佳实践配置验证通过后我把上面的工作区信息和采集配置整理成下面的目录结构提交到 Gitinfra/ └── amp/ ├── order-service-prod/ │ ├── workspace.json # 工作区基础信息 │ ├── remote-write.yaml # Scrape 与 Remote Write 配置 │ └── grafana-datasource.json # Grafana 数据源配置 └── README.md # 接入说明workspace.json的内容样例{ workspaceId: ws-0123456789abcdef0, alias: order-service-prod, region: ap-northeast-1, status: ACTIVE, tags: { Environment: prod, Owner: platform, CostCenter: order }, endpoints: { remoteWrite: https://aps-workspaces.ap-northeast-1.amazonaws.com/workspaces/ws-0123456789abcdef0/api/v1/remote_write, query: https://aps-workspaces.ap-northeast-1.amazonaws.com/workspaces/ws-0123456789abcdef0/api/v1/query } }grafana-datasource.json内容如下{ type: prometheus, url: https://aps-workspaces.ap-northeast-1.amazonaws.com/workspaces/ws-0123456789abcdef0, access: proxy, basicAuth: false, jsonData: { authType: sigv4, sigv4Auth: true, sigv4Region: ap-northeast-1, sigv4Service: aps }, secureJsonData: { sigv4AccessKey: YOUR_ACCESS_KEY, sigv4SecretKey: YOUR_SECRET_KEY } }这套文件提交后团队里任何人要接新的 Grafana 面板或新增采集任务直接取对应的 YAML 和 JSON 文件改一改就能用不用每个人都去控制台里找配置。3.5 采集数据验证流程如何确认数据真的进了工作区配置完成后验证数据是否真的写入 AMP这一步很多人都忽略掉直接去配 Grafana等发现面板没数据再回头排查效率很低。我的做法是先用查询 API 独立验证一遍再接入 Grafana。在 AWS CloudShell 或者本地终端执行aws amp query-metrics \ --workspace-id ws-0123456789abcdef0 \ --query up如果没有返回数据可以换个时间范围再查aws amp query-metrics \ --workspace-id ws-0123456789abcdef0 \ --query rate(demo_api_request_duration_seconds_count[5m]) \ --start-time $(date -d 30 minutes ago %s) \ --end-time $(date %s)此外控制台的工作区详情页里也有“指标”标签页可以看到当前工作区的接收字节数、时间序列数、写入请求数等核心指标。如果采集器运行正常这些数值应该是持续增长的。如果查询结果一无所获大概率是采集端根本没有成功写入需要回到采集器日志里排查后文问题速查表中会展开。4. 常见问题与排查技巧实录4.1 日志总是报 403签名认证失败怎么办这是初次接入 AMP 时遇到最多的错误。现象是 Prometheus 采集器或 Grafana Agent 日志里出现HTTP 403 Forbidden错误信息类似The request signature we calculated does not match the signature you provided。排查路径其实很明确检查采集器所在区域的 IAM 角色是否包含aps:RemoteWrite权限这是写入 AMP 的最低要求。检查 SigV4 配置里的region是否和工作区所在区域一致这是最容易忽略的坑。如果工作区在ap-northeast-1采集器配置的 region 却写成了us-east-1签名自然对不上。检查时钟同步。SigV4 签名对时间戳非常敏感容器或 EC2 实例的时钟偏移超过 5 分钟签名就会失效。用timedatectl status或date看看系统时间是否正确。检查临时凭证配置。如果你用的是 STS 临时凭证采集器的环境变量里要同时设置AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY和AWS_SESSION_TOKEN三个都齐全才能签名成功。4.2 写入端点能通但采集数据一直断档间隔还很长如果写入不报错但 Grafana 面板数据总是一段一段缺的我先怀疑队列参数配置不合理。AMP 的 Remote Write 接收链路对突发流量的承载能力很强但如果采集端的发送队列设置不合理可能会出现在高负载时数据来不及发送导致缓冲溢出。实测下来下面这组队列参数可以应对绝大多数场景queue_config: capacity: 10000 max_shards: 200 min_shards: 1 max_samples_per_send: 2000 batch_send_deadline: 10s min_backoff: 30ms max_backoff: 5s这里max_shards决定了并发写请求数量如果你的采集目标特别多几千个 Pod建议把max_shards调到 500 试试。capacity是每个分片队列能缓存的样本数量默认值 2500 在低频采集场景下够用但高基数场景建议提高到 10000。另外如果数据缺的不是几秒而是几分钟优先看采集器的抓取超时时间。默认scrape_timeout是 10s但有些 exporter 响应慢一旦超时就跳过本轮抓取Grafana 里呈现出来的就是周期性的空洞。4.3 控制台里无法进入工作区详情页一直转圈这个问题我遇到过两次一次是浏览器插件拦截了控制台的脚本请求另一次是 IAM 权限不足导致接口返回异常。先换一个浏览器建议用无痕模式试试排除插件干扰如果仍然不行打开浏览器开发者工具F12切到 Network 面板重新点击工作区 ID看看具体的接口返回状态码。如果返回 403 或 AccessDenied那就不是控制台的问题了需要检查当前登录用户的 IAM 权限补上aps:DescribeWorkspace和aps:ListWorkspaces权限即可。4.4 跨账号采集器的权限配置思路很多团队的 EKS 集群和 AMP 工作区不在同一个 AWS 账号里。跨账号场景下采集器的权限配置要分两步走在 AMP 工作区所在账号接收端创建一个 IAM Role允许源账号的某个 Role 来 Assume然后在源账号的采集器 ServiceAccount 上绑定该 Role。用 Terraform 来写的话接收端账号的关键资源如下resource aws_iam_role amp_ingest_role { name amp-ingest-role assume_role_policy jsonencode({ Version 2012-10-17 Statement [ { Effect Allow Principal { AWS arn:aws:iam::源账号ID:root } Action sts:AssumeRole } ] }) } resource aws_iam_role_policy amp_ingest_policy { name amp-ingest-policy role aws_iam_role.amp_ingest_role.id policy jsonencode({ Version 2012-10-17 Statement [ { Effect Allow Action [aps:RemoteWrite] Resource arn:aws:aps:ap-northeast-1:接收端账号ID:workspace/ws-0123456789abcdef0 } ] }) }写完terraform apply之后再把接收端账号创建的 Role ARN 填到采集器的serviceAccounts.server.annotations.eks.amazonaws.com/role-arn里就可以实现跨账号的权限打通了。4.5 常见问题速查表现象优先排查项具体处理方式写入返回 403SigV4 签名检查 region、时间同步、IAM 权限、临时凭证完整性写入返回 404Endpoint 地址检查 URL 路径是否包含完整的工作区 ID写入返回 413请求体过大调低max_samples_per_send增大batch_send_deadline有写入但查不到数据查询端点确认查询时用的是同一个工作区 ID数据断档队列参数调大capacity和max_shards观察系统资源Grafana 无数据数据源认证检查 Grafana 数据源是否启用了 SigV4 认证控制台页面异常浏览器/IAM无痕模式、检查角色权限5. 经验总结与后续扩展建议5.1 关于 AMP 控制台与自建 Prometheus 的一些真实体会AMP 工作区这套模式确实把 Prometheus 的运维门槛降下来不少尤其是在存储和高可用这块。以前自建 Thanos S3 存储光对象存储桶的生命周期规则、压缩策略、索引缓存就够折腾一阵。AMP 把这些全部封装好了你只需要关心采集配置和数据本身。但在实际使用中我也发现一些不太顺手的地方提前告诉大家免得踩坑。AMP 的查询性能在跨度特别大的时间范围比如查询 90 天的数据时第一次查询会比较慢因为需要扫描大量历史分片建议在 Grafana 里设置好常用的时间范围避免超大范围查询。还有就是告警规则的配置方式跟原生 Prometheus 不同AMP 的告警规则是通过规则组Rule Groups管理的在控制台里创建时要注意命名空间和规则的格式校验不符合规范的话规则不会生效。5.2 可以怎么进一步把这套配置用起来如果你已经成功创建了工作区并保存了配置接下来可以做几件事让这套监控体系更完善把采集配置做成 Helm Chart 或 Terraform 模块放进自己的平台工程仓库里。后续新业务要接监控直接复用模块填上工作区 ID 和区域参数即可不用再手动改 YAML。接入 Grafana 时可以把数据源配置通过 Grafana Provisioning 方式管理这样 Grafana 实例重建后配置自动恢复不用再手动添加数据源。为工作区配置告警规则组。AMP 支持在控制台或通过 API 管理告警规则虽然目前告警通知还要依赖 Amazon SNS 或第三方工具但规则本身可以跟指标存储放在一起管理起来还算方便。5.3 一个值得养成的操作习惯最后说一个我自己的小习惯。每次在 AMP 控制台里操作完我都会顺手截一张图把操作前后的配置贴到当天的运维记录里。这样做不是为了形式主义而是等到月底复盘成本或者排查数据问题时有一份清晰的操作时间线会省很多事。AWS 控制台的审计日志虽然有 CloudTrail但 CloudTrail 记录的是 API 调用层面的操作不包含你在页面里填写的配置内容。靠控制台的“记忆”和 CloudTrail 的“时间线”结合起来才能还原一次完整的变更过程。这个习惯我坚持了两年在好几次排障中帮了大忙也推荐给所有把监控建在云上的团队。如果你也正在把监控体系迁到 AMP或者过程中碰到了什么奇怪的问题欢迎照着上面的步骤和排查表过一遍。多数问题集中在认证和网络两个环节耐心点一个个试总能调通。
