https://blog.margrop.net/tag/%E7%9B%91%E6%8E%A7/ Recent content in 监控 on 魔都水滴 Hugo -- gohugo.io zh-CN Sun, 24 May 2026 08:10:00 +0800 https://blog.margrop.net/post/codex-reset-radar-quota-reset-guide/ Sun, 24 May 2026 08:10:00 +0800 https://blog.margrop.net/post/codex-reset-radar-quota-reset-guide/ <blockquote> <p><strong>先说结论</strong></p> <p>最近 Codex 的额度重置变得比以前更值得关注：有时是常规周期，有时是服务故障后的补偿性重置，有时是限额消耗异常后的官方修复。对重度 Codex 用户来说，真正尴尬的不是“额度被重置”，而是“我明明还剩不少周额度，却在重置前没有及时用掉”。</p> <p><code>Codex 重置雷达</code> 做的事情很简单：把官方状态页、官方/社区公开动态、历史重置窗口和当前预测信号聚合起来，判断是否出现“即将或正在重置”的窗口。它不是魔法预测器，也不是 OpenAI 官方服务；它更像一个面向 Codex 用户的早期预警看板：当信号足够强时，提醒你赶紧把当前周期剩余的 Codex 周额度用在真正需要的任务上。</p> </blockquote> <p>本文只讨论公开信息、公开网页和公开状态信号，不包含任何私有账号、Token、真实业务系统、内网地址或个人使用数据。文中提到的“额度”“重置”“速蹬窗口”都是面向普通 Codex 用户的体验分析，不构成对 OpenAI 官方计费、订阅或服务策略的承诺。</p> https://blog.margrop.net/post/proxmoxve-lvm-link-speed-uptime-kuma/ Tue, 05 May 2026 17:20:00 +0800 https://blog.margrop.net/post/proxmoxve-lvm-link-speed-uptime-kuma/ <blockquote> <p><strong>先说结论</strong></p> <p>ProxmoxVE 的 <code>local-lvm</code> 不是一个普通挂载目录，很多时候不能靠 <code>df -h</code> 发现它快满了；网口协商速率也不会因为服务还在线就自动暴露出来。最稳的办法是把这两个“容易被忽略但一出事就很麻烦”的指标接入现有 Uptime Kuma：<code>local-lvm</code> 用 HTTP 拉取监控，网口速率用 Push 主动上报。这样磁盘池接近阈值、网线或交换机端口掉到百兆时，统一在 Uptime Kuma 页面和通知链路里告警。</p> </blockquote> <p>本文会从需求背景、原始方案的问题核查、改进后的脚本、systemd 服务、Uptime Kuma 配置、验证方法和安全边界讲完整。文中所有地址、token、主机名都使用占位符，不出现真实内网信息。你可以把示例里的 <code>&lt;PVE_HOST&gt;</code>、<code>&lt;KUMA_URL&gt;</code>、<code>&lt;PUSH_TOKEN&gt;</code>、<code>&lt;INTERFACE&gt;</code> 替换成自己的环境值。</p>