Nightingale 集成指南使用 Categraf GCP 指标采集插件监控 Google Cloud【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale导读本文围绕 integrations/GoogleCloud 目录下的 GCP 指标采集插件GCP Metrics Collection Plugin展开说明如何通过 Categraf 采集 Google CloudGCP平台上的监控指标并将其汇入 Nightingale 进行存储、告警与可视化。读完本文你将掌握该插件的权限配置、认证方式、全部配置参数的含义与取值范围以及如何针对 GCE 实例等资源做精细化过滤采集。一、插件定位GCP 监控指标如何进入 NightingaleNightingale 本身不负责监控数据的采集项目官方推荐使用 CategrafCategraf 采集操作系统、网络设备、中间件、数据库以及各类云平台如 GCP的监控数据再通过Prometheus Remote Write协议推送到 Nightingale由 Nightingale 完成时序存储如 Prometheus、VictoriaMetrics 等与告警可视化。本项目根目录下的integrations/目录即存放了大量采集插件的示例配置、告警规则与仪表盘模板其中 GoogleCloud 就是面向 Google Cloud 的采集插件包collect/googlecloud/gcp.tomlGCP 采集插件的 TOML 配置模板markdown/README.en_US.md 与 markdown/README.md插件的英文/中文使用说明本文即基于英文文档展开。该插件通过 Google Cloud Monitoring API 拉取指标因此需要给服务账号授予只读监控权限并配置项目 ID 与凭据。二、所需权限只读访问 Google Cloud Monitoring使用该插件前需要为服务账号Service Account授予以下 OAuth Scopehttps://www.googleapis.com/auth/monitoring.read这是 Google Cloud Monitoring 的只读权限范围仅允许读取监控数据时间序列、告警策略等无法修改任何资源符合最小权限原则。实际使用中你需要在 Google Cloud Console 中创建或选择一个服务账号为该账号授予包含monitoring.read权限范围的凭据如 JSON 格式的 service account key将 key 文件下载到采集器所在机器上供插件读取。提示更精细的做法是仅对目标项目project授予该权限避免凭据具备跨项目读取能力。三、配置文件与核心参数详解插件的完整配置模板见 collect/googlecloud/gcp.toml。其整体结构沿用 Categraf 插件的通用形态顶层interval定义采集周期[[instances]]数组内定义每个采集实例的具体参数。以下逐项解析英文文档 README.en_US.md 中的配置# collect interval, recommended to be 1 minute interval60 [[instances]] # set the project_id project_idyour-project-id # set the credentials key file credentials_file/path/to/your/key.json # or set the credentials JSON directly credentials_jsonxxx参数是否必填默认值说明interval是60采集周期秒建议不小于 1 分钟60s因为 Cloud Monitoring 的指标最小粒度通常为 60 秒project_id是无GCP 项目 ID即 metrics 归属的项目credentials_file二选一无服务账号 key 文件的路径例如/path/to/your/key.jsoncredentials_json二选一无直接以字符串形式内嵌凭据 JSON当不便引用文件时使用credentials_file与credentials_json只需配置其一前者适合在服务器上用文件管理凭据后者适合把凭据直接写入配置文件、随配置分发。3.1 时间窗口delay 与 period指标拉取并非取当前时刻而是基于一个延迟窗口以应对 GCP 监控数据落盘的延迟# metric end time now - delay #delay2m # metric start time now - deley - period #period1mdelay指标结束时间 当前时间 − delay。即允许数据延迟多久后再拉取默认建议2m2 分钟。如果拉得太新GCP 侧数据尚未写入容易取到空值period指标起始时间 当前时间 − delay − period即一次拉取覆盖的时间跨度默认建议1m1 分钟。注意文档原文中该行注释为deley拼写笔误实际含义即 delay。两者共同决定了每次请求的时间区间[now - delay - period, now - delay]可视为与 CloudWatch 插件中delay/period参数见 integrations/CloudWatch/collect/cloudwatch/cloud.toml对齐的同类设计delay必须能覆盖指标在云侧的可查延迟period则通常是采集周期的整数倍。3.2 指标过滤器 filter#filtermetric.type\compute.googleapis.com/instance/cpu/utilization\ AND resource.labels.zone\asia-northeast1-a\filter使用 Google Cloud Monitoring 的过滤表达式语法可以按metric.type指标类型与resource.labels资源标签筛选要采集的指标。示例含义为只采集asia-northeast1-a可用区中 GCE 实例的 CPU 利用率指标。合理设置 filter 可以显著减少 API 请求量与数据处理量。3.3 请求控制timeout 与 request_inflight# request timeout #timeout5s # cache TTL for the metric list; only takes effect when filter is empty #cache_ttl1h # give the GCE instance_name an alias and put it into a label #gce_host_tagxxx # maximum number of concurrent requests in flight #request_inflight30 # request_inflight valid range is (0,100] # set a larger value only if you know what you are doing force_request_inflight 200timeout单次 HTTP 请求超时时间示例为5scache_ttl指标列表metric list的缓存时长。仅当 filter 为空时生效即插件在未指定 filter 时需要先枚举全部指标用缓存避免每次采集都重复拉取指标清单gce_host_tag给 GCE 实例的instance_name取一个别名并放入 label 中便于在 Nightingale 侧按主机维度关联与筛选request_inflight并发在途请求数上限合法取值范围为(0, 100]force_request_inflight强制并发数设置。文档特别注明request_inflight的合法范围是(0,100]而示例force_request_inflight 200超出了该范围——这类强制参数只有在你清楚自己在做什么例如已确认 GCP 配额允许更高并发时才建议使用否则可能触发 GCP API 限流。四、一个可落地的完整配置示例将上述参数组合得到一份针对单项目的可用配置可直接写入 Categraf 的采集配置目录# 采集周期GCP 指标最小粒度为 1 分钟建议不低于 60s interval60 [[instances]] project_idyour-project-id credentials_file/etc/categraf/gcp-key.json # 数据延迟与时间窗 delay2m period1m # 按需过滤只采 GCE 实例 CPU 利用率 filtermetric.type\compute.googleapis.com/instance/cpu/utilization\ # 请求控制 timeout5s cache_ttl1h request_inflight30 # 主机别名标签可选 gce_host_taggce_instance配置完成后启动/重载 Categraf插件会按interval周期通过 Cloud Monitoring API 拉取指标转换为 Prometheus 格式的时序数据后由 Categraf 经 Remote Write 推送到 Nightingale。后续即可在 Nightingale 中针对这些指标创建告警规则与仪表盘integrations/目录内的各组件包通常还附带 alerts 规则与 dashboards 模板可参考同类云平台插件如 CloudWatch。五、使用建议与注意事项采集周期下限GCP 指标的最小数据粒度是 60 秒interval建议保持 60否则可能出现空轮询浪费 API 配额凭据安全credentials_file指向的 key 文件务必设置合理的文件权限若使用credentials_json内嵌凭据需注意配置文件本身的访问控制并发与配额request_inflight默认上限 100贸然使用force_request_inflight放大并发可能触发 Google Cloud Monitoring API 的速率限制rate limit仅在确认配额充足时使用善用 filter能明确metric.type与resource.labels时优先配置 filter 缩小采集范围既可降低 API 调用量也能减少 Nightingale 侧的存储压力延迟窗口如果发现指标经常缺失或为空优先检查delay是否覆盖了数据落盘延迟可适当调大如 3m~5m。六、小结GCP 指标采集插件以极简的 TOML 配置即可完成 Google Cloud 监控数据的接入通过monitoring.read只读权限 服务账号凭据配合project_id与时间窗、过滤器、并发控制等参数即可将 GCE 等 GCP 资源的指标稳定地采集进 Nightingale 体系。本文涉及的配置模板与说明文档均位于 integrations/GoogleCloud可直接在仓库中查阅、复制并落地使用。【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/15 20:06:17 · 阅读 1.2k Nightingale 集成指南：使用 Categraf GCP 指标采集插件监控 Google Cloud
Nightingale 集成指南使用 Categraf GCP 指标采集插件监控 Google Cloud【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale导读本文围绕 integrations/GoogleCloud 目录下的 GCP 指标采集插件GCP Metrics Collection Plugin展开说明如何通过 Categraf 采集 Google CloudGCP平台上的监控指标并将其汇入 Nightingale 进行存储、告警与可视化。读完本文你将掌握该插件的权限配置、认证方式、全部配置参数的含义与取值范围以及如何针对 GCE 实例等资源做精细化过滤采集。一、插件定位GCP 监控指标如何进入 NightingaleNightingale 本身不负责监控数据的采集项目官方推荐使用 CategrafCategraf 采集操作系统、网络设备、中间件、数据库以及各类云平台如 GCP的监控数据再通过Prometheus Remote Write协议推送到 Nightingale由 Nightingale 完成时序存储如 Prometheus、VictoriaMetrics 等与告警可视化。本项目根目录下的integrations/目录即存放了大量采集插件的示例配置、告警规则与仪表盘模板其中 GoogleCloud 就是面向 Google Cloud 的采集插件包collect/googlecloud/gcp.tomlGCP 采集插件的 TOML 配置模板markdown/README.en_US.md 与 markdown/README.md插件的英文/中文使用说明本文即基于英文文档展开。该插件通过 Google Cloud Monitoring API 拉取指标因此需要给服务账号授予只读监控权限并配置项目 ID 与凭据。二、所需权限只读访问 Google Cloud Monitoring使用该插件前需要为服务账号Service Account授予以下 OAuth Scopehttps://www.googleapis.com/auth/monitoring.read这是 Google Cloud Monitoring 的只读权限范围仅允许读取监控数据时间序列、告警策略等无法修改任何资源符合最小权限原则。实际使用中你需要在 Google Cloud Console 中创建或选择一个服务账号为该账号授予包含monitoring.read权限范围的凭据如 JSON 格式的 service account key将 key 文件下载到采集器所在机器上供插件读取。提示更精细的做法是仅对目标项目project授予该权限避免凭据具备跨项目读取能力。三、配置文件与核心参数详解插件的完整配置模板见 collect/googlecloud/gcp.toml。其整体结构沿用 Categraf 插件的通用形态顶层interval定义采集周期[[instances]]数组内定义每个采集实例的具体参数。以下逐项解析英文文档 README.en_US.md 中的配置# collect interval, recommended to be 1 minute interval60 [[instances]] # set the project_id project_idyour-project-id # set the credentials key file credentials_file/path/to/your/key.json # or set the credentials JSON directly credentials_jsonxxx参数是否必填默认值说明interval是60采集周期秒建议不小于 1 分钟60s因为 Cloud Monitoring 的指标最小粒度通常为 60 秒project_id是无GCP 项目 ID即 metrics 归属的项目credentials_file二选一无服务账号 key 文件的路径例如/path/to/your/key.jsoncredentials_json二选一无直接以字符串形式内嵌凭据 JSON当不便引用文件时使用credentials_file与credentials_json只需配置其一前者适合在服务器上用文件管理凭据后者适合把凭据直接写入配置文件、随配置分发。3.1 时间窗口delay 与 period指标拉取并非取当前时刻而是基于一个延迟窗口以应对 GCP 监控数据落盘的延迟# metric end time now - delay #delay2m # metric start time now - deley - period #period1mdelay指标结束时间 当前时间 − delay。即允许数据延迟多久后再拉取默认建议2m2 分钟。如果拉得太新GCP 侧数据尚未写入容易取到空值period指标起始时间 当前时间 − delay − period即一次拉取覆盖的时间跨度默认建议1m1 分钟。注意文档原文中该行注释为deley拼写笔误实际含义即 delay。两者共同决定了每次请求的时间区间[now - delay - period, now - delay]可视为与 CloudWatch 插件中delay/period参数见 integrations/CloudWatch/collect/cloudwatch/cloud.toml对齐的同类设计delay必须能覆盖指标在云侧的可查延迟period则通常是采集周期的整数倍。3.2 指标过滤器 filter#filtermetric.type\compute.googleapis.com/instance/cpu/utilization\ AND resource.labels.zone\asia-northeast1-a\filter使用 Google Cloud Monitoring 的过滤表达式语法可以按metric.type指标类型与resource.labels资源标签筛选要采集的指标。示例含义为只采集asia-northeast1-a可用区中 GCE 实例的 CPU 利用率指标。合理设置 filter 可以显著减少 API 请求量与数据处理量。3.3 请求控制timeout 与 request_inflight# request timeout #timeout5s # cache TTL for the metric list; only takes effect when filter is empty #cache_ttl1h # give the GCE instance_name an alias and put it into a label #gce_host_tagxxx # maximum number of concurrent requests in flight #request_inflight30 # request_inflight valid range is (0,100] # set a larger value only if you know what you are doing force_request_inflight 200timeout单次 HTTP 请求超时时间示例为5scache_ttl指标列表metric list的缓存时长。仅当 filter 为空时生效即插件在未指定 filter 时需要先枚举全部指标用缓存避免每次采集都重复拉取指标清单gce_host_tag给 GCE 实例的instance_name取一个别名并放入 label 中便于在 Nightingale 侧按主机维度关联与筛选request_inflight并发在途请求数上限合法取值范围为(0, 100]force_request_inflight强制并发数设置。文档特别注明request_inflight的合法范围是(0,100]而示例force_request_inflight 200超出了该范围——这类强制参数只有在你清楚自己在做什么例如已确认 GCP 配额允许更高并发时才建议使用否则可能触发 GCP API 限流。四、一个可落地的完整配置示例将上述参数组合得到一份针对单项目的可用配置可直接写入 Categraf 的采集配置目录# 采集周期GCP 指标最小粒度为 1 分钟建议不低于 60s interval60 [[instances]] project_idyour-project-id credentials_file/etc/categraf/gcp-key.json # 数据延迟与时间窗 delay2m period1m # 按需过滤只采 GCE 实例 CPU 利用率 filtermetric.type\compute.googleapis.com/instance/cpu/utilization\ # 请求控制 timeout5s cache_ttl1h request_inflight30 # 主机别名标签可选 gce_host_taggce_instance配置完成后启动/重载 Categraf插件会按interval周期通过 Cloud Monitoring API 拉取指标转换为 Prometheus 格式的时序数据后由 Categraf 经 Remote Write 推送到 Nightingale。后续即可在 Nightingale 中针对这些指标创建告警规则与仪表盘integrations/目录内的各组件包通常还附带 alerts 规则与 dashboards 模板可参考同类云平台插件如 CloudWatch。五、使用建议与注意事项采集周期下限GCP 指标的最小数据粒度是 60 秒interval建议保持 60否则可能出现空轮询浪费 API 配额凭据安全credentials_file指向的 key 文件务必设置合理的文件权限若使用credentials_json内嵌凭据需注意配置文件本身的访问控制并发与配额request_inflight默认上限 100贸然使用force_request_inflight放大并发可能触发 Google Cloud Monitoring API 的速率限制rate limit仅在确认配额充足时使用善用 filter能明确metric.type与resource.labels时优先配置 filter 缩小采集范围既可降低 API 调用量也能减少 Nightingale 侧的存储压力延迟窗口如果发现指标经常缺失或为空优先检查delay是否覆盖了数据落盘延迟可适当调大如 3m~5m。六、小结GCP 指标采集插件以极简的 TOML 配置即可完成 Google Cloud 监控数据的接入通过monitoring.read只读权限 服务账号凭据配合project_id与时间窗、过滤器、并发控制等参数即可将 GCE 等 GCP 资源的指标稳定地采集进 Nightingale 体系。本文涉及的配置模板与说明文档均位于 integrations/GoogleCloud可直接在仓库中查阅、复制并落地使用。【免费下载链接】nightingaleNightingale is to monitoring and alerting what Grafana is to visualization.项目地址: https://gitcode.com/GitHub_Trending/ni/nightingale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考