无历史流量数据场景下的 Agent 告警配置agent-platform-alert-configuration 的流量模式决策与默认策略指南【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills本文聚焦 agent-platform-alert-configuration 技能在目标 Agent 没有任何历史监控数据例如全新上线的 Agent时的告警配置方法论。当无法用数据分析流量模式时正确的做法是显式向用户询问预期的流量特征并在自动化/即时配置场景下以 Steady/ConsistentShort-Window Z-Score作为默认策略先行落地同时处理 Error Rate 的 SLO 预热期与 Seasonal 模式的 1 周盲区风险。读完本文你将掌握无数据场景下的模式选项与映射关系、各算法的数据预热要求、默认配置的生成规则以及对应的 PromQL 与 Terraform 实现细节。一、场景定位什么情况下会走进无历史流量数据分支在 agent-platform-alert-configuration 的可靠性Reliability与成本Cost告警配置流程中Latency延迟与 Rapid Token Burn RateToken 消耗速率等指标都必须先确定工作负载的流量模式才能选择正确的动态阈值算法。流量模式判断取决于历史数据的有无分为两条路径Case 1没有历史指标数据例如 brand new agent——遵循本文对应的无历史流量数据处理文档Case 2存在历史指标数据例如有流量的活跃 Agent——遵循有历史流量数据处理文档。在实际执行链中触发无数据分支的典型场景有四种Agent 刚上线新部署的 Agent 尚无任何 OpenTelemetry 指标被采集。监控命名空间缺失在成本告警前置检查中通过 check_telemetry.py 的--query-monitoring-metadata参数查询 Token 使用指标的可用 namespace若没有返回与目标 Agent 匹配的 namespace即视为无历史数据。流量分析脚本明确判定为无流量analyze_traffic.py 在 14 天窗口4032 个 5 分钟数据点内若mean_last 0.0 and zero_ratio 1.0会输出New Agent / No Traffic档案此时必须回退到用户询问流程。历史数据不足脚本抛出ValueError数据点少于 4032 个即不足 14 天时同样回退到本文描述的用户询问流程参见有历史流量数据处理文档中的 Fallback 说明。注意skill 的核心前置条件要求 Agent 必须已接入 OpenTelemetry 指标采集Reliability/Cost/Safety/Security 告警依赖 OTel 指标流否则任何告警策略都没有数据源可评估Quality 告警则依赖 Vertex AI Online Monitors与本文的无数据分支相对独立。二、核心决策向用户询问预期的流量模式绝不基于名称或描述猜测在无历史数据的情况下技能明确禁止基于 Agent 的名称、描述或上下文去推断流量模式。原因很直接动态阈值算法的基线窗口1 小时、1 周与真实流量特征强耦合猜错模式会导致告警噪音或盲区。因此必须在回复中直接向用户提问例如What traffic/usage pattern do you expect for your agent?并显式呈现以下三个可定制选项及其算法映射选项中文含义映射的延迟告警算法数据预热要求Steady / Consistent平稳 / 一致Short-Window Z-Score Baseline1 小时回看窗口1 小时指标历史Bursty / Inconsistent突发 / 不稳定Moving Averages1 小时基线1 小时指标历史Seasonal / Cyclical季节性 / 周期性Seasonal Decomposition需要offset 1d与offset 1w1 周指标历史由1woffset 决定同时必须告知用户默认模式是 Steady / Consistent映射 Short-Window Z-Score Baseline若用户未指定将按该默认模式继续。这三种算法分别对应 reliability_alert_policies.md 中 Latency 的三个 PromQL 变体详见本文第五节其中 Short-Window Z-Score 专门为新 Agent、只需 1 小时历史即可快速激活而设计这也正是它被选为无数据场景默认值的原因。2.1 自动化 / 即时配置请求的处理不得阻塞等待如果用户的提示词要求立即配置或写入告警策略例如 Set up its alerting policies in monitoring/alerts.tf或者执行环境是自动化 / 非交互式脚本绝不能停下来等待用户答复。正确做法是在回复中提出上述模式问题明确说明由于尚未收到选择将按默认的 Steady/Consistent 模式部署立即生成并写入默认配置Steady / Consistent → Short-Window Z-Score。这与 SKILL.md 中Brand New Agents (No Traffic History)的 Critical Rules 一致即时设置请求下ask the question but proceed using the default Steady/Consistent (Short-Window Z-Score) pattern。2.2 无论选择哪种模式其他策略使用正确的数据类默认值流量模式只影响 Latency以及 Token 消耗这类跟随流量形态的指标。对于Error Rate错误率无论流量模式如何一律使用 Multi-Window Multi-Burn Rate SLO Alerting多窗口多燃尽率 SLO 告警或基于比率的静态阈值。其根因在 reliability_alert_policies.md 中写得很清楚错误率天然稀疏大量0若标准差为0Z-score 会因除零而数学上不稳定产生误报。三、算法预热期与 Seasonal 模式的盲区警告不同算法需要不同长度的历史数据这决定了新 Agent 上线后告警何时才能真正生效算法预热期说明Short-Window Z-Score / Moving Averages1 小时指标历史新 Agent 可在 1 小时后快速激活延迟告警SLO Burn RateError RateFast burn1h/5m 窗口在 1 小时后即可工作Slow burn 组件最多需要 3 天慢燃尽窗口为 3 天Seasonal Decomposition1 周历史受1woffset 约束见下方警告关键警告如果用户切换到 Seasonal Decomposition必须明确告知其将产生1 周盲区本周期的告警需要等到下一周期才能建立基线。建议用户在此期间先以Short-Window Z-Score或Static Thresholds静态阈值作为临时防线等积累满一周数据后再切换。这一预热期差异也解释了为什么无数据场景的默认算法是 Short-Window Z-Score它在三种动态算法中预热最快仅 1 小时能最大程度缩短新 Agent 的无告警保护时间窗口。四、用户沟通清单回复中必须传达的 7 个要点在回复开头必须清晰传达无历史数据的事实、可选项以及已执行的即时动作按以下顺序组织说明原因由于 Agent 没有历史数据无法自动分析其流量模式。直接提问询问用户预期的流量模式Steady / Consistent、Seasonal / Cyclical、Bursty / Inconsistent说明三种模式的映射差异以及选择 Seasonal 将带来 1 周盲区风险。声明默认值默认是Steady / ConsistentLatency 使用 Short-Window Z-Score 算法如果用户没有明确想法或不做选择将以此默认继续。确认已落地如果用户接受默认说明已部署 Steady/Consistent 默认配置以确保文件立即就绪但若后续偏好其他模式可随时请求更新。说明预热期Latency 需 1 小时SLO 最多需 3 天。交代其余映射Error Rate 使用 SLO Burn Rate。提供通俗解释用平实的英文/自然语言说明每个提议告警测量什么、底层算法如何工作、触发意味着什么对应 SKILL.md 的 Plain English Response 要求。另外SKILL.md 还强制要求若用户未提供通知渠道必须在最终回复中询问是否需要配置 notification channels不得擅自假设或擅自使用代码库中搜索到的渠道。五、源码纵深流量分类的统计依据与测试验证虽然无数据场景不运行analyze_traffic.py的分类逻辑因为无数据可分类但理解该脚本的统计指标有助于向用户解释三种模式的判别依据也为后续等数据积累后自动重分类提供可验证的迁移路径。5.1 核心统计量analyze_traffic.py脚本对 14 天4032 个 5 分钟点序列计算三个指标并执行决策树分类zero_ratio零值占比最近 7 天中速率 0.01的 5 分钟区间占比variance_ratio方差比stddev / mean衡量波动剧烈程度autocorr_1w1 周滞后自相关最近 7 天与前 7 天序列的协方差除以标准差乘积衡量周周期规律性。决策树逻辑与有历史流量数据处理文档中的决策映射表一致判定条件分类档案推荐算法mean_last 0.0 and zero_ratio 1.0New Agent / No TrafficShort-Window Z-Score1h 基线variance_ratio 2.0Bursty / InconsistentMoving Averagesautocorr_1w 0.75 and variance_ratio 2.0Seasonal / CyclicalSeasonal Decomposition1w 与 1d 均值其余Steady / Consistent1w Z-Score 基线5.2 测试用例印证analyze_traffic_test.pytest_classify_new_agent对全零的 4032 点序列断言档案为New Agent / No Traffic、算法为Short-Window Z-Score (1h baseline)——这正是回退到用户询问流程的代码级证据test_insufficient_data少于 4032 点会抛出ValueError对应文档中fallback to user inquiry的条件test_classify_steady/test_classify_bursty/test_classify_seasonal分别用 mock_traffic_data.py 中内置的STEADY_TRAFFIC、BURSTY_TRAFFIC、SEASONAL_TRAFFIC序列验证三档分类test_main_live_query_request_count模拟 14 天固定值序列经 live 查询后输出Steady / Consistenttest_main_live_query_token_usage以高峰 1000 与低谷 1.0 交替的序列验证 Token 指标分类为Bursty / Inconsistent。这些测试同时揭示了 live 模式支持的两种指标及其分组标签见_SUPPORTED_METRIC_TYPE_LABELLatency 使用workload.googleapis.com/gen_ai.invoke_agent.duration按metric.labels.gen_ai_agent_name分组Token 使用workload.googleapis.com/gen_ai.client.token.usage按resource.labels.namespace分组。六、默认策略的落地实现PromQL 与 Terraform无数据场景下生成的默认配置Steady / Consistent → Short-Window Z-Score其查询与资源模板在 reliability_alert_policies.md 中有完整定义。以下展示核心内容均假设monitored_resourcegeneric_node并按 SKILL.md 的规则按gen_ai_agent_name动态分组、不硬编码单个 Agent 名。6.1 Short-Window Z-ScoreLatency无数据场景默认比较 1 分钟 P95 延迟与 1 小时基线Z-Score 3 触发abs( histogram_quantile(0.95, sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_bucket{monitored_resourcegeneric_node}[1m])) by (le, gen_ai_agent_name)) - histogram_quantile(0.95, sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_bucket{monitored_resourcegeneric_node}[1h])) by (le, gen_ai_agent_name)) ) / stddev_over_time( (histogram_quantile(0.95, sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_bucket{monitored_resourcegeneric_node}[1m])) by (le, gen_ai_agent_name)))[1h:1m] ) 3其中stddev_over_time(...[1h:1m])子查询用于计算1 分钟延迟在 1 小时内的标准差。对应 Terraform 资源模板{latency_algorithm_name_short}等占位符替换为short_window_zscore/Short-Window Z-Score/Z-Score 3resource google_monitoring_alert_policy latency_{latency_algorithm_name_short} { project var.project_id display_name Agent Reliability - Latency {latency_algorithm_name_long} combiner OR conditions { display_name Latency {latency_algorithm_condition_description} condition_prometheus_query_language { query EOT {latency_telemetry_query} EOT } } documentation { content High latency detected for the agent. mime_type text/markdown subject Agent Reliability - Latency {latency_algorithm_name_long} on $${metric.label.gen_ai_agent_name} } user_labels { created-with-google-skill agent-platform-alert-configuration } }6.2 其余两种选项的 PromQL供用户后续切换Moving AveragesBursty / Inconsistent5 分钟 P95 超过 1 小时平均的 1.5 倍histogram_quantile(0.95, sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_bucket{monitored_resourcegeneric_node}[5m])) by (le, gen_ai_agent_name)) 1.5 * histogram_quantile(0.95, sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_bucket{monitored_resourcegeneric_node}[1h])) by (le, gen_ai_agent_name))Seasonal DecompositionSeasonal / Cyclical5 分钟 P95 与1 天前 1 周前均值之比 2。注意两条铁律分子当前延迟不得带任何 offsetoffset 1d/offset 1w只能加在分母构建历史基线并且只追踪尖峰避免用abs()双向追踪导致一周后基线漂移引发二次误报histogram_quantile(0.95, sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_bucket{monitored_resourcegeneric_node}[5m])) by (le, gen_ai_agent_name)) / ( ( histogram_quantile(0.95, sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_bucket{monitored_resourcegeneric_node}[5m] offset 1d)) by (le, gen_ai_agent_name)) histogram_quantile(0.95, sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_bucket{monitored_resourcegeneric_node}[5m] offset 1w)) by (le, gen_ai_agent_name)) ) / 2 ) 26.3 Error RateMulti-Window Multi-Burn Rate SLO无数据场景同样适用Fast Burn SLO1h / 5m 双窗口PromQL 示例${var.slo_target}为 Terraform 变量必须使用${var.xxx}语法而非裸引用否则部署期报错( sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_count{monitored_resourcegeneric_node,error_type!}[5m])) by (gen_ai_agent_name) / sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_count{monitored_resourcegeneric_node}[5m])) by (gen_ai_agent_name) (1 - ${var.slo_target}) * 14.4 ) and ( sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_count{monitored_resourcegeneric_node,error_type!}[1h])) by (gen_ai_agent_name) / sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_count{monitored_resourcegeneric_node}[1h])) by (gen_ai_agent_name) (1 - ${var.slo_target}) * 14.4 )其 Terraform 模板Fast Burn使用condition_prometheus_query_language并设置duration 300s5 分钟缓冲用于过滤冷启动 / 部署抖动对于查询超过 25 小时数据的慢燃尽 SLO 则必须省略 duration因为平台对长回看窗口禁用 retest 窗口。6.4 时长缓冲Duration Buffer规则短回看窗口告警 25 小时数据如 Short-Window Z-Score、Moving Averages、Fast Burn SLO必须设置duration 300s5 分钟缓冲过滤瞬时尖峰长回看窗口告警 25 小时数据如 Long-Window Z-Score、Seasonal Decomposition、Slow Burn SLO平台禁用 duration/retest 窗口不得设置 duration。七、动态基线的已知盲区与工程提醒在向用户解释告警含义时用户沟通第 7 点值得一并说明两个源自参考文档的工程事实慢漂移盲区动态统计 Z-score 阈值把当前速率与滚动统计基线比较。若系统在数天内缓慢劣化基线曲线会随之适应这种慢漂移使标准 Z-score 告警对持续缓慢错误失明。建议并行配置硬静态阈值告警以严格执行 SLA。稀疏流量提示即使数据积累后分类为 Steady / Consistent若zero_ratio 0.95Z-score 告警可能不稳定此时应建议改用 Short-Window Z-Score 或 Static Thresholds 而非 Long-Window Z-Score。八、相关参考文档导航本文场景在整个技能工作流中的位置与相邻文档如下均位于skills/cloud/agent-platform-alert-configuration/目录技能总览与执行协议SKILL.md安全分级、前置脚本、输出格式、去重与 lint 校验本文主文档references/no_historical_traffic_data.md有数据分支分类映射表与决策树references/has_historical_traffic_data.md各告警类型的策略规格ReliabilityLatency / SLO / SQL 查询references/reliability_alert_policies.md、CostRapid Token Burn Ratereferences/cost_alert_policies.md、Quality / Safety / Security 告警同目录下对应文件工具脚本流量分类器 scripts/analyze_traffic.py 及其测试 scripts/analyze_traffic_test.py、测试数据 scripts/mock_traffic_data.py、遥测检查 scripts/check_telemetry.py、配置语法校验 scripts/lint_syntax.py、重复策略扫描 scripts/scan_duplicates.py实操前置运行本技能的任何 Python 脚本前先执行pip install -r scripts/requirements.txt依赖见 scripts/requirements.txt包含google-cloud-monitoring2.31.0、google-cloud-aiplatform1.160.0等live 查询若报CredentialsMissingError退出码 1需在终端执行gcloud auth application-default login完成本地认证。总结无历史流量数据并非无法配置告警而是要把决策权交还用户显式询问预期模式、以 Steady/ConsistentShort-Window Z-Score为默认立即落地、如实沟通各算法的预热期与 Seasonal 的 1 周盲区并保证 Error Rate 始终使用 SLO Burn Rate 这类与流量形态解耦的稳健算法。这样既能让全新 Agent 在 1 小时预热后获得延迟保护也为数据积累后的自动重分类保留了清晰的迁移路径。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 无历史流量数据场景下的 Agent 告警配置：agent-platform-alert-configuration 的流量模式决策与默认策略指南
无历史流量数据场景下的 Agent 告警配置agent-platform-alert-configuration 的流量模式决策与默认策略指南【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills本文聚焦 agent-platform-alert-configuration 技能在目标 Agent 没有任何历史监控数据例如全新上线的 Agent时的告警配置方法论。当无法用数据分析流量模式时正确的做法是显式向用户询问预期的流量特征并在自动化/即时配置场景下以 Steady/ConsistentShort-Window Z-Score作为默认策略先行落地同时处理 Error Rate 的 SLO 预热期与 Seasonal 模式的 1 周盲区风险。读完本文你将掌握无数据场景下的模式选项与映射关系、各算法的数据预热要求、默认配置的生成规则以及对应的 PromQL 与 Terraform 实现细节。一、场景定位什么情况下会走进无历史流量数据分支在 agent-platform-alert-configuration 的可靠性Reliability与成本Cost告警配置流程中Latency延迟与 Rapid Token Burn RateToken 消耗速率等指标都必须先确定工作负载的流量模式才能选择正确的动态阈值算法。流量模式判断取决于历史数据的有无分为两条路径Case 1没有历史指标数据例如 brand new agent——遵循本文对应的无历史流量数据处理文档Case 2存在历史指标数据例如有流量的活跃 Agent——遵循有历史流量数据处理文档。在实际执行链中触发无数据分支的典型场景有四种Agent 刚上线新部署的 Agent 尚无任何 OpenTelemetry 指标被采集。监控命名空间缺失在成本告警前置检查中通过 check_telemetry.py 的--query-monitoring-metadata参数查询 Token 使用指标的可用 namespace若没有返回与目标 Agent 匹配的 namespace即视为无历史数据。流量分析脚本明确判定为无流量analyze_traffic.py 在 14 天窗口4032 个 5 分钟数据点内若mean_last 0.0 and zero_ratio 1.0会输出New Agent / No Traffic档案此时必须回退到用户询问流程。历史数据不足脚本抛出ValueError数据点少于 4032 个即不足 14 天时同样回退到本文描述的用户询问流程参见有历史流量数据处理文档中的 Fallback 说明。注意skill 的核心前置条件要求 Agent 必须已接入 OpenTelemetry 指标采集Reliability/Cost/Safety/Security 告警依赖 OTel 指标流否则任何告警策略都没有数据源可评估Quality 告警则依赖 Vertex AI Online Monitors与本文的无数据分支相对独立。二、核心决策向用户询问预期的流量模式绝不基于名称或描述猜测在无历史数据的情况下技能明确禁止基于 Agent 的名称、描述或上下文去推断流量模式。原因很直接动态阈值算法的基线窗口1 小时、1 周与真实流量特征强耦合猜错模式会导致告警噪音或盲区。因此必须在回复中直接向用户提问例如What traffic/usage pattern do you expect for your agent?并显式呈现以下三个可定制选项及其算法映射选项中文含义映射的延迟告警算法数据预热要求Steady / Consistent平稳 / 一致Short-Window Z-Score Baseline1 小时回看窗口1 小时指标历史Bursty / Inconsistent突发 / 不稳定Moving Averages1 小时基线1 小时指标历史Seasonal / Cyclical季节性 / 周期性Seasonal Decomposition需要offset 1d与offset 1w1 周指标历史由1woffset 决定同时必须告知用户默认模式是 Steady / Consistent映射 Short-Window Z-Score Baseline若用户未指定将按该默认模式继续。这三种算法分别对应 reliability_alert_policies.md 中 Latency 的三个 PromQL 变体详见本文第五节其中 Short-Window Z-Score 专门为新 Agent、只需 1 小时历史即可快速激活而设计这也正是它被选为无数据场景默认值的原因。2.1 自动化 / 即时配置请求的处理不得阻塞等待如果用户的提示词要求立即配置或写入告警策略例如 Set up its alerting policies in monitoring/alerts.tf或者执行环境是自动化 / 非交互式脚本绝不能停下来等待用户答复。正确做法是在回复中提出上述模式问题明确说明由于尚未收到选择将按默认的 Steady/Consistent 模式部署立即生成并写入默认配置Steady / Consistent → Short-Window Z-Score。这与 SKILL.md 中Brand New Agents (No Traffic History)的 Critical Rules 一致即时设置请求下ask the question but proceed using the default Steady/Consistent (Short-Window Z-Score) pattern。2.2 无论选择哪种模式其他策略使用正确的数据类默认值流量模式只影响 Latency以及 Token 消耗这类跟随流量形态的指标。对于Error Rate错误率无论流量模式如何一律使用 Multi-Window Multi-Burn Rate SLO Alerting多窗口多燃尽率 SLO 告警或基于比率的静态阈值。其根因在 reliability_alert_policies.md 中写得很清楚错误率天然稀疏大量0若标准差为0Z-score 会因除零而数学上不稳定产生误报。三、算法预热期与 Seasonal 模式的盲区警告不同算法需要不同长度的历史数据这决定了新 Agent 上线后告警何时才能真正生效算法预热期说明Short-Window Z-Score / Moving Averages1 小时指标历史新 Agent 可在 1 小时后快速激活延迟告警SLO Burn RateError RateFast burn1h/5m 窗口在 1 小时后即可工作Slow burn 组件最多需要 3 天慢燃尽窗口为 3 天Seasonal Decomposition1 周历史受1woffset 约束见下方警告关键警告如果用户切换到 Seasonal Decomposition必须明确告知其将产生1 周盲区本周期的告警需要等到下一周期才能建立基线。建议用户在此期间先以Short-Window Z-Score或Static Thresholds静态阈值作为临时防线等积累满一周数据后再切换。这一预热期差异也解释了为什么无数据场景的默认算法是 Short-Window Z-Score它在三种动态算法中预热最快仅 1 小时能最大程度缩短新 Agent 的无告警保护时间窗口。四、用户沟通清单回复中必须传达的 7 个要点在回复开头必须清晰传达无历史数据的事实、可选项以及已执行的即时动作按以下顺序组织说明原因由于 Agent 没有历史数据无法自动分析其流量模式。直接提问询问用户预期的流量模式Steady / Consistent、Seasonal / Cyclical、Bursty / Inconsistent说明三种模式的映射差异以及选择 Seasonal 将带来 1 周盲区风险。声明默认值默认是Steady / ConsistentLatency 使用 Short-Window Z-Score 算法如果用户没有明确想法或不做选择将以此默认继续。确认已落地如果用户接受默认说明已部署 Steady/Consistent 默认配置以确保文件立即就绪但若后续偏好其他模式可随时请求更新。说明预热期Latency 需 1 小时SLO 最多需 3 天。交代其余映射Error Rate 使用 SLO Burn Rate。提供通俗解释用平实的英文/自然语言说明每个提议告警测量什么、底层算法如何工作、触发意味着什么对应 SKILL.md 的 Plain English Response 要求。另外SKILL.md 还强制要求若用户未提供通知渠道必须在最终回复中询问是否需要配置 notification channels不得擅自假设或擅自使用代码库中搜索到的渠道。五、源码纵深流量分类的统计依据与测试验证虽然无数据场景不运行analyze_traffic.py的分类逻辑因为无数据可分类但理解该脚本的统计指标有助于向用户解释三种模式的判别依据也为后续等数据积累后自动重分类提供可验证的迁移路径。5.1 核心统计量analyze_traffic.py脚本对 14 天4032 个 5 分钟点序列计算三个指标并执行决策树分类zero_ratio零值占比最近 7 天中速率 0.01的 5 分钟区间占比variance_ratio方差比stddev / mean衡量波动剧烈程度autocorr_1w1 周滞后自相关最近 7 天与前 7 天序列的协方差除以标准差乘积衡量周周期规律性。决策树逻辑与有历史流量数据处理文档中的决策映射表一致判定条件分类档案推荐算法mean_last 0.0 and zero_ratio 1.0New Agent / No TrafficShort-Window Z-Score1h 基线variance_ratio 2.0Bursty / InconsistentMoving Averagesautocorr_1w 0.75 and variance_ratio 2.0Seasonal / CyclicalSeasonal Decomposition1w 与 1d 均值其余Steady / Consistent1w Z-Score 基线5.2 测试用例印证analyze_traffic_test.pytest_classify_new_agent对全零的 4032 点序列断言档案为New Agent / No Traffic、算法为Short-Window Z-Score (1h baseline)——这正是回退到用户询问流程的代码级证据test_insufficient_data少于 4032 点会抛出ValueError对应文档中fallback to user inquiry的条件test_classify_steady/test_classify_bursty/test_classify_seasonal分别用 mock_traffic_data.py 中内置的STEADY_TRAFFIC、BURSTY_TRAFFIC、SEASONAL_TRAFFIC序列验证三档分类test_main_live_query_request_count模拟 14 天固定值序列经 live 查询后输出Steady / Consistenttest_main_live_query_token_usage以高峰 1000 与低谷 1.0 交替的序列验证 Token 指标分类为Bursty / Inconsistent。这些测试同时揭示了 live 模式支持的两种指标及其分组标签见_SUPPORTED_METRIC_TYPE_LABELLatency 使用workload.googleapis.com/gen_ai.invoke_agent.duration按metric.labels.gen_ai_agent_name分组Token 使用workload.googleapis.com/gen_ai.client.token.usage按resource.labels.namespace分组。六、默认策略的落地实现PromQL 与 Terraform无数据场景下生成的默认配置Steady / Consistent → Short-Window Z-Score其查询与资源模板在 reliability_alert_policies.md 中有完整定义。以下展示核心内容均假设monitored_resourcegeneric_node并按 SKILL.md 的规则按gen_ai_agent_name动态分组、不硬编码单个 Agent 名。6.1 Short-Window Z-ScoreLatency无数据场景默认比较 1 分钟 P95 延迟与 1 小时基线Z-Score 3 触发abs( histogram_quantile(0.95, sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_bucket{monitored_resourcegeneric_node}[1m])) by (le, gen_ai_agent_name)) - histogram_quantile(0.95, sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_bucket{monitored_resourcegeneric_node}[1h])) by (le, gen_ai_agent_name)) ) / stddev_over_time( (histogram_quantile(0.95, sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_bucket{monitored_resourcegeneric_node}[1m])) by (le, gen_ai_agent_name)))[1h:1m] ) 3其中stddev_over_time(...[1h:1m])子查询用于计算1 分钟延迟在 1 小时内的标准差。对应 Terraform 资源模板{latency_algorithm_name_short}等占位符替换为short_window_zscore/Short-Window Z-Score/Z-Score 3resource google_monitoring_alert_policy latency_{latency_algorithm_name_short} { project var.project_id display_name Agent Reliability - Latency {latency_algorithm_name_long} combiner OR conditions { display_name Latency {latency_algorithm_condition_description} condition_prometheus_query_language { query EOT {latency_telemetry_query} EOT } } documentation { content High latency detected for the agent. mime_type text/markdown subject Agent Reliability - Latency {latency_algorithm_name_long} on $${metric.label.gen_ai_agent_name} } user_labels { created-with-google-skill agent-platform-alert-configuration } }6.2 其余两种选项的 PromQL供用户后续切换Moving AveragesBursty / Inconsistent5 分钟 P95 超过 1 小时平均的 1.5 倍histogram_quantile(0.95, sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_bucket{monitored_resourcegeneric_node}[5m])) by (le, gen_ai_agent_name)) 1.5 * histogram_quantile(0.95, sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_bucket{monitored_resourcegeneric_node}[1h])) by (le, gen_ai_agent_name))Seasonal DecompositionSeasonal / Cyclical5 分钟 P95 与1 天前 1 周前均值之比 2。注意两条铁律分子当前延迟不得带任何 offsetoffset 1d/offset 1w只能加在分母构建历史基线并且只追踪尖峰避免用abs()双向追踪导致一周后基线漂移引发二次误报histogram_quantile(0.95, sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_bucket{monitored_resourcegeneric_node}[5m])) by (le, gen_ai_agent_name)) / ( ( histogram_quantile(0.95, sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_bucket{monitored_resourcegeneric_node}[5m] offset 1d)) by (le, gen_ai_agent_name)) histogram_quantile(0.95, sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_bucket{monitored_resourcegeneric_node}[5m] offset 1w)) by (le, gen_ai_agent_name)) ) / 2 ) 26.3 Error RateMulti-Window Multi-Burn Rate SLO无数据场景同样适用Fast Burn SLO1h / 5m 双窗口PromQL 示例${var.slo_target}为 Terraform 变量必须使用${var.xxx}语法而非裸引用否则部署期报错( sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_count{monitored_resourcegeneric_node,error_type!}[5m])) by (gen_ai_agent_name) / sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_count{monitored_resourcegeneric_node}[5m])) by (gen_ai_agent_name) (1 - ${var.slo_target}) * 14.4 ) and ( sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_count{monitored_resourcegeneric_node,error_type!}[1h])) by (gen_ai_agent_name) / sum(rate(workload_googleapis_com:gen_ai_invoke_agent_duration_count{monitored_resourcegeneric_node}[1h])) by (gen_ai_agent_name) (1 - ${var.slo_target}) * 14.4 )其 Terraform 模板Fast Burn使用condition_prometheus_query_language并设置duration 300s5 分钟缓冲用于过滤冷启动 / 部署抖动对于查询超过 25 小时数据的慢燃尽 SLO 则必须省略 duration因为平台对长回看窗口禁用 retest 窗口。6.4 时长缓冲Duration Buffer规则短回看窗口告警 25 小时数据如 Short-Window Z-Score、Moving Averages、Fast Burn SLO必须设置duration 300s5 分钟缓冲过滤瞬时尖峰长回看窗口告警 25 小时数据如 Long-Window Z-Score、Seasonal Decomposition、Slow Burn SLO平台禁用 duration/retest 窗口不得设置 duration。七、动态基线的已知盲区与工程提醒在向用户解释告警含义时用户沟通第 7 点值得一并说明两个源自参考文档的工程事实慢漂移盲区动态统计 Z-score 阈值把当前速率与滚动统计基线比较。若系统在数天内缓慢劣化基线曲线会随之适应这种慢漂移使标准 Z-score 告警对持续缓慢错误失明。建议并行配置硬静态阈值告警以严格执行 SLA。稀疏流量提示即使数据积累后分类为 Steady / Consistent若zero_ratio 0.95Z-score 告警可能不稳定此时应建议改用 Short-Window Z-Score 或 Static Thresholds 而非 Long-Window Z-Score。八、相关参考文档导航本文场景在整个技能工作流中的位置与相邻文档如下均位于skills/cloud/agent-platform-alert-configuration/目录技能总览与执行协议SKILL.md安全分级、前置脚本、输出格式、去重与 lint 校验本文主文档references/no_historical_traffic_data.md有数据分支分类映射表与决策树references/has_historical_traffic_data.md各告警类型的策略规格ReliabilityLatency / SLO / SQL 查询references/reliability_alert_policies.md、CostRapid Token Burn Ratereferences/cost_alert_policies.md、Quality / Safety / Security 告警同目录下对应文件工具脚本流量分类器 scripts/analyze_traffic.py 及其测试 scripts/analyze_traffic_test.py、测试数据 scripts/mock_traffic_data.py、遥测检查 scripts/check_telemetry.py、配置语法校验 scripts/lint_syntax.py、重复策略扫描 scripts/scan_duplicates.py实操前置运行本技能的任何 Python 脚本前先执行pip install -r scripts/requirements.txt依赖见 scripts/requirements.txt包含google-cloud-monitoring2.31.0、google-cloud-aiplatform1.160.0等live 查询若报CredentialsMissingError退出码 1需在终端执行gcloud auth application-default login完成本地认证。总结无历史流量数据并非无法配置告警而是要把决策权交还用户显式询问预期模式、以 Steady/ConsistentShort-Window Z-Score为默认立即落地、如实沟通各算法的预热期与 Seasonal 的 1 周盲区并保证 Error Rate 始终使用 SLO Burn Rate 这类与流量形态解耦的稳健算法。这样既能让全新 Agent 在 1 小时预热后获得延迟保护也为数据积累后的自动重分类保留了清晰的迁移路径。【免费下载链接】skillsAgent Skills for Google products and technologies项目地址: https://gitcode.com/GitHub_Trending/skills29/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考