阿拉丁可观测性工坊

部署之后，可观测性在哪里

用 aladin-cicd-forge 把服务部署上线只是第一步。接下来常见的局面是：服务在跑，但没有任何人在看指标。Prometheus 没配规则，Alertmanager 路由是空的，Grafana 看板停留在默认模板，README 里写的 SLO 从来没人算过。故障发现全靠用户投诉，排查时没有历史指标可看，没有错误预算可对照。

skillhub 上能找到的监控类工具大多是单点方案：要么只生成一段 Prometheus 规则，要么只给一个 Grafana 面板 JSON，没人把「指标采集 → 告警规则 → 通知路由 → 看板 → SLO → 运维手册」整条链路串起来。结果是每换一种监控需求，就得手动拼凑一堆互不关联的配置文件。

从服务清单到监控配置

aladin-observability-forge 的做法是：你给一个仓库路径，或者一份描述服务名、语言、端口、SLO 的 services.json，它自动扫描框架文件、端口、/metrics 和 /health 端点，推断服务画像，然后一次性产出：

• rules.yml：Prometheus recording rules（请求率、错误率、延迟分位）和多维 alerting 规则（可用性、错误率、延迟 P99、资源饱和度），阈值由 SLO 错误预算反推而非拍脑袋设定
• alertmanager.yml：完整的路由树、抑制规则、分组策略和值班接收人骨架（webhook/email 占位符）
• dashboard.json：概览、服务详情、RED 方法、SLO 四类面板，可直接 import 到 Grafana
• slo.yml：SLI 定义、目标值、错误预算，以及多窗口多燃烧率（MWMBR）告警，区分快烧和慢烧
• runbook.md：每个告警对应的处置流程和值班表

提交前，脚本会在本地做 dry-run 校验：YAML/JSON 语法、阈值合理性、SLO 目标合法性（∈(0,1]）、规则命名规范。整个工具链只用 Python 标准库，不联网，不依赖任何第三方包。

适用边界与注意点

这个技能只产配置，不执行部署。它不连接真实的 Prometheus 或 Grafana 集群，不拉取实时指标，也不发起任何网络请求。生成的配置需要你手动提交并由平台加载后才能生效。

它不替代 SRE 层面的架构决策，比如容量规划、多区域容灾、服务网格选型，也不适配单一云厂商的专有监控 PaaS。日志检索和链路追踪平台（如 ELK、Loki、Jaeger）的部署不在范围内，但会给出结构化日志字段和 trace 埋点的规范建议。

Alertmanager 配置中的接收人是占位符，接入真实值班通道前需要替换。建议提交前用 git diff 审一遍生成结果，确认没有遗漏或误配。