企业官网建设流程全解析

最近在帮一个团队梳理监控体系时，刚好把 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 Environment=prod,Owner=platform

创建完返回的 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，标签打上Environment=prod、Owner=platform、CostCenter=order。点击创建后，等待状态变成“运行中”。

第三步，记录关键端点信息。在列表里找到刚创建的工作区，点击工作区 ID 进入详情页，复制以下内容到本地记录表中：

第四步，配置采集端。既然采集目标是 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 将配置保存到代码仓库的最佳实践

配置验证通过后，我把上面的工作区信息和采集配置整理成下面的目录结构，提交到 Git：

infra/ └── 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。

排查路径其实很明确：

1. 检查采集器所在区域的 IAM 角色是否包含aps:RemoteWrite权限，这是写入 AMP 的最低要求。
2. 检查 SigV4 配置里的region是否和工作区所在区域一致，这是最容易忽略的坑。如果工作区在ap-northeast-1，采集器配置的 region 却写成了us-east-1，签名自然对不上。
3. 检查时钟同步。SigV4 签名对时间戳非常敏感，容器或 EC2 实例的时钟偏移超过 5 分钟，签名就会失效。用timedatectl status或date看看系统时间是否正确。
4. 检查临时凭证配置。如果你用的是 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 常见问题速查表

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，或者过程中碰到了什么奇怪的问题，欢迎照着上面的步骤和排查表过一遍。多数问题集中在认证和网络两个环节，耐心点，一个个试，总能调通。