真实失败率需用Nginx日志+Prometheus抓取，依据$request_time、$upstream_response_time、$upstream_http_content_type等字段统计5xx及异常200/499，并通过rate()计算5分钟错误率，排除上游伪故障，结合Grafana分层监控耗时。
用 Nginx 日志 + Prometheus 抓真实失败率，别信 curl -I
镜像站的失败率不能靠 curl -I 或 composer diag 算——它们只测连通性，不反映真实请求路径（如 /p2/monolog/monolog.json）是否返回有效 JSON。Nginx 日志里的 $status 和 $upstream_status 才是真相来源。
- 必须开启
log_format记录$upstream_cache_status（区分缓存命中/回源）、$upstream_http_x_ratelimit_remaining（限流余量）、$request_time（服务端处理耗时） - 失败判定不能只看
5xx：200但Content-Type: text/html、或响应体是 Nginx 默认错误页，也得算失败——用nginx-module-vts配合自定义 log_format 提取$upstream_http_content_type - Prometheus 拉取时，用
nginx-exporter（不是node-exporter），它能解析 vts 的 JSON 输出，把nginx_vts_server_request_seconds_count{code="200"}和{code="502"}分开统计
rate(nginx_vts_server_request_seconds_count{code=~"5.."}[5m]) / rate(nginx_vts_server_request_seconds_count[5m]) 是核心告警指标
这个 PromQL 表达式算的是 5 分钟内 HTTP 5xx 错误率，不是绝对次数。为什么必须用 rate()？因为镜像站会偶发上游抖动（比如 packagist.org 返回 503），直接数 count 会狂告警。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 阈值设为
> 0.05（5%）比固定次数更合理：流量低谷期 1 个 502 就占 100%，高峰期 50 个才 5% - 要排除已知伪故障：在 PromQL 里加
unless on() (probe_http_status_code{job="upstream-packagist"} == 503)，避免上游临时不可用触发误报 - 别漏掉
499（客户端主动断连）：有些 CI 工具超时后直接 kill curl，Nginx 记为 499，它和 5xx 同属“请求未完成”，应纳入失败率分母
耗时监控必须拆解 $request_time 和 $upstream_response_time
$request_time 是整个请求生命周期（含 SSL 握手、读 body、写响应），而 $upstream_response_time 才是镜像服务端真实处理时间。两者差值大，说明瓶颈在 Nginx 层（比如 gzip 压缩慢、SSL 卸载卡住）；接近则问题在 PHP-FPM 或 Redis 缓存层。
- 对
/packages.json这类高频请求，$upstream_response_time > 1s就该查 PHP-FPM active processes 是否打满 - 对
/dist/xxx.zip下载请求，$request_time高但$upstream_response_time低，说明是带宽或 CDN 节点问题，不是镜像服务本身 - Grafana 看板里必须并列画两条线：
histogram_quantile(0.95, rate(nginx_vts_server_request_seconds_bucket[5m]))（P95 总耗时）和histogram_quantile(0.95, rate(nginx_vts_upstream_response_seconds_bucket[5m]))（P95 后端耗时）
定时探测脚本要模拟真实 Composer 请求路径
别用 curl https://mirrors.aliyun.com/composer/ 测首页——Composer 根本不访问它。真正关键路径是 /p2/{vendor}/{package}.json 和 /packages.json，这些请求带 Accept: application/json 头，且需校验 JSON 结构。
- 一条命令就能验证：
curl -s -f -m 10 -H "Accept: application/json" https://mirrors.tuna.tsinghua.edu.cn/composer/p2/laravel/framework.json | jq -e '.name' > /dev/null - 失败退出码不光来自 HTTP 状态：jq 解析失败（空响应、HTML 内容）、curl 超时、SSL handshake failed 都得捕获
- 并发探测多个镜像时，必须加
timeout 10s，否则一个卡死拖垮整轮轮询；结果写入统一格式 JSON 文件（含 timestamp、url、status、jq_exit_code、curl_time_total），供后续聚合
touch 更新 last_check 时间，会掩盖实际失败发生时刻；所有日志行首必须带 HEAL: 或 PROBE: 前缀，方便 Filebeat 按标签分流进 ELK 归因。 
