将 Cloudprober 指标接入 AWS CloudWatch 与 Google Cloud Monitoring【免费下载链接】cloudproberAn active monitoring software to detect failures before your customers do.项目地址: https://gitcode.com/gh_mirrors/clo/cloudproberCloudprober 是一款开源的主动监控active monitoring工具能在真实用户发现问题之前主动探测你的网站、API 与内部服务提前发现故障。而它最强大的能力之一就是通过内置的surfacer指标导出器机制把采集到的监控指标一键导出到AWS CloudWatch与Google Cloud Monitoring原 Stackdriver等主流监控平台。本文将用最简单的方式带你完成 Cloudprober 指标接入两大云监控平台的全过程。什么是 Cloudprober 的 Surfacer指标导出机制Cloudprober 的核心优势在于一套探测、多处输出它支持 Prometheus、OpenTelemetry、AWS CloudWatch、Google Cloud Monitoring、Google Pub/Sub、Postgres 等十余种输出方式而且可以同时启用多个互不干扰。这个负责导出的内置机制就叫 surfacer你只需在配置文件中添加一段surfacer配置块即可把指标实时推送过去。整体架构可参考上方的 Cloudprober 架构图左侧是各类主动探测目标右侧则是 Dashboards、SLOs、告警等下游消费方。如果你不配置任何 surfacerCloudprober 会默认启用 Prometheus 与文件两种导出方式方便本地调试。一、把 Cloudprober 指标接入 AWS CloudWatch1. 快速配置步骤在 Cloudprober 配置文件中加入以下内容即可启用 CloudWatch 导出surfacer { type: CLOUDWATCH }就这么简单默认情况下指标会发布到名为cloudprober的 CloudWatch 命名空间namespace下指标维度Dimensions会自动携带探针名称、目标地址、协议类型等标签方便你在 CloudWatch 控制台按维度筛选。相关实现可参考源码模块 internal/surfacers/cloudwatch/cloudwatch.go。2. AWS 认证与 IAM 权限配置CloudWatch surfacer 基于 AWS Go SDK支持默认凭证链按以下顺序自动寻找凭证环境变量共享凭证文件~/.aws/credentialsECS 任务 IAM 角色EC2 实例 IAM 角色。为了让 Cloudprober 有权限写入指标你需要为对应角色配置如下 IAM 策略注意命名空间要与下方配置一致{ Version: 2012-10-17, Statement: [ { Condition: { StringEqualsIgnoreCase: { cloudwatch:namespace: cloudprober } }, Action: [cloudwatch:PutMetricData], Resource: [*], Effect: Allow, Sid: PutMetrics } ] }3. 指定 AWS 区域Cloudprober 确定写入区域的优先级为配置中的 region 字段 → EC2 元数据 →AWS_REGION环境变量 →AWS_DEFAULT_REGION环境变量。推荐直接在配置里写死避免歧义surfacer { type: CLOUDWATCH cloudwatch_surfacer { namespace: /cloudprober/website/probes region: us-east-1 resolution: 60 } }4. 更细粒度的 CloudWatch 配置项CloudWatch surfacer 的完整配置项定义在 internal/surfacers/cloudwatch/proto/config.proto 中常用参数如下配置项默认值说明namespacecloudproberCloudWatch 指标命名空间resolution60指标存储分辨率秒低于 60 会产生高分辨率计费region自动检测目标 AWS 区域metrics_batch_size1000单次批量写入的指标数上限API 上限 1000batch_timer_sec30缓冲区最长保留时间满批或超时即写入5. 用 CloudWatch Metric Maths 计算差值Cloudprober 导出的指标是累积值counter而 CloudWatch 大多展示快照值。要还原每个时间段的增量可以借助 CloudWatch Metric Maths 的RATE与PERIOD函数RATE(m1) * PERIOD(m1)其中m1是 Cloudprober 指标的数学表达式 ID例如namespace: cloudprober、metric name: latency、probe: 探针名。这样你就能在 CloudWatch 上得到与 Prometheusrate()等价的增量曲线。二、把 Cloudprober 指标接入 Google Cloud Monitoring1. 快速配置步骤Google Cloud Monitoring前身 Stackdriver的接入同样简单只需一行配置surfacer { type: STACKDRIVER }如果你运行在 GCP 上VM 或 GKE Pod 具备 Cloud Monitoring 写入权限这一句配置即可直接生效否则需要额外指定 GCP 项目并配置Google Application Default Credentials应用默认凭证。2. 指标命名与监控前缀默认情况下指标会以custom.googleapis.com/cloudprober/探针类型/探针名为前缀导出。例如名为google_com的 HTTP 探针会生成custom.googleapis.com/cloudprober/http/google_com/total custom.googleapis.com/cloudprober/http/google_com/success custom.googleapis.com/cloudprober/http/google_com/latency你还可以通过monitoring_url自定义前缀或用metrics_prefix调整层级NONE/PROBE/PTYPE_PROBE。完整参数见 internal/surfacers/stackdriver/proto/config.proto示例配置可参考 examples/surfacers/stackdriver_surfacer.cfg。3. 用 MQL 计算失败率与平均延迟由于导出的都是计数类指标直接看图意义不大。Google Cloud Monitoring 提供了强大的MQLMonitoring Query Language可以轻松算出更有价值的指标。比如计算失败率fetch global || { metric custom.googleapis.com/cloudprober/http/google_com/failure ; metric custom.googleapis.com/cloudprober/http/google_com/total } || align delta(1m) || join || div计算某个探针的平均延迟fetch global || { metric custom.googleapis.com/cloudprober/http/google_com/latency ; metric custom.googleapis.com/cloudprober/http/google_com/success } || align delta(1m) || join || div以上查询既可用于 Metrics Explorer 绘图也能直接用来创建告警规则。三、同时接入多个监控系统Surfacer 的另一个亮点是可以同时配置多个。例如下面的配置同时启用了 Prometheus 与 Google Cloud Monitoring且只把特定探针的指标导出到云平台surfacer { type: PROMETHEUS } surfacer { type: STACKDRIVER ignore_metrics_with_label { key: probe value: sysvars } }注意一旦你显式声明了任一 surfacer默认的 Prometheus 与文件导出就不会再自动生效需要按需自行补齐。四、进阶技巧指标过滤与导出为 Gauge按标签过滤通过allow_metrics_with_label/ignore_metrics_with_label控制导出范围例如只导出ptype: http的指标既能降低云监控费用也让面板更干净。按名称过滤用ignore_metrics_with_name: validation_failure屏蔽无用指标。导出为 Gauge设置export_as_gauge: true后指标以瞬时值而非累积值导出计算平均延迟等场景会更直观代价是丢失部分历史信息。增加失败指标add_failure_metric: true会额外导出 failure 计数目前除 FILE 和 PUBSUB 外默认开启。更多 Surfacer 机制与过滤说明可查阅官方文档 docs/content/docs/surfacers/overview.md、docs/content/docs/surfacers/cloudwatch.md 与 docs/content/docs/surfacers/stackdriver.md。结语通过 Cloudprober 内置的 surfacer 机制把主动监控指标接入AWS CloudWatch与Google Cloud Monitoring只需寥寥数行配置无需编写任何代码即可把探测数据沉淀到云原生监控体系中与既有告警、看板无缝衔接。再加上指标过滤、Gauge 导出、MQL / Metric Maths 等技巧你完全可以把 Cloudprober 打造成多云环境下的统一主动监控底座。现在就动手把指标接入你的云监控平台让故障暴露在真实用户之前吧【免费下载链接】cloudproberAn active monitoring software to detect failures before your customers do.项目地址: https://gitcode.com/gh_mirrors/clo/cloudprober创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/8/21 16:23:52 · 阅读 1.2k 将 Cloudprober 指标接入 AWS CloudWatch 与 Google Cloud Monitoring
将 Cloudprober 指标接入 AWS CloudWatch 与 Google Cloud Monitoring【免费下载链接】cloudproberAn active monitoring software to detect failures before your customers do.项目地址: https://gitcode.com/gh_mirrors/clo/cloudproberCloudprober 是一款开源的主动监控active monitoring工具能在真实用户发现问题之前主动探测你的网站、API 与内部服务提前发现故障。而它最强大的能力之一就是通过内置的surfacer指标导出器机制把采集到的监控指标一键导出到AWS CloudWatch与Google Cloud Monitoring原 Stackdriver等主流监控平台。本文将用最简单的方式带你完成 Cloudprober 指标接入两大云监控平台的全过程。什么是 Cloudprober 的 Surfacer指标导出机制Cloudprober 的核心优势在于一套探测、多处输出它支持 Prometheus、OpenTelemetry、AWS CloudWatch、Google Cloud Monitoring、Google Pub/Sub、Postgres 等十余种输出方式而且可以同时启用多个互不干扰。这个负责导出的内置机制就叫 surfacer你只需在配置文件中添加一段surfacer配置块即可把指标实时推送过去。整体架构可参考上方的 Cloudprober 架构图左侧是各类主动探测目标右侧则是 Dashboards、SLOs、告警等下游消费方。如果你不配置任何 surfacerCloudprober 会默认启用 Prometheus 与文件两种导出方式方便本地调试。一、把 Cloudprober 指标接入 AWS CloudWatch1. 快速配置步骤在 Cloudprober 配置文件中加入以下内容即可启用 CloudWatch 导出surfacer { type: CLOUDWATCH }就这么简单默认情况下指标会发布到名为cloudprober的 CloudWatch 命名空间namespace下指标维度Dimensions会自动携带探针名称、目标地址、协议类型等标签方便你在 CloudWatch 控制台按维度筛选。相关实现可参考源码模块 internal/surfacers/cloudwatch/cloudwatch.go。2. AWS 认证与 IAM 权限配置CloudWatch surfacer 基于 AWS Go SDK支持默认凭证链按以下顺序自动寻找凭证环境变量共享凭证文件~/.aws/credentialsECS 任务 IAM 角色EC2 实例 IAM 角色。为了让 Cloudprober 有权限写入指标你需要为对应角色配置如下 IAM 策略注意命名空间要与下方配置一致{ Version: 2012-10-17, Statement: [ { Condition: { StringEqualsIgnoreCase: { cloudwatch:namespace: cloudprober } }, Action: [cloudwatch:PutMetricData], Resource: [*], Effect: Allow, Sid: PutMetrics } ] }3. 指定 AWS 区域Cloudprober 确定写入区域的优先级为配置中的 region 字段 → EC2 元数据 →AWS_REGION环境变量 →AWS_DEFAULT_REGION环境变量。推荐直接在配置里写死避免歧义surfacer { type: CLOUDWATCH cloudwatch_surfacer { namespace: /cloudprober/website/probes region: us-east-1 resolution: 60 } }4. 更细粒度的 CloudWatch 配置项CloudWatch surfacer 的完整配置项定义在 internal/surfacers/cloudwatch/proto/config.proto 中常用参数如下配置项默认值说明namespacecloudproberCloudWatch 指标命名空间resolution60指标存储分辨率秒低于 60 会产生高分辨率计费region自动检测目标 AWS 区域metrics_batch_size1000单次批量写入的指标数上限API 上限 1000batch_timer_sec30缓冲区最长保留时间满批或超时即写入5. 用 CloudWatch Metric Maths 计算差值Cloudprober 导出的指标是累积值counter而 CloudWatch 大多展示快照值。要还原每个时间段的增量可以借助 CloudWatch Metric Maths 的RATE与PERIOD函数RATE(m1) * PERIOD(m1)其中m1是 Cloudprober 指标的数学表达式 ID例如namespace: cloudprober、metric name: latency、probe: 探针名。这样你就能在 CloudWatch 上得到与 Prometheusrate()等价的增量曲线。二、把 Cloudprober 指标接入 Google Cloud Monitoring1. 快速配置步骤Google Cloud Monitoring前身 Stackdriver的接入同样简单只需一行配置surfacer { type: STACKDRIVER }如果你运行在 GCP 上VM 或 GKE Pod 具备 Cloud Monitoring 写入权限这一句配置即可直接生效否则需要额外指定 GCP 项目并配置Google Application Default Credentials应用默认凭证。2. 指标命名与监控前缀默认情况下指标会以custom.googleapis.com/cloudprober/探针类型/探针名为前缀导出。例如名为google_com的 HTTP 探针会生成custom.googleapis.com/cloudprober/http/google_com/total custom.googleapis.com/cloudprober/http/google_com/success custom.googleapis.com/cloudprober/http/google_com/latency你还可以通过monitoring_url自定义前缀或用metrics_prefix调整层级NONE/PROBE/PTYPE_PROBE。完整参数见 internal/surfacers/stackdriver/proto/config.proto示例配置可参考 examples/surfacers/stackdriver_surfacer.cfg。3. 用 MQL 计算失败率与平均延迟由于导出的都是计数类指标直接看图意义不大。Google Cloud Monitoring 提供了强大的MQLMonitoring Query Language可以轻松算出更有价值的指标。比如计算失败率fetch global || { metric custom.googleapis.com/cloudprober/http/google_com/failure ; metric custom.googleapis.com/cloudprober/http/google_com/total } || align delta(1m) || join || div计算某个探针的平均延迟fetch global || { metric custom.googleapis.com/cloudprober/http/google_com/latency ; metric custom.googleapis.com/cloudprober/http/google_com/success } || align delta(1m) || join || div以上查询既可用于 Metrics Explorer 绘图也能直接用来创建告警规则。三、同时接入多个监控系统Surfacer 的另一个亮点是可以同时配置多个。例如下面的配置同时启用了 Prometheus 与 Google Cloud Monitoring且只把特定探针的指标导出到云平台surfacer { type: PROMETHEUS } surfacer { type: STACKDRIVER ignore_metrics_with_label { key: probe value: sysvars } }注意一旦你显式声明了任一 surfacer默认的 Prometheus 与文件导出就不会再自动生效需要按需自行补齐。四、进阶技巧指标过滤与导出为 Gauge按标签过滤通过allow_metrics_with_label/ignore_metrics_with_label控制导出范围例如只导出ptype: http的指标既能降低云监控费用也让面板更干净。按名称过滤用ignore_metrics_with_name: validation_failure屏蔽无用指标。导出为 Gauge设置export_as_gauge: true后指标以瞬时值而非累积值导出计算平均延迟等场景会更直观代价是丢失部分历史信息。增加失败指标add_failure_metric: true会额外导出 failure 计数目前除 FILE 和 PUBSUB 外默认开启。更多 Surfacer 机制与过滤说明可查阅官方文档 docs/content/docs/surfacers/overview.md、docs/content/docs/surfacers/cloudwatch.md 与 docs/content/docs/surfacers/stackdriver.md。结语通过 Cloudprober 内置的 surfacer 机制把主动监控指标接入AWS CloudWatch与Google Cloud Monitoring只需寥寥数行配置无需编写任何代码即可把探测数据沉淀到云原生监控体系中与既有告警、看板无缝衔接。再加上指标过滤、Gauge 导出、MQL / Metric Maths 等技巧你完全可以把 Cloudprober 打造成多云环境下的统一主动监控底座。现在就动手把指标接入你的云监控平台让故障暴露在真实用户之前吧【免费下载链接】cloudproberAn active monitoring software to detect failures before your customers do.项目地址: https://gitcode.com/gh_mirrors/clo/cloudprober创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考