前言
国内很多商品期货、部分金融期货都有夜盘：晚上九点到凌晨一两点仍在交易，而交易员已经下班。所谓无人值守，就是策略进程在服务器上继续跑，没有人盯着屏幕。这时最怕的不是均线算错，而是几类静默故障：行情其实已经断了但程序还在空转、单子挂在交易所一整天没人成交、或者柜台连续拒单而策略还以为在正常运行。第二天开盘才发现，往往已经错过处理窗口。
天勤 TqSdk 的程序通常靠 wait_update() 推进：每调用一次，就从服务器收一批行情和交易回报，更新内存里的对象。监控的核心，是把这些对象里几个关键字段是否还在正常变化，转成可告警的信号。下面按行情、进程、委托成交、资金风控四块说明夜盘该看什么、英文字段名在天勤里指什么、阈值怎么设才不至于误报。
一、先弄清要盯的几个天勤对象
| 你看到的英文/代码名 | 在天勤里是什么 | 夜盘监控用它干什么 |
|---|---|---|
quote |
某合约的实时行情快照，由 api.get_quote(合约代码) 得到 |
看价格时间是否还在走 |
quote.datetime |
该行情快照对应的业务时间，由行情服务写入，不是本机时钟 | 判断行情是否停更 |
symbol |
合约代码字符串，如 SHFE.rb2510（上期所螺纹钢某月份） |
多品种时要逐个盯 |
get_order() |
返回当前账户委托单字典，key 为委托号 | 看挂单是否僵死 |
status |
委托状态；ALIVE 表示仍在交易所有效、未完全成交也未撤完 |
筛在途单 |
volume_left |
该委托还剩多少手没成交 | 挂单长时间不变要告警 |
last_msg |
柜台返回的委托状态说明文字，拒单时常有原因 | 统计拒单关键词 |
is_error |
天勤标记是否为错单（文档提醒：为 False 也不代表一定没错，回报可能在途） | 辅助判断拒单 |
get_position(合约) |
该合约持仓对象 | 看仓位是否长期不变 |
pos.pos |
净持仓手数，正为多、负为空 | 与信号对照 |
get_account() |
资金账户对象 | 看风险度、权益 |
risk_ratio |
风险度，文档定义为保证金除以账户权益 | 是否接近满仓 |
emergency |
策略里自定的紧急标志变量名，非天勤内置，表示已进入强平/停机流程 | 避免重复开仓 |
TqApi |
天勤与行情、交易服务建立连接的主对象，常写作变量 api |
全程序应只有一个实例 |
二、行情是否还活着
监控逻辑：在交易时段内，若某合约的 quote.datetime 或 K 线表最后一行的 datetime 超过若干分钟不更新，说明要么休市（正常）、要么断线或订阅丢失（异常）。
休市时 datetime 本来就不会跳，所以要配交易日历或交易时段过滤，避免凌晨休市误告警。交易时段内常用阈值是五到十分钟无更新则打一条告警日志，并尝试 api.close() 后由外部守护进程重启。
实现上可在 is_changing(quote, "datetime") 为真时记录 last_seen[symbol] = time.time()，另起轻量定时检查与当前时间差。也可对 wait_update(deadline=时间戳) 设超时：deadline 是 Unix 时间，超过则函数返回 False，表示这一帧长时间没收到业务包，适合记一条"心跳超时"日志（用法见官方文档，不宜把 deadline 设得过小）。
三、连接与进程：systemd、supervisor、Api 指什么
进程外要确认 Python 进程还在。Linux 服务器上常用 systemd（系统自带的服务管理器）或 supervisor（第三方进程守护工具）配置成：进程崩溃自动拉起、且同一策略只跑一个实例。Windows 上可用计划任务或服务，原则相同。
进程内要确认只有一个 TqApi 实例。重复创建而不 close() 会叠多个连接，表现为内存上涨、行情乱跳。Jupyter 里反复运行单元格最容易犯这个错；服务器上则是部署脚本启动了两次。
内存持续涨也要查：是否缓存了巨大 DataFrame、是否在循环里追加日志不轮转。这些不属行情断线，但会导致 eventually 卡死。
四、成交与委托：ALIVE、volume_left 为什么要一起看
策略发出目标仓后，天勤会在后续 wait_update 里通过 TargetPosTask 或 insert_order 真正报单。监控要看委托对象（get_order() 返回的每一项）：
status == "ALIVE"：单还在场上排队或部分成交中。若从夜盘九点挂到十点，volume_left一直等于初始手数、一点没减少，说明价格可能太远或流动性太差，需要告警而不是干等。last_msg出现资金不足、非交易时段、价格非法等字样，应计数；一夜拒单次数突增比单笔拒单更危险。is_error为真时按错单处理，记录完整last_msg备查。
同时看持仓：若日志里已有开仓信号，但 get_position(symbol).pos 一小时不变，可能是拒单、熔断未处理、或 task 没在 set_target_volume 后继续 wait_update。这三类原因排查路径不同，都要靠日志里的 order_id 与 last_msg 区分。
五、资金与风控字段
account.risk_ratio 接近 1 表示保证金占权益比例很高，夜盘波动一大容易追保或拒单。可设阈值如 0.85 先告警、0.95 触发减仓。
emergency 若是你在代码里定义的紧急状态（例如当日回撤超限后置 True），监控应确认进入 emergency 后是否还有新开仓日志；若有，说明信号层未正确冻结。
日初权益 day_start_balance 若在夜盘日切后未重置，会把前一天基准带到今天，导致回撤计算失真。夜盘跨越自然日时，要在团队约定的时间点重记日初权益。
六、TqNotify 与日志落地
天勤在 tqsdk.lib 提供 TqNotify（以你本地 reference/tqsdk.lib.rst 为准），在 wait_update 循环里收集柜台相关通知，再统一交给一个 dispatch 函数：全量写文件，仅严重级别发钉钉或短信。避免每笔成交都推即时消息，夜盘会被刷屏。
建议结构化日志至少包含：时间戳、合约 symbol、事件类型、委托号 order_id、status、last_msg、pos.pos。事后复盘不用猜英文字段对应什么。
七、夜盘特有场景
夜盘结束到日盘开盘之间，策略是否应暂停自动开仓，要在配置里写死，不能依赖 K 线 datetime 自动分辨。小品种夜盘流动性差，ALIVE 单挂很久不成交较常见，监控项应包含"有单无成交持续时长"。
上线前在模拟盘人为断网一次，看告警能否在预期时间内触发；比真到夜盘才第一次验证可靠得多。
总结
夜盘无人值守真正要做的，是把'人不盯盘就容易忽略'的静默故障提前变成可见信号：行情是否还在动、委托是否卡住、拒单是否异常、风险是否越线。监控要同时覆盖程序内与程序外：主循环读 quote/order/position/account 把证据写入日志；进程外用 systemd 或 supervisor 保活，避免崩溃后长时间没人发现。更关键的是区分休市与交易时段，防止因为 datetime 不推进造成误告警；同时把 ALIVE 无成交、last_msg 拒单关键词突增等指标做成可解释阈值。通过这样的闭环，策略即使在深夜运行，也能把不确定性控制在可响应范围内，并在第二天开盘前把问题定位清楚。
FAQ
1）休市时也告警行情不更新怎么办？
用交易日历或 quote 交易时段判断，休市不报。
2）TqNotify 会漏消息吗？
主循环若长时间阻塞在 sleep 或同步 IO，通知也会延误；勿在 wait_update 之间长时间卡住。
3）多策略同机怎么区分日志？
每条日志加 strategy_id 前缀，拒单率分策略统计。
4）云服务器还要额外监控吗？
进程外可用简单 HTTP 心跳或磁盘空间监控，与程序内监控互补。
风险提示
以上内容用于期货程序化运维参考，不构成投资建议。