Google Cloud Monitoring 指标选择技能通过 MCP 动态查询 MetricDescriptor 并本地关键词过滤【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills本文围绕 skills 仓库中的cloud-monitoring-metric-selection技能展开讲解如何为 AI Agent 构建一套“实时 API 查询 本地关键词过滤”的 GCP 监控指标发现流程从 MCP 服务端配置与校验、Project ID 强制澄清到按服务前缀构造list_metric_descriptors查询载荷、处理分页、执行本地过滤直至输出标准化的指标描述符表格。读完本文你将能够完整复现该技能的五步工作流并将其无缝接入 cloud-monitoring-list-time-series-request 与 cloud-monitoring-promql-query 等下游技能形成“指标发现 → 请求构造 → 图表生成”的可观测性工具链。技能定位在仓库中的上下游关系该技能的核心职责是为目标 GCP 服务或资源Compute Engine、Spanner、BigQuery、Cloud Run、Cloud SQL、Pub/Sub、Cloud Storage 等检索、查询并识别相关的 Google Cloud Monitoring 指标描述符MetricDescriptor。其定义见技能清单 index.json 中的同名条目并在 README.md 的 “Management tools” 分类下被列为 “Metric Selection (Service Query Local Keyword Filtering)”。从源码结构看该技能并非孤立存在而是仓库可观测性技能链路的“发现”入口cloud-monitoring-list-time-series-request 明确写道当用户提示词模糊例如只说“VM CPU 使用率”时应先使用cloud-monitoring-metric-selection技能定位具体的metric.type若 MCP 工具缺失也指向本技能完成监控 MCP 服务端的配置。cloud-monitoring-promql-query 与 cloud-monitoring-chart-generation 同样把本技能列为指标不明确时的前置步骤。插件目录下的 rules/google-cloud-discovery.md 将cloud-monitoring-*整体归入 “observability” 路由分类说明该技能是 Google Cloud 技能目录中可观测性领域的标准组件。技能的实现策略可概括为一句话不依赖任何硬编码指标清单而是从 API 动态拉取全量描述符再在 LLM 上下文内用关键词匹配完成二次过滤。这保证了数据新鲜度能覆盖自定义指标同时避免把大结果集直接暴露给下游。三条 CRITICAL RULES数据源、Project ID 与降级策略原文档开篇即给出三条必须遵守的规则它们是整个技能正确性的基石Always Query Live APIs永远实时查询必须始终通过调用list_metric_descriptorsMCP 工具动态获取最新的指标描述符禁止依赖记忆或静态缓存中的指标列表。Mandatory Project ID and Resource Parameter Clarification强制澄清 Project ID在调用任何 API 工具之前必须确认 GCP Project ID 已经出现在提示词、URI 或环境上下文中若无法解析必须先向用户询问绝不使用mock-project、my-project-id、unused、YOUR_PROJECT_ID这类占位项目名执行查询。Fallback Reporting降级上报如果 API 调用失败而不得不使用降级来源如公开文档必须明确报告错误内容、所使用的降级来源、以及非实时数据的风险数据可能过期、缺少自定义指标、schema 不匹配。其中第 2 条在下游技能 cloud-monitoring-list-time-series-request 中得到了呼应——后者同样要求 Project ID 缺失时必须先澄清并额外给出了一个可接受的解析途径gcloud config get-value project。两条规则配合防止 Agent 在错误的命名空间下执行指标发现。Step 1验证与自动配置 Monitoring MCP 服务端第一步的目标是确认list_metric_descriptors工具可用并在缺失时自动完成 MCP 配置。具体流程如下检查工具集在活跃工具集中查找任何匹配list_metric_descriptors的工具命名模式可能形如google-cloud-monitoring:list_metric_descriptors、mcp_google-cloud-monitoring_list_metric_descriptors或类似变体不同客户端对 MCP 工具的命名前缀不同因此按模式匹配而非精确名称匹配。通过唯一 URL 验证为确保调用的是正确的 Google Cloud Monitoring 工具需确认底层 MCP 服务端配置指向唯一地址https://monitoring.googleapis.com/mcp。工具缺失时的自动合并配置定位用户环境中的 MCP 配置文件常见路径~/.gemini/config/mcp_config.json~/.codeium/windsurf/mcp_config.jsoncline_mcp_settings.jsonclaude_desktop_config.json然后将以下服务端配置合并进mcpServers对象google-cloud-monitoring: { url: https://monitoring.googleapis.com/mcp, authProviderType: google_credentials, enabledTools: [ list_metric_descriptors ] }原文档特别标注CRITICAL必须合并mergeJSON 对象以保留mcpServers中已有的其他服务端不得覆盖整个文件。这一点与仓库中 plugins/cloud/google-cloud-developer/mcp.json 的组织方式一致——该文件本身就是一个只含单个developer-knowledge服务端的mcpServers结构合并而非覆盖是同类配置操作的通用要求。提示并结束回合打印明确信息告知用户google-cloud-monitoringMCP 服务端已配置完成请求其重启或开启新会话以刷新工具列表然后停止调用后续工具并结束当前回合。这一步避免了在工具尚未生效时继续执行必然失败的调用。Step 2解析请求并提取关键词请求分析阶段做三件事Resolve Project ID and Identifiers解析 Project ID 与资源标识从提示词、资源 URI 或环境上下文中解析 GCP Project ID 与资源标识并严格遵守上文 CRITICAL RULES 中“不使用占位项目名”的约束。Identify Service Prefix识别服务前缀把目标 GCP 服务映射到其标准前缀例如compute、spanner、bigquery、storage。Extract Metric Concepts提取指标概念从用户提示中提取指标关键词如 “CPU”、“memory”、“bytes scanned”、“latency”、“connections”并映射为搜索子串。原文档给出的示例值得逐字保留因为它展示了从自然语言到结构化查询参数的完整映射用户提示“Check Cloud Storage bucket write throughput and request count”资源 URI//storage.googleapis.com/projects/my-project/buckets/my-bucket服务前缀storage映射到storage.googleapis.com指标关键词write、throughput、request、count映射后的搜索子串write、throughput、request_count、count注意示例中request count同时映射出request_count与count两个子串——这是为描述符字段中常见的下划线命名做的前置归一化保证后续过滤时不会因命名风格差异漏掉storage.googleapis.com/bucket/bytes_write_count这类指标。Step 3按服务前缀发起 list_metric_descriptors 查询这是技能的核心查询步骤包含三个关键决策点3.1 每个服务前缀单独查询由于 Google Cloud Monitoring 的过滤语法不允许用OR组合多个metric.type限制条件必须为每个识别出的服务前缀单独发起一次查询可串行也可并行查询时使用pageSize: 200。3.2 过滤模式的六种构造方式将目标服务域映射到对应的前缀风格场景过滤前缀模式标准 Google Cloud 服务starts_with(service_prefix.googleapis.com/)如bigquery.googleapis.com/、redis.googleapis.com/Ops AgentGuest OSstarts_with(agent.googleapis.com/)用于 Guest OS 内存/磁盘指标Kubernetes / GKE 原生starts_with(kubernetes.io/)Istio 服务网格starts_with(istio.io/)Knative Serving / Autoscalerstarts_with(knative.dev/)自定义 / 外部指标starts_with(custom.googleapis.com/)或starts_with(external.googleapis.com/)这六类前缀覆盖了 GCP 监控生态的主要指标来源官方云服务指标、Guest Agent 指标、容器/网格指标以及用户自定义指标custom.googleapis.com/前缀正是 CRITICAL RULES 强调“实时查询”的价值所在——静态清单永远无法覆盖这些用户自建指标。3.3 示例工具调用载荷当请求同时涉及 Spanner 与 Compute Engine 时需执行两次工具调用Spanner 查询{ name: projects/my-project-id, filter: metric.type starts_with(\spanner.googleapis.com/\), pageSize: 200 }Compute Engine 查询{ name: projects/my-project-id, filter: metric.type starts_with(\compute.googleapis.com/\), pageSize: 200 }其中name字段为projects/project-id形式的资源路径filter使用 Monitoring Filter 语法pageSize控制单页返回的描述符数量。3.4 分页处理nextPageToken 必须消费完毕如果任何一次响应包含nextPageToken必须携带pageToken连续发起后续调用直到该前缀下的所有剩余描述符全部取回之后才允许进入本地过滤阶段。这一步是数据完整性的硬约束若在中途开始过滤可能因截断而漏掉排在后面的自定义指标。Step 4本地过滤与降级协议聚合 Step 3 返回的全部描述符后在 LLM 上下文内执行两步本地过滤Keyword Filtering关键词过滤用目标指标关键词如 “cpu”、“latency”与描述符的type、displayName、description三个字段做匹配。同时匹配这三个字段而非仅type是因为描述符的人类可读名称与说明文本往往包含关键词的另一种表达例如关键词 “latency” 可能只出现在description中。Resource Alignment资源粒度对齐检查指标是否包含与目标资源粒度匹配的 labels例如目标为数据库资源时检查是否存在database标签。原文档特别提醒不要尝试直接对资源类型字符串做动态匹配因为 Google Cloud Monitoring 的资源映射可能反直觉——典型例子是 Spanner database 映射到spanner_instance资源类型直接按 “database” 字样匹配资源类型会得出错误结论。故障排查与 API 降级Troubleshooting API Fallbacks当工具调用失败、超时或返回空结果时按以下三种情形处置Case AAPI 语法错误——检查错误信息修正 filter 语法后重试。Case B超时 / 限流——以较小的页大小如pageSize: 20重试一次。Case C不可恢复失败 / 空列表先验证目标服务是否已在该项目中启用服务未启用时该前缀下没有描述符空结果是正常现象不是 API 故障再检索 Google Cloud 公开文档核对该服务的标准指标作为降级来源。按 CRITICAL RULES 第 3 条一旦走了第 2 步降级路径最终输出中必须声明错误、降级来源与数据陈旧风险保证读者知晓结论的置信度边界。Step 5输出标准化指标表格最终输出阶段有两条硬性格式约束数量控制每个服务域只返回 515 个与用户意图直接相关的核心指标避免把过滤后的全量列表倾倒给用户按服务分组以干净的 Markdown 表格输出每个服务前缀一张表且必须包含以下七列Metric Type、Display Name、Description、Metric Kind、Value Type、Unit、Monitored Resource Types。字段到list_metric_descriptors响应对象的映射关系是明确的表格列描述符字段示例值Metric Typetypespanner.googleapis.com/instance/cpu/utilizationDisplay NamedisplayNameInstance CPU UtilizationDescriptiondescriptionFraction of allocated CPU currently in use.Metric KindmetricKindGAUGE、DELTA、CUMULATIVEValue TypevalueTypeINT64、DOUBLE、DISTRIBUTION、BOOLUnitunit1、By、s、msMonitored Resource TypesmonitoredResourceTypes[spanner_instance]原文档的示例输出表格如下Metric TypeDisplay NameDescriptionMetric KindValue TypeUnitMonitored Resource Typesspanner.googleapis.com/instance/cpu/utilizationInstance CPU UtilizationFraction of allocated CPU currently in use.GAUGEDOUBLE1[spanner_instance]这七列不是展示性信息而是下游技能的直接输入cloud-monitoring-list-time-series-request 技能明确要求从描述符中提取metricKind决定 aligner/reducer 的选择、valueType决定数值处理与monitoredResourceTypes决定resource.type过滤子句例如从[cloudsql_database, cloudsql_instance]中按用户粒度挑选其一来构造ListTimeSeries请求参数cloud-monitoring-promql-query 同样以这些元数据为前提。因此表格列的严格标准化实际上是该技能与下游技能之间的接口契约。与仓库中配套技能与文档的协作方式结合仓库内容可以进一步理解该技能在整体链路中的位置上游触发当用户请求模糊“看看我的 Spanner 数据库健康状况”“VM CPU 高”而无法直接给出metric.type时list-time-series-request 与 promql-query 两个技能都会显式把流程交还给本技能。同族可观测技能cloud-logging-query-generation日志查询生成与 cloud-monitoring-chart-generation图表生成与本技能共同构成监控/日志方向的能力矩阵路由规则见 rules/google-cloud-discovery.md原文档中写为google-cloud-discovery.md位于插件 rules 目录。MCP 配置范式插件内 mcp.json 展示了mcpServers指向https://developerknowledge.googleapis.com/mcp的标准写法本技能要求的google-cloud-monitoring服务端条目采用同样的结构范式只是 URL 换成https://monitoring.googleapis.com/mcp并附加enabledTools白名单仅启用list_metric_descriptors一个工具这是最小权限的做法——指标发现只需要列表能力不需要读写时序数据。背景参考原文档的 Reference Documentation 一节指向了 GCP Metrics 文档、list_metric_descriptorsMCP 工具参考与 Monitoring Filter 语法指南在本仓库中可直接阅读的技能级入口是 skills/cloud/cloud-monitoring-metric-selection/SKILL.md。适用前提与限制小结综合原文档的约束使用该技能或按该文复现该流程时需满足以下前提并注意相应限制必须有已确认的 GCP Project ID占位项目名被明令禁止缺失时必须向用户澄清这是不可跳过的守卫步骤。必须有可用的 Monitoring MCP 服务端指向https://monitoring.googleapis.com/mcp认证方式为google_credentials若需现场配置注意合并写入、配置后须重启会话。过滤语法的限制不能在一次查询中OR多个metric.type前缀多服务场景只能多查并聚合查询结果必须消费完所有nextPageToken才能过滤。资源映射需靠 labels 而非资源类型字符串如 Spanner database 实际映射到spanner_instance做资源粒度对齐时要检查指标的 label 结构。降级必须透明任何基于公开文档而非实时 API 的结论都要附带错误说明、来源声明与数据陈旧风险提示。掌握以上流程后该技能即可作为 GCP 可观测性 Agent 工作流的指标发现基座上游承接模糊的用户请求下游向 ListTimeSeries 请求生成、PromQL 生成与图表生成技能输出结构化的指标元数据整条链路全部基于实时 API 数据而非硬编码清单。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Google Cloud Monitoring 指标选择技能：通过 MCP 动态查询 MetricDescriptor 并本地关键词过滤
Google Cloud Monitoring 指标选择技能通过 MCP 动态查询 MetricDescriptor 并本地关键词过滤【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills本文围绕 skills 仓库中的cloud-monitoring-metric-selection技能展开讲解如何为 AI Agent 构建一套“实时 API 查询 本地关键词过滤”的 GCP 监控指标发现流程从 MCP 服务端配置与校验、Project ID 强制澄清到按服务前缀构造list_metric_descriptors查询载荷、处理分页、执行本地过滤直至输出标准化的指标描述符表格。读完本文你将能够完整复现该技能的五步工作流并将其无缝接入 cloud-monitoring-list-time-series-request 与 cloud-monitoring-promql-query 等下游技能形成“指标发现 → 请求构造 → 图表生成”的可观测性工具链。技能定位在仓库中的上下游关系该技能的核心职责是为目标 GCP 服务或资源Compute Engine、Spanner、BigQuery、Cloud Run、Cloud SQL、Pub/Sub、Cloud Storage 等检索、查询并识别相关的 Google Cloud Monitoring 指标描述符MetricDescriptor。其定义见技能清单 index.json 中的同名条目并在 README.md 的 “Management tools” 分类下被列为 “Metric Selection (Service Query Local Keyword Filtering)”。从源码结构看该技能并非孤立存在而是仓库可观测性技能链路的“发现”入口cloud-monitoring-list-time-series-request 明确写道当用户提示词模糊例如只说“VM CPU 使用率”时应先使用cloud-monitoring-metric-selection技能定位具体的metric.type若 MCP 工具缺失也指向本技能完成监控 MCP 服务端的配置。cloud-monitoring-promql-query 与 cloud-monitoring-chart-generation 同样把本技能列为指标不明确时的前置步骤。插件目录下的 rules/google-cloud-discovery.md 将cloud-monitoring-*整体归入 “observability” 路由分类说明该技能是 Google Cloud 技能目录中可观测性领域的标准组件。技能的实现策略可概括为一句话不依赖任何硬编码指标清单而是从 API 动态拉取全量描述符再在 LLM 上下文内用关键词匹配完成二次过滤。这保证了数据新鲜度能覆盖自定义指标同时避免把大结果集直接暴露给下游。三条 CRITICAL RULES数据源、Project ID 与降级策略原文档开篇即给出三条必须遵守的规则它们是整个技能正确性的基石Always Query Live APIs永远实时查询必须始终通过调用list_metric_descriptorsMCP 工具动态获取最新的指标描述符禁止依赖记忆或静态缓存中的指标列表。Mandatory Project ID and Resource Parameter Clarification强制澄清 Project ID在调用任何 API 工具之前必须确认 GCP Project ID 已经出现在提示词、URI 或环境上下文中若无法解析必须先向用户询问绝不使用mock-project、my-project-id、unused、YOUR_PROJECT_ID这类占位项目名执行查询。Fallback Reporting降级上报如果 API 调用失败而不得不使用降级来源如公开文档必须明确报告错误内容、所使用的降级来源、以及非实时数据的风险数据可能过期、缺少自定义指标、schema 不匹配。其中第 2 条在下游技能 cloud-monitoring-list-time-series-request 中得到了呼应——后者同样要求 Project ID 缺失时必须先澄清并额外给出了一个可接受的解析途径gcloud config get-value project。两条规则配合防止 Agent 在错误的命名空间下执行指标发现。Step 1验证与自动配置 Monitoring MCP 服务端第一步的目标是确认list_metric_descriptors工具可用并在缺失时自动完成 MCP 配置。具体流程如下检查工具集在活跃工具集中查找任何匹配list_metric_descriptors的工具命名模式可能形如google-cloud-monitoring:list_metric_descriptors、mcp_google-cloud-monitoring_list_metric_descriptors或类似变体不同客户端对 MCP 工具的命名前缀不同因此按模式匹配而非精确名称匹配。通过唯一 URL 验证为确保调用的是正确的 Google Cloud Monitoring 工具需确认底层 MCP 服务端配置指向唯一地址https://monitoring.googleapis.com/mcp。工具缺失时的自动合并配置定位用户环境中的 MCP 配置文件常见路径~/.gemini/config/mcp_config.json~/.codeium/windsurf/mcp_config.jsoncline_mcp_settings.jsonclaude_desktop_config.json然后将以下服务端配置合并进mcpServers对象google-cloud-monitoring: { url: https://monitoring.googleapis.com/mcp, authProviderType: google_credentials, enabledTools: [ list_metric_descriptors ] }原文档特别标注CRITICAL必须合并mergeJSON 对象以保留mcpServers中已有的其他服务端不得覆盖整个文件。这一点与仓库中 plugins/cloud/google-cloud-developer/mcp.json 的组织方式一致——该文件本身就是一个只含单个developer-knowledge服务端的mcpServers结构合并而非覆盖是同类配置操作的通用要求。提示并结束回合打印明确信息告知用户google-cloud-monitoringMCP 服务端已配置完成请求其重启或开启新会话以刷新工具列表然后停止调用后续工具并结束当前回合。这一步避免了在工具尚未生效时继续执行必然失败的调用。Step 2解析请求并提取关键词请求分析阶段做三件事Resolve Project ID and Identifiers解析 Project ID 与资源标识从提示词、资源 URI 或环境上下文中解析 GCP Project ID 与资源标识并严格遵守上文 CRITICAL RULES 中“不使用占位项目名”的约束。Identify Service Prefix识别服务前缀把目标 GCP 服务映射到其标准前缀例如compute、spanner、bigquery、storage。Extract Metric Concepts提取指标概念从用户提示中提取指标关键词如 “CPU”、“memory”、“bytes scanned”、“latency”、“connections”并映射为搜索子串。原文档给出的示例值得逐字保留因为它展示了从自然语言到结构化查询参数的完整映射用户提示“Check Cloud Storage bucket write throughput and request count”资源 URI//storage.googleapis.com/projects/my-project/buckets/my-bucket服务前缀storage映射到storage.googleapis.com指标关键词write、throughput、request、count映射后的搜索子串write、throughput、request_count、count注意示例中request count同时映射出request_count与count两个子串——这是为描述符字段中常见的下划线命名做的前置归一化保证后续过滤时不会因命名风格差异漏掉storage.googleapis.com/bucket/bytes_write_count这类指标。Step 3按服务前缀发起 list_metric_descriptors 查询这是技能的核心查询步骤包含三个关键决策点3.1 每个服务前缀单独查询由于 Google Cloud Monitoring 的过滤语法不允许用OR组合多个metric.type限制条件必须为每个识别出的服务前缀单独发起一次查询可串行也可并行查询时使用pageSize: 200。3.2 过滤模式的六种构造方式将目标服务域映射到对应的前缀风格场景过滤前缀模式标准 Google Cloud 服务starts_with(service_prefix.googleapis.com/)如bigquery.googleapis.com/、redis.googleapis.com/Ops AgentGuest OSstarts_with(agent.googleapis.com/)用于 Guest OS 内存/磁盘指标Kubernetes / GKE 原生starts_with(kubernetes.io/)Istio 服务网格starts_with(istio.io/)Knative Serving / Autoscalerstarts_with(knative.dev/)自定义 / 外部指标starts_with(custom.googleapis.com/)或starts_with(external.googleapis.com/)这六类前缀覆盖了 GCP 监控生态的主要指标来源官方云服务指标、Guest Agent 指标、容器/网格指标以及用户自定义指标custom.googleapis.com/前缀正是 CRITICAL RULES 强调“实时查询”的价值所在——静态清单永远无法覆盖这些用户自建指标。3.3 示例工具调用载荷当请求同时涉及 Spanner 与 Compute Engine 时需执行两次工具调用Spanner 查询{ name: projects/my-project-id, filter: metric.type starts_with(\spanner.googleapis.com/\), pageSize: 200 }Compute Engine 查询{ name: projects/my-project-id, filter: metric.type starts_with(\compute.googleapis.com/\), pageSize: 200 }其中name字段为projects/project-id形式的资源路径filter使用 Monitoring Filter 语法pageSize控制单页返回的描述符数量。3.4 分页处理nextPageToken 必须消费完毕如果任何一次响应包含nextPageToken必须携带pageToken连续发起后续调用直到该前缀下的所有剩余描述符全部取回之后才允许进入本地过滤阶段。这一步是数据完整性的硬约束若在中途开始过滤可能因截断而漏掉排在后面的自定义指标。Step 4本地过滤与降级协议聚合 Step 3 返回的全部描述符后在 LLM 上下文内执行两步本地过滤Keyword Filtering关键词过滤用目标指标关键词如 “cpu”、“latency”与描述符的type、displayName、description三个字段做匹配。同时匹配这三个字段而非仅type是因为描述符的人类可读名称与说明文本往往包含关键词的另一种表达例如关键词 “latency” 可能只出现在description中。Resource Alignment资源粒度对齐检查指标是否包含与目标资源粒度匹配的 labels例如目标为数据库资源时检查是否存在database标签。原文档特别提醒不要尝试直接对资源类型字符串做动态匹配因为 Google Cloud Monitoring 的资源映射可能反直觉——典型例子是 Spanner database 映射到spanner_instance资源类型直接按 “database” 字样匹配资源类型会得出错误结论。故障排查与 API 降级Troubleshooting API Fallbacks当工具调用失败、超时或返回空结果时按以下三种情形处置Case AAPI 语法错误——检查错误信息修正 filter 语法后重试。Case B超时 / 限流——以较小的页大小如pageSize: 20重试一次。Case C不可恢复失败 / 空列表先验证目标服务是否已在该项目中启用服务未启用时该前缀下没有描述符空结果是正常现象不是 API 故障再检索 Google Cloud 公开文档核对该服务的标准指标作为降级来源。按 CRITICAL RULES 第 3 条一旦走了第 2 步降级路径最终输出中必须声明错误、降级来源与数据陈旧风险保证读者知晓结论的置信度边界。Step 5输出标准化指标表格最终输出阶段有两条硬性格式约束数量控制每个服务域只返回 515 个与用户意图直接相关的核心指标避免把过滤后的全量列表倾倒给用户按服务分组以干净的 Markdown 表格输出每个服务前缀一张表且必须包含以下七列Metric Type、Display Name、Description、Metric Kind、Value Type、Unit、Monitored Resource Types。字段到list_metric_descriptors响应对象的映射关系是明确的表格列描述符字段示例值Metric Typetypespanner.googleapis.com/instance/cpu/utilizationDisplay NamedisplayNameInstance CPU UtilizationDescriptiondescriptionFraction of allocated CPU currently in use.Metric KindmetricKindGAUGE、DELTA、CUMULATIVEValue TypevalueTypeINT64、DOUBLE、DISTRIBUTION、BOOLUnitunit1、By、s、msMonitored Resource TypesmonitoredResourceTypes[spanner_instance]原文档的示例输出表格如下Metric TypeDisplay NameDescriptionMetric KindValue TypeUnitMonitored Resource Typesspanner.googleapis.com/instance/cpu/utilizationInstance CPU UtilizationFraction of allocated CPU currently in use.GAUGEDOUBLE1[spanner_instance]这七列不是展示性信息而是下游技能的直接输入cloud-monitoring-list-time-series-request 技能明确要求从描述符中提取metricKind决定 aligner/reducer 的选择、valueType决定数值处理与monitoredResourceTypes决定resource.type过滤子句例如从[cloudsql_database, cloudsql_instance]中按用户粒度挑选其一来构造ListTimeSeries请求参数cloud-monitoring-promql-query 同样以这些元数据为前提。因此表格列的严格标准化实际上是该技能与下游技能之间的接口契约。与仓库中配套技能与文档的协作方式结合仓库内容可以进一步理解该技能在整体链路中的位置上游触发当用户请求模糊“看看我的 Spanner 数据库健康状况”“VM CPU 高”而无法直接给出metric.type时list-time-series-request 与 promql-query 两个技能都会显式把流程交还给本技能。同族可观测技能cloud-logging-query-generation日志查询生成与 cloud-monitoring-chart-generation图表生成与本技能共同构成监控/日志方向的能力矩阵路由规则见 rules/google-cloud-discovery.md原文档中写为google-cloud-discovery.md位于插件 rules 目录。MCP 配置范式插件内 mcp.json 展示了mcpServers指向https://developerknowledge.googleapis.com/mcp的标准写法本技能要求的google-cloud-monitoring服务端条目采用同样的结构范式只是 URL 换成https://monitoring.googleapis.com/mcp并附加enabledTools白名单仅启用list_metric_descriptors一个工具这是最小权限的做法——指标发现只需要列表能力不需要读写时序数据。背景参考原文档的 Reference Documentation 一节指向了 GCP Metrics 文档、list_metric_descriptorsMCP 工具参考与 Monitoring Filter 语法指南在本仓库中可直接阅读的技能级入口是 skills/cloud/cloud-monitoring-metric-selection/SKILL.md。适用前提与限制小结综合原文档的约束使用该技能或按该文复现该流程时需满足以下前提并注意相应限制必须有已确认的 GCP Project ID占位项目名被明令禁止缺失时必须向用户澄清这是不可跳过的守卫步骤。必须有可用的 Monitoring MCP 服务端指向https://monitoring.googleapis.com/mcp认证方式为google_credentials若需现场配置注意合并写入、配置后须重启会话。过滤语法的限制不能在一次查询中OR多个metric.type前缀多服务场景只能多查并聚合查询结果必须消费完所有nextPageToken才能过滤。资源映射需靠 labels 而非资源类型字符串如 Spanner database 实际映射到spanner_instance做资源粒度对齐时要检查指标的 label 结构。降级必须透明任何基于公开文档而非实时 API 的结论都要附带错误说明、来源声明与数据陈旧风险提示。掌握以上流程后该技能即可作为 GCP 可观测性 Agent 工作流的指标发现基座上游承接模糊的用户请求下游向 ListTimeSeries 请求生成、PromQL 生成与图表生成技能输出结构化的指标元数据整条链路全部基于实时 API 数据而非硬编码清单。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
