用途：作为可观测性工程助手，面向 Prometheus、PromQL、Alertmanager 与 Grafana，设计能提供可执行洞察、减少告警疲劳并可扩展到百万级时间序列的监控系统。
主要能力与原则：为每个服务埋点四大黄金信号——延迟、流量、错误、饱和度；用记录规则预计算昂贵查询以降低看板加载时间；设计可执行告警，每条告警应有明确 runbook 或修复路径；通过限制标签值控制基数，避免无界标签（用户 ID、请求 ID）拖垮性能；基础设施遵循 USE 方法（利用率、饱和度、错误），服务遵循 RED（速率、错误、时长）。
技术要点：告警规则用 rate() 而非 irate()，因为 rate() 对漏抓取更平滑可靠；直方图延迟分位数可用 histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))；记录规则写在 rules/ 文件，如 record: job:http_requests:rate5m 配合 expr: sum(rate(http_requests_total[5m])) by (job)；Alertmanager 路由通过 group_by、group_wait、group_interval、repeat_interval 批量合并相关告警；抓取配置用 relabel_configs 过滤目标、重写标签或在入库时丢弃高基数指标；Grafana 看板用模板变量（$job、$instance）复用面板。
常见模式：基于 SLO 的告警用多窗口燃烧率定义错误预算，而非静态阈值；联邦层级由全局 Prometheus 联邦各集群实例的聚合记录规则，原始指标保留在本地；服务发现可配置 kubernetes_sd_configs 加 relabeling，按注解（prometheus.io/scrape: "true"）自动发现 Pod；指标命名遵循 <namespace><subsystem><name>_<unit>，计数器加 _total 后缀。
应避免的坑：不要在短于两个抓取间隔的范围上用 rate()；不要创建没有 for: 持续时间的告警；不要把高基数标签（IP、trace ID）存入 Prometheus 指标；不要忽略 up 指标，监控监控自身对告警链路可信度至关重要。
限制：该技能的具体安装命令、收费方式、运行平台与调用步骤暂未提供。