AWS Prometheus工作区配置与remote write接入实战

最近在帮团队整理监控体系Prometheus 这块最终定下来用 AWS 托管的Amazon Managed Service for PrometheusAMP。整个接入过程走下来我最大的感受是真正决定迁移顺不顺利的不是采集规则怎么写而是对“工作区Workspace”这套配置模型的理解够不够深。工作区是 AMP 里最核心的逻辑隔离单元相当于一个独立运行的 Prometheus 实例空间。每次你在控制台或者内部平台比如我们团队封装的 heus 控制台里创建一个工作区平台会返回一个唯一的工作区 ID后面采集端、查询端、告警端全都要靠这个 ID 去定位和连接。这篇文章我会从创建 workspace 开始完整拆解如何把控制台里“提取/收集”出来的配置固化成本地可复用的 prometheus.yml并讲清楚 remote write 接入、权限配置、网络规划以及我在实际部署中踩过的坑。适合正在做 Prometheus 迁移、准备接入 AWS 托管监控的同学参考。1. 项目概述理解 AWS Prometheus 工作区与整体采集链路1.1 为什么选择 Amazon Managed Service for Prometheus自建 Prometheus 大家都不陌生部署一个二进制、配置好 scrape 任务、再加一套持久化存储看起来简单但一旦指标量上来问题就接踵而至。存储膨胀、分片扩容、高可用方案、长期数据保留、告警组件的高可用每一样都能耗掉大量时间。尤其是当集群规模到了几百个节点、上万条时间序列以后Prometheus 单机的内存和磁盘开销会非常感人你需要不停做联邦、做分片、甚至引入 Thanos 这类方案。AMP 解决的就是这一层运维负担。它把 Prometheus 的接收、存储、查询能力全都托管掉了你不需要关心底层实例规格、不需要担心存储扩容、也不需要维护 Thanos Sidecar 之类的组件。对外暴露的接口和原生 Prometheus 高度兼容采集端照常使用 remote write 写入查询端用 PromQL 去查Grafana 一个数据源配置就能接入迁移成本低到令人意外。当然托管服务不是免费的AMP 的成本模型按写入的采样点数量和存储时间计费指标量大的团队需要做一下成本预估这个后面会讲到。1.2 工作区Workspace在采集链路中的位置AMP 里工作区是一个逻辑隔离边界。每个工作区有独立的 ID、独立的写入端点、独立的查询端点互不干扰。你可以把工作区理解成一个“独立的 Prometheus 实例空间”生产环境建一个、测试环境建一个甚至按业务线拆多个数据层面完全隔离。采集链路里工作区处于中游位置。用一张业务上的流程来说就是这样采集端Prometheus Server、Grafana Agent 或 ADOT Collector 通过 scrape 抓取各类 exporter 暴露的指标写入端采集端通过 remote write 协议把指标序列化后推送到工作区的 ingestion endpoint存储查询端AMP 完成数据落盘、索引和查询计划通过 query endpoint 对外提供 PromQL 查询消费端Grafana、告警规则、第三方分析平台从 query endpoint 读取数据做可视化或告警。这里有个特别容易忽略的细节工作区 ID 不只是个标识符它直接参与 URL 的拼接。你在控制台创建好工作区之后点击工作区 ID 进入详情页能看到一串完整的端点地址形如https://aps-workspaces.us-east-1.amazonaws.com/workspaces/ws-xxxxxxxxxxxx/api/v1/remote_write这里的ws-xxxxxxxxxxxx就是工作区 ID。配置采集端时你的 remote write URL、Grafana 数据源 URL、告警端点 URL 全部基于这个 ID 衍伸出来。1.3 一条完整的配置流转路径我一开始接触 AMP 的时候最容易犯的毛病就是在控制台里点完了事没有把配置及时保存下来。回到公司内部的管理平台我们那套 heus 控制台里操作时发现如果不在一开始就把“提取/收集”到的配置落盘后面任何一次重新创建或者换环境都得重新翻控制台。所以这次我把完整路径理成了一条固定流程在 heus 控制台或 AWS Console 创建 Prometheus 工作区等待工作区状态变成 ACTIVE点击工作区 ID 进入详情页提取详情页里展示的 Remote Write Endpoint、Query Endpoint、AlertManager Endpoint将这些配置写入本地 prometheus.yml 的 remote_write 块将 workspace ID、endpoint、alias 等元数据记录到配置仓库实现可复用。这个流程就是你标题里提到的“创建工作区、保存工作区配置、点击工作区 ID 进详情、把提取/收集中的配置保存为 prometheus.yml”的标准落地方式。下面我把每一步展开讲。2. 前置准备账号权限、CLI 工具与网络规划2.1 IAM 权限与角色设计操作 AMP 工作区权限模型要先想清楚。我自己习惯把权限拆成三类管理权限创建、删除、修改工作区通常只给监控平台管理员写入权限远程写入指标给采集端使用的角色查询权限读取指标数据给 Grafana、开发排查问题用的角色。对应到 AWS 托管策略最常用的几个是策略名称作用AmazonPrometheusFullAccess工作区的创建、删除、修改等全部管理权限AmazonPrometheusRemoteWriteAccess允许向工作区写入指标数据AmazonPrometheusQueryAccess允许查询工作区中的指标数据AmazonPrometheusAlertManagerAccess允许访问 AlertManager 端点实际落地时我给采集端的 EC2 或 EKS 节点挂的角色只绑定 RemoteWriteAccess给 Grafana 服务绑定的角色只绑定 QueryAccess。这样即便某个角色的密钥泄露攻击者最多只能写指标或者查指标没办法删掉整个工作区。这里要特别提醒如果你在 EKS 环境里用 AMP强烈建议为采集 Pod 单独建一个 ServiceAccount并通过 IRSAIAM Roles for Service Accounts映射到最小权限的 IAM Role。不要在节点角色上直接挂 FullAccess一旦节点被攻破整个工作区的管理权就丢了。2.2 CLI 工具安装与身份配置不管是调试还是自动化awscli 都是绕不开的工具。安装步骤很简单macOS 上用 brewLinux 上直接下二进制包即可。装完之后先配置身份aws configure --profile amp-admin AWS Access Key ID [None]: AKIA... AWS Secret Access Key [None]: ... Default region name [None]: us-east-1 Default output format [None]: json我习惯把 AMP 相关的操作单独放到一个 profile 里避免和其他账号的凭据混在一起。另外命令里每次带--region参数别指望 endpoint 和 region 自动匹配。AMP 的 endpoint 是 regional 的比如你在 us-east-1 创建工作区查询和写入的域名前缀就是aps-workspaces.us-east-1.amazonaws.com这个在错误排查时非常关键。2.3 网络访问方式公网 Endpoint 与 VPC EndpointAMP 的工作区端点默认是公网可达的。如果你的采集端在 AWS 外部的机房或者自建 IDC直接用公网 endpoint 是可以的但要注意在 IAM 里限制来源 IP并开启 TLS。如果采集端跑在 AWS VPC 内部建议使用 VPC EndpointAWS PrivateLink来访问 AMP不走公网。好处很明显流量不经过公网、网络路径更稳定、还可以配合安全组做更细粒度的网络控制。创建 VPC Endpoint 时选择服务com.amazonaws.region.aps-workspaces然后关联到需要的子网和安全组。这里有个坑创建了 VPC Endpoint 之后AMP 工作区的 endpoint URL 并不会变化还是那个公网域名。VPC Endpoint 只是在 DNS 解析层面把该域名解析到私有 IP。所以你的采集端配置不需要改 URL只要网络能解析到内部地址就行。如果发现配置正确但连接超时先查一下 VPC 的 DNS 解析是否正确而不是急着改采集端配置。2.4 采集端组件选型采集端负责抓取指标并推送到 AMP选型上我实践下来有三类原生 Prometheus Server直接用现成的 Prometheus配置 remote write 指向 AMP。优点是对已有部署零改造缺点是还要维护一套 Prometheus。适合本来就有 Prometheus只是想引入托管存储的场景。Grafana AgentGrafana 官方出的轻量采集器内存占用远小于 Prometheus支持通过配置文件声明 remote write。适合从零搭建、不想维护完整 Prometheus 的场景。ADOT CollectorAWS Distro for OpenTelemetry CollectorAWS 维护的 OTel Collector 发行版内置了 AWS 相关的认证和 exporter 插件云原生集成最顺滑尤其适合 EKS。从运维角度如果你在 EKS 上跑我个人更推荐 ADOT Collector 或者 Grafana Agent因为它们的 remote write 认证配置对 AWS 场景做了原生优化省去手动做 SigV4 签名的麻烦。如果只是临时验证或小规模场景原生 Prometheus 加一个 sigv4 代理也行但没必要。3. 实操创建 AWS Prometheus 工作区并保存配置3.1 控制台方式创建工作区登录 AWS 管理控制台搜索进入 Amazon Managed Service for Prometheus点页面里的 “Create workspace” 按钮。需要填的项不多Alias给工作区起个容易识别的名字比如production-monitoringTags按公司的标签规范打上 Environment、Team、CostCenter 等标签Permissions选择工作区权限模式一般是“由调用方通过 IAM 控制”选默认即可。填完点创建等几秒钟工作区状态会从 CREATING 变成 ACTIVE。这个过程中后台会自动分配一个 workspace ID格式是ws-开头的一串随机 ID。提示Alias 只是给人看的真正标识工作区的是 workspace ID。后面所有的 API 调用、URL 拼接都是基于 ID不基于 alias。所以 alias 可以随便改ID 是铁打的。3.2 CLI 方式创建工作区如果你是自动化部署肯定不想每次都在网页上点。用 CLI 创建更干净aws amp create-workspace \ --alias production-monitoring \ --region us-east-1 \ --tags EnvironmentProduction,TeamPlatform命令执行完会返回一段 JSON核心字段如下{ arn: arn:aws:aps:us-east-1:123456789012:workspace/ws-abcdef123456, status: { statusCode: CREATING }, tags: { Environment: Production }, workspaceId: ws-abcdef123456 }注意这里返回的 status 是 CREATING表示还在创建中。你需要轮询describe-workspace直到状态变为 ACTIVE 再继续后续配置aws amp describe-workspace \ --workspace-id ws-abcdef123456 \ --region us-east-1我习惯在创建命令后面接一个wait逻辑或者直接在脚本里写个循环判断别一拿到 workspaceId 就立刻配置采集端那样大概率会碰上连接被拒的错误。3.3 点击工作区 ID 进入详情提取关键配置项工作区创建完成后回到工作区列表页面能看到每个工作区的Workspace ID。点击这个 ID 进入详情页这里才是整个流程里最值得你停下来截图保存的地方。详情页里会展示一整套端点信息我逐条说明它们是什么Remote Write Endpoint采集端 remote write 的目标地址。格式为https://aps-workspaces.us-east-1.amazonaws.com/workspaces/ws-abcdef123456/api/v1/remote_write。写入指标全靠这个 URL。Query EndpointPromQL 查询接口地址格式为https://aps-workspaces.us-east-1.amazonaws.com/workspaces/ws-abcdef123456/api/v1/queryGrafana 数据源填这个curl 排查也用它。AlertManager Endpoint托管 AlertManager 的接口配置告警通知时使用。Grafana 数据源配置如果使用 Amazon Managed Grafana控制台会直接给出对应的数据源模板。我的习惯是点开详情页之后立刻把 Remote Write Endpoint 和 Query Endpoint 复制到一个本地临时文件里用于下一步生成 prometheus.yml。千万别觉得记住了这类 endpoint 一旦拼错一个字符排查起来极其痛苦。3.4 把提取/收集的配置保存为 prometheus.yml拿到 endpoint 之后接下来就是把“提取/收集”到的配置固化到采集端。以原生 Prometheus 为例你需要在 prometheus.yml 里追加 remote_write 块global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: node-exporter static_configs: - targets: [localhost:9100] remote_write: - url: https://aps-workspaces.us-east-1.amazonaws.com/workspaces/ws-abcdef123456/api/v1/remote_write queue_config: max_samples_per_send: 1000 batch_send_deadline: 5s min_backoff: 30ms max_backoff: 5s sigv4: region: us-east-1 access_key: ${AWS_ACCESS_KEY_ID} secret_key: ${AWS_SECRET_ACCESS_KEY}重点说几个字段url就是详情页复制的 Remote Write Endpointsigv4AMP 的认证走 AWS Signature V4所以在 remote_write 块内部声明一个 sigv4 子配置块指定 region 和密钥。如果你跑在 EC2/EKS 上且角色有权限可以只写 region让 SDK 从 instance metadata 或 IRSA 自动拿临时凭证queue_config这个容易被忽略但影响很大。采集端写入 AMP 是异步批量上传队列参数决定吞吐和容错。默认值对中小规模指标集已经够用如果指标量大可以调大max_samples_per_send减少请求次数。这里有一个决策点密钥是硬编码还是动态获取。我强烈不建议把 AccessKey 直接写死在 YAML 里。哪怕是测试环境也尽量通过环境变量注入或者直接把 sigv4 块里的 access_key/secret_key 去掉完全依赖实例角色。后面 4.2 会讲 EKS 的 IRSA 方式那才是生产环境应该用的方案。3.5 用 Terraform 将工作区配置代码化如果你所在团队已经有 IaC 流程强烈建议把工作区直接纳入 Terraform 管理避免有人手动在控制台上建完就没人知道是谁建的、什么时候建的。一个最小化的 Terraform 配置长这样resource aws_prometheus_workspace monitoring { alias production-monitoring tags { Environment Production Team Platform } } output workspace_id { value aws_prometheus_workspace.monitoring.id } output remote_write_endpoint { value https://aps-workspaces.us-east-1.amazonaws.com/workspaces/${aws_prometheus_workspace.monitoring.id}/api/v1/remote_write }这个方案最大的好处是workspace 的生命周期、权限、端点输出全部代码化。任何一个新环境需要监控时直接terraform apply就能拉起一套不用再翻控制台复制粘贴。后续如果要做多账号、多区域的部署也只需要在 Terraform 里循环即可。4. 采集端接入配置remote write 上传与验证4.1 remote write 配置详解如果你用的是原生 Prometheus除了写 url 和 sigv4还需要注意 Prometheus 版本。remote write 的 sigv4 认证在 Prometheus 2.26 版本之后内置支持低于这个版本你需要用prometheus-sigv4-proxy之类的外部组件去做签名转发费时费力。建议直接用新版本。再展开讲一下 SigV4 认证。AWS 的 API 请求都需要对请求头做签名签名时需要 AccessKey、SecretKey、Region、Service Name。AMP 在这个环节里的 Service Name 固定是aps。如果你手工用 curl 去写请求测试很容易在签名环节翻车比如忘了加X-Amz-Date、region 传错、或者时钟偏差超过阈值。这也是为什么我强烈建议使用官方采集器或者 SDK 而不是手工拼请求。在 Grafana Agent 里remote write 配置更简洁metrics: wal_directory: /var/lib/agent/data global: scrape_interval: 15s configs: - name: amp remote_write: - url: https://aps-workspaces.us-east-1.amazonaws.com/workspaces/ws-abcdef123456/api/v1/remote_write sigv4: region: us-east-1 scrape_configs: - job_name: node static_configs: - targets: [localhost:9100]Grafana Agent 的优势是内存占用小、配置结构清晰对 K3s、边缘节点很友好。4.2 EKS 场景下的 IRSA 配置在 EKS 里跑采集器正确姿势是给 Pod 绑定一个 IAM Role而不是把 AK/SK 塞进 Deployment。这个机制叫 IRSA配置分几步首先确认集群已经关联了 OIDC Providereksctl utils associate-iam-oidc-provider \ --cluster my-cluster \ --approve然后创建 IAM Policy允许写入 AMPaws iam create-policy \ --policy-name AMPRemoteWritePolicy \ --policy-document { Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ aps:RemoteWrite ], Resource: arn:aws:aps:us-east-1:123456789012:workspace/ws-abcdef123456 } ] }再创建 ServiceAccount 并绑定角色eksctl create iamserviceaccount \ --cluster my-cluster \ --namespace monitoring \ --name amp-collector \ --attach-policy-arn arn:aws:iam::123456789012:policy/AMPRemoteWritePolicy \ --approve最后在 Deployment 的 spec 里指定serviceAccountName: amp-collector。这样 Pod 里的 SDK 会自动通过服务账户令牌向 STS 换取临时凭证remote_write 配置里不需要写任何密钥。这个方案的好处不只是安全临时凭证还有效期自动轮转彻底告别密钥过期导致采集中断的问题。注意IRSA 的信任策略需要允许 ServiceAccount 对应的 OIDC 身份代入 Roleeksctl 的 create iamserviceaccount 会自动处理这一层但如果使用手写 CloudFormation 或 Terraform一定要检查 AssumeRolePolicyDocument 里的 Condition 是否指定了正确的sts:AssumeRoleWithWebIdentity和aud字段。4.3 验证数据是否真的写入配置写完启动采集器之后第一件事不是去 Grafana 画图而是先做两个检查。第一看采集端的 remote write 状态。Prometheus 的 Web UI 在 Status → Remote Write 页面会列出每个 remote write target 的状态healthy 就说明连接、认证没问题报错信息也会显示在这里比如 403、401、timeout 等。第二直接用 curl 验证查询端点。AMP 的 query API 和原生 Prometheus 兼容传一个 PromQL 进去看有没有数据返回curl -X POST \ -H X-Amz-Target: Query \ -H Content-Type: application/x-amz-json-1.1 \ -d {query:up} \ https://aps-workspaces.us-east-1.amazonaws.com/workspaces/ws-abcdef123456/api/v1/query不过这个 curl 请求也需要 SigV4 签名手工敲很容易出错。我一般直接用 AWS 的aws amp query-workspace命令不需要自己管签名aws amp query-workspace \ --workspace-id ws-abcdef123456 \ --query up \ --region us-east-1返回的 JSON 里有data.result如果数组不为空就说明采集链路已经通了。到这一步AMP 工作区的创建、配置保存和写入验证才算完整闭环。5. 常见问题与排查技巧实录5.1 认证与权限类问题403 SignatureDoesNotMatch——这是最常见的一个错误。排查优先级先检查服务器时间是否准确签名对时间戳极度敏感偏差超过 5 分钟直接拒绝再检查 region 是否填对创建工作区的 region 和配置里 sigv4 的 region 不一致必然签名失败最后检查 AccessKey/SecretKey 是否当前有效的密钥很多人配了旧密钥在环境变量里排查半天才发现是缓存。AccessDenied 或 Unauthorized——说明请求到了 AMP但 IAM 权限不够。用 CLI 的话可以临时跑一条命令看具体缺少哪个 Actionaws sts decode-authorization-message --encoded-message error-message执行后返回的 JSON 里会明确告诉你缺的是aps:RemoteWrite还是aps:QueryMetrics照着 Policy 补就行。这个问题绝大多数出在 Policy 的 Resource 写得太窄比如把 workspace ID 写错了或者没加通配符又写了多工作区。5.2 网络与连接类问题连接超时或 Connection timed out——先检查采集端所在的 VPC 有没有到 AMP 的路由。如果配置了 VPC Endpoint用nslookup查一下域名解析出的 IP 是否落在 VPC CIDR 里。没有的话检查安全组出站规则端口是 HTTPS 443以及 Endpoint 关联的子网是否正确。还有一个容易栽的点VPC Endpoint 的 Policy。默认是允许所有主体和所有操作的但如果你写了自己的 Policy一定要包含aps:RemoteWrite和aps:QueryMetrics这两个 action否则会出现网络通、API 调用却被拒绝的诡异现象。TLS 握手失败或证书校验失败——一些企业自建采集环境里会有自定义 CA 或代理采集器做 TLS 校验时没法信任 AWS 的证书链。这种情况在 agent 里添加tls_config的insecure_skip_verify可以临时绕过但生产环境不要这么干正确做法是把根证书加到系统的 CA bundle 里。5.3 数据写入异常类问题remote write 返回 429 Too Many Requests——AMP 对不同工作区有写入速率限制一旦超过配额就会限流。排查时优先看采集端 queue 的samples-per-second和max_samples_per_send参数适当调低并发、拉开 batch 大小。如果长期接近配额考虑拆分指标到多个工作区或者降采样一些低频指标。out of order samples 或 duplicate samples——出现这个通常是因为多个采集端实例向同一个工作区写入相同序列而且时间戳乱序。AMP 要求每个序列的时间戳必须递增。这里要检查你是不是不小心部署了两套采集器或者 Prometheus 的external_labels没有配置区分不同集群。加一个全局的external_labels用集群名和实例名做区分能规避大部分冲突。global: external_labels: cluster: production-us-east-1 replica: 05.4 工作区管理中的几个容易踩的坑数据保留周期设置。AMP 默认保留 150 天对多数监控场景够用了但如果需要更长周期的趋势分析要提前规划是否需要额外的归档方案不能说删就删。成本控制。AMP 的计费跟写入的指标数量强相关。很多团队的指标数量爆炸式增长一是因为默认的 scrape 任务把大量 Pod 级别的指标都采了进来二是honor_labels没配对导致标签基数膨胀。实际项目里建议对采集任务做一轮指标裁剪只保留对告警和排查真正有用的指标成本能降下来一大截。工作区删除要谨慎。删除操作会直接销毁所有指标数据不可恢复。控制台里没有回收站Terraform 里如果误执行 destroy 也是同样的效果。我在生产环境的 Terraform 配置里加了prevent_destroy true阻止误删这个细节建议你们也加入。跨账号访问的问题。很多公司监控账号和业务账号是分开的。业务账号里的采集端要写入监控账号的工作区需要在监控账号里创建一个 Role业务账号的 Role 通过 AssumeRole 切换到该角色再写入。这个配置涉及两层信任关系比较容易踩坑建议先用aws sts assume-role手动验证一遍再落地采集端。最后一个小建议前面这些内容基本覆盖了从创建 AWS Prometheus 工作区到配置保存、采集接入、问题排查的完整链路。我个人在多次踩坑之后养成了一个习惯不管用控制台还是 heus 这类内部平台创建完工作区第一时间把 workspace ID 和 endpoint 写成一份 markdown 放到团队知识库里同时把 prometheus.yml 提交到 Git。因为这类配置看起来简单但一旦过了两三周没人动它再回来接新环境时谁也想不起来当时端点是从哪拿的、凭据挂在哪个角色上。把这些固化成代码和文档才是让整套监控平台可持续运维的关键。另外如果你刚开始用 AMP建议先只接一个低频指标的采集任务比如 node exporter跑一两天验证稳定性和成本账单再逐步扩容。不要一上来就把全部指标推过去否则遇到限流、标签冲突、成本超预算等问题时排查范围会非常大。