From f173c402dad096f12b8fb5a2c765d872e47f562f Mon Sep 17 00:00:00 2001 From: xmz7891 Date: Thu, 8 Oct 2026 22:53:44 +0800 Subject: [PATCH] remove temp --- _build/_cmsg_monitor_v2.txt | 44 ------------------------------------- 1 file changed, 44 deletions(-) delete mode 100644 _build/_cmsg_monitor_v2.txt diff --git a/_build/_cmsg_monitor_v2.txt b/_build/_cmsg_monitor_v2.txt deleted file mode 100644 index 09e5eed..0000000 --- a/_build/_cmsg_monitor_v2.txt +++ /dev/null @@ -1,44 +0,0 @@ -监测单元和预案重写成"分层"版（来源改为本地整份文件） - -== 为什么重写 == - -certbot 签证书时加了 http -> https 的 301，而监测单元原来判断 -"curl 拿到 200 才算健康"、且 curl **默认不跟跳转** -> 拿到 301 --> 判成"网站挂了" -> 又要启动预案 -> 重启中转 -> 再查还是 301。 -这是**第二次**踩同一类坑了（上一次是改监听地址忘了改探测地址）。 - -共同教训：**改了入口的行为，必须回头看所有探测入口的地方。** - -== 新设计：分两层探测 == - - PRIMARY https://yk.xxmxxs.top/v1/health 用户实际走的路 - FALLBACK http://127.0.0.1:13245/v1/health 中转本身 - -两个都查才能分清哪一层坏了，进而选对抢救动作： - - PRIMARY 挂 + FALLBACK 好 -> edge 层（CF / DNS / nginx） - 两个都挂 -> core 层（中转服务本身） - -预案据此走不同的阶梯： - - edge: 重载 nginx -> 重启 nginx -> 查 443 与证书 - core: 重启中转 -> 强杀重拉 -> 中转+nginx 都重启 - -不区分层次的话只能瞎重启，而 edge 层的问题重启中转一万次也没用。 - -== 做法上的改进：不再远端打补丁 == - -前几轮一直是"SSH 过去用嵌套 heredoc 现场改 monitor.sh"， -连续踩三次：PowerShell 在本机求值 \、引号被吃、 -脚本里的 %{http_code} 和 Python 的 %% 格式化打架。 - -现在改成：relay/monitor-lightsail.sh 和 relay/rescue-lightsail.sh -是**唯一事实来源**，本地编辑 -> 整份上传 -> 重装， -改了什么一目了然，也能进 git。 - -== 顺带 == - -因为 Lightsail 防火墙还没放行 443，PRIMARY 一直是 000， -监测会把 fails 一直加上去、白生成抢救报告。 -所以暂时把 monitor.timer 停掉，等 443 开了再启用 -（脚本 _build/pause_monitor.py，恢复是一条 systemctl start）。