VPS 状态显示绿色与交易列表没有动静,回答的是不同的问题。要监督外汇 EA,您需要获取终端、所需市场数据、程序运行和当前经纪商订单的最新证据,还需要一条在报告终端停止运行时仍然有效的告警通道。
这是 VPS 与 MT4 稳定性系列的第 4 篇指南。请先了解 托管与运行连续性,再通过 指南 2 了解配置,通过 指南 3 了解恢复流程。本指南重点介绍如何观察正常运行,并在事故扩大之前发现不确定情况。
先定义正常运行,再定义故障
EA 即使没有开仓,也可能运行正常。交易时段过滤、点差限制、已有订单组合、风险规则或缺乏有效信号,都可能解释这种安静状态。监控应检查预定环境能否完成其文档规定的任务,包括管理现有订单,而不是要求达到最低交易笔数。
记录终端身份、目标账户与服务器、准确的交易品种和图表周期、EA 版本、获准使用的 Inputs、订单归属规则及预期运行时段。也应列出 EA 所需的其他品种。向开发者确认程序实际提供哪些状态、日志和重启行为。EX4 文件并不会自动提供心跳或对每项决策的完整解释。
区分三种状态:正常、已确认的问题和未知。如果仪表板停止更新,应显示最后观察时间,并将当前状态标为未知;不要继续把过时的绿色状态当作当前证据。
检查四层证据
| 层级 | 有用的观察结果 | 仅凭此项无法确认什么 |
|---|---|---|
| VPS 与操作系统 | 可用性、重启事件、资源压力、存储空间及目标 MT4 进程。 | 机器可访问或进程正在运行,并不能证明 EA 逻辑能正常响应。 |
| MT4 与市场数据 | 正确的账户与服务器、连接状态,以及每个所需品种的近期数据。 | 一个图表持续变化,并不能证明另一个所需品种也在更新。 |
| EA 运行 | 初始化成功、文档规定的状态、权限,以及程序支持时有实际意义的心跳。 | 计时器消息不能证明信号计算或持仓管理已完成。 |
| 经纪商订单与管理 | 当前持仓与挂单、已接受的保护设置、请求结果,以及预定的订单管理实例。 | 账户余额、旧报告或上一次成功交易,不能确认当前的保护状况。 |
这些检查彼此独立。可以手动检查,也可以通过专门配置的监控系统采集;MT4 不会自动将它们整合成此处描述的仪表板。
不改变策略的五分钟检查
- 确认 EA 在哪里运行。 检查目标终端和账户,而不是迁移后遗留的本地图表。
- 检查交易时段及所需报价。 确认此时是否应有更新,以及经纪商的准确品种名称是否具有可用数据。
- 检查初始化与权限。 阅读近期的
Experts与Journal消息,以及 EA 文档规定的状态。 - 检查当前订单。 确认由谁管理,以及经纪商端实际存在哪些保护设置。
- 检查监控通道。 确认最新报告时间,并确认测试告警能送达目标设备。
五分钟是一种检查形式,并不保证能完成诊断,也不代表适用于所有 EA 的响应时间。如果情况不明确,请保留证据并参考 EA 错误指南。不要为了让状态灯变绿而放宽点差或风险限制、修改 Magic Number,或强制入场。
已连接不等于正在接收新报价
IsConnected() 报告终端与服务器的连接状态。它不能证明每个品种的数据都是最新的、账户有交易权限,或策略逻辑运行正常。检查准确的品种名称,包括经纪商后缀,以及 EA 除挂载图表外还需要的数据。
MarketInfo(symbol, MODE_TIME) 提供该品种最后收到的 tick 时间,采用经纪商服务器时间基准。最后一次报价是历史证据,并不是在没有新 tick 时仍会前进的时钟。周末、品种交易时段的休市间隔或市场平静时,报价较旧可能属于正常现象。将报价静默判断为行情故障之前,先检查经纪商的实际交易时间表。
观察正常行为后,按品种及交易时段定义报价时效检查。不存在适用于所有外汇货币对或所有 EA 的通用安全超时值。仅凭 Bid 价格不变也不够:连续 tick 可以具有相同价格。如果条件允许,应记录数据事件的接收情况,而不只是价格是否变化。
为不同问题使用正确的时钟
| 时钟或时间戳 | 含义 | 监控的局限 |
|---|---|---|
TimeCurrent() | 最后已知的服务器时间。在 OnTick()中,它指正在处理的 tick;在其他事件处理函数中,它指 Market Watch 中某个选定品种的最新报价时间。 | 没有报价时可能停止前进,也不能专门证明 EA 目标品种的数据时效。 |
MODE_TIME | 指定品种最后收到的 tick 时间。 | 使用正确的服务器时间基准,并结合交易时段判断。 |
TimeLocal() | 计算机的本地时钟。 | 时区、夏令时或时钟校正可能改变比较结果。 |
| 独立采集器的接收时间 | 监控服务实际收到已识别报告的时间。 | 取决于采集器和传输过程;不能证明底层交易流程已完成。 |
在确认两者采用共同时间基准之前,不要直接用 Windows 时钟减去经纪商报价时间,并将结果称为报价年龄。开发者可以使用适当的计数器测量经过的时间,但必须处理重置和计数器回绕。外部采集器应使用经过测试的自身计时逻辑判断报告缺失,并与市场时间戳分开处理。
在日志中标明来源、日期和时区。重建事故经过前,应统一各来源的时间基准;屏幕上两个看似相近的时间,不能证明事件先后顺序。请参阅 Experts 与 Journal 日志指南。
明确心跳究竟能证明什么
心跳是由指定组件定期发送的报告。VPS 心跳反映主机的部分状态;监控 EA 的心跳反映其自身的事件处理。两者都不能自动证明另一个交易 EA 已评估信号或管理订单组合。
OnTick() 在 EA 挂载图表的品种收到新 tick 时运行。如果仅在此处发送心跳,该品种没有 tick 时,心跳可能停止。若开发者已实现相关功能,程序也可以使用 EventSetTimer() 配合 OnTimer() 来请求定期事件。计时器事件会进入队列;当同类事件已在队列中或正在处理时,不会再添加一个。这不是精确的外部时钟,也不能保证阻塞的程序仍会持续报告。
应询问报告由哪个检查点产生:进入事件处理函数、完成数据检查、完成管理周期,还是成功传输。实用字段包括实例身份、版本、序列号、运行模式、数据状态,以及报告生成和接收时间。递增序列号有助于区分新报告与重复播放的旧报告,但仍不能证明成交。
对于闭源 EA,请使用供应商支持的状态信息和外部观察。不要将新增观察程序描述为能够访问策略内部健康状况。独立监控 EA 需要自己的图表;将它挂载到策略图表会替换原有 EA。它应只观察,不应发送交易或管理策略订单。
从终端外部检测报告缺失
已经停止运行的终端无法可靠地发送自己的最后一条故障消息。独立观察程序可以发现预期报告停止到达,前提是观察程序、其连接和通知通道仍然有效。若唯一的看门狗也部署在同一台 VPS 上,它同样会受该主机故障影响。
将信息采集与干预分开。报告缺失告警意味着观察链路中的发送端、网络、采集器或告警通道某处出现问题。它不能证明主 EA 已停止交易,也不能自动启用备用交易副本。移交前应先调查主机及当前经纪商订单;移交流程请参阅 指南 3。
为每个预定实例分配独立的监控身份,并检测未知或重复发送者。也应监控采集器自身,并配置经过测试的备用联系通道。只传输必要状态;密码、激活密钥和无限制账户访问权限都不应成为心跳字段。
监控权限,但不要盲目启用
在普通桌面版 MT4 中,应同时检查 AutoTrading 和 EA 自身的交易权限,以及目标账户的交易权限与供应商许可。只读登录可以显示账户信息,却不能交易。权限改变后,EA 可能继续计算,但无法完成预定的订单修改。
不带参数的 IsTradeAllowed() 检查发起调用的 EA 是否有权限,以及交易上下文是否忙碌。返回 false 不是完整诊断;返回 true 也不保证经纪商会接受下一个请求。独立观察程序的权限结果不能证明另一个 EA 的程序级权限。
当运行模式意外偏离获准状态时发出告警。主动暂停的终端应记录为暂停,而不是由看门狗“修复”。关闭自动交易不会平仓,却可能中断依赖本地程序的退出管理。任何暂停都应有明确的订单管理计划。
监控失败请求与现有持仓
跟踪有文档记录的交易请求顺序:预定操作、尝试、返回结果,以及与经纪商记录的核对。即使没有出现新持仓,被拒绝的请求和失败的修改仍然重要。如果供应商没有记录尝试或跳过信号的原因,仅凭交易列表无法可靠地重建这些信息。
错误 128 表示交易超时。响应丢失或不确定后,应先检查持仓、挂单及相关历史,再决定是否重试。没有本地确认不能证明请求被拒绝。调查时应包括准确品种、方向、交易量、已知时的订单编号及请求时间;不要猜测哪笔订单属于本次尝试。
结合 EA 文档中的订单归属规则,检查当前风险敞口、浮动盈亏、账户净值,以及已接受的 Stop Loss/Take Profit。经纪商端持有的保护设置不同于计划中的虚拟止损或未来的移动止损调整。EA 停止后,持仓可能继续存在;本地监控不可用时,挂单也可能触发。本指南不定义新的回撤阈值或自动清仓政策。
测试告警直至确认接收端收到
- 在目标终端中,打开
Tools → Options → Notifications,启用推送通知,并输入目标移动终端的MetaQuotes ID。 - 使用
Test,确认终端结果,并在实际设备上核实是否收到。检查设备通知权限及实际响应通道。 - 单独测试 EA 或观察程序的实际告警条件。设置页面中的测试不能证明报告缺失规则或订单拒绝告警确实存在。
- 记录测试时间、发送者、目标地址和结果;VPS 迁移、设备更换或通知设置修改后,应再次测试。
Notify of trade operations 涵盖成功的交易操作及文档规定的账户事件;它不会通知失败的交易操作。因此,它不能完整监控请求拒绝、过期数据或终端故障。
对于自定义的 SendNotification(),MetaQuotes 文档规定消息最多 255 个字符,每秒最多调用 2 次,每分钟最多 10 次。违反频率限制可能导致此函数被禁用。它不能在 Strategy Tester 中运行,因此应在适当的运行中模拟环境检查投递情况。成功发送并不能证明有人看到了消息或确认接收。应合并重复故障,在状态发生有意义的变化时发送,而不是每个 tick 都发告警。
在告警规则中写明背景与下一步
| 条件 | 所需背景信息 | 有用的下一步 |
|---|---|---|
| 近期没有报告 | 预期发送者及间隔、采集器健康状况,以及计划内维护。 | 确认观察链路和主实例状态;不要自动启动备用实例。 |
| 所需品种报价过旧 | 准确品种、运行时段、正常更新行为及时间基准。 | 检查其他所需品种、连接及经纪商服务状态。 |
| 意外的交易限制或失败请求 | 获准运行模式、发起调用的 EA 与账户、准确消息及当前订单。 | 调查权限或拒绝原因;重试之前先核对不确定的执行结果。 |
| 存在未平仓订单,但管理状态未知 | 当前风险敞口、已接受的经纪商端保护,以及预定管理实例。 | 遵循已有的事故处理计划,明确管理责任。 |
定义持续时间、重复告警间隔、确认方式和恢复条件。恢复消息应说明哪些观察结果已恢复;一条新心跳不能证明所有层级均已恢复。明确维护窗口、负责人和结束时间,不要永久屏蔽频繁触发的告警。
根据账户实际情况确定严重程度。在没有风险敞口时,与持仓依赖本地退出管理时,同样的数据问题可能有不同影响。监控用于识别这种情况,并不能提供通用的安全等待时长。
使用同一时钟的心跳缺失示例
假设示例:采集器预期每 60 秒收到一份具有明确身份的报告,并在 180 秒没有新报告时触发缺失告警。这些只是教学设置,不是通用推荐阈值。下方所有时间都是采集器以 UTC 记录的观察时间;没有从中减去经纪商报价时间。
| 采集器时间(UTC) | 观察 | 证据支持的结论 |
|---|---|---|
| 10:00:00 | 收到最后一条具有明确身份的心跳。 | 收到了一份报告,报告了其定义的检查点状态。 |
| 10:01:00 | 独立主机检查收到响应;没有新的 EA 心跳。 | 主机检查通道有效;EA 报告状态仍未确认。 |
| 10:03:00 | 采集器已持续 180 秒没有收到新心跳。 | 示例中的报告缺失条件已满足;故障组件仍然未知。 |
| 10:03:20 | 获授权的检查观察到更新的报价及一笔经纪商端未平仓订单。 | 观察到了市场数据和风险敞口;仍需确认交易 EA 的管理状态。 |
这里, 180 ÷ 60 = 3 个预期报告间隔内没有收到新报告。这不能证明以下情况:交易停止时间为 10:00:00、服务器拒绝了操作,或订单无人管理。干预前应检查 EA、日志及当前订单状态。如果采集器本身曾不可用,就不能声称它连续观察了整个时间段。
保留简明运行记录
实用记录包括最近成功检查的时间、所需品种的数据状态、EA 与终端身份、未平仓订单的管理者、尚未解决的消息、告警测试结果及计划变更。在部署、重启、迁移、获准的参数修改和经纪商维护后进行检查,然后根据实际 EA 的管理需求安排检查频率。
公开监控有助于评估表现,但首先应检查最后更新时间和报告延迟。漂亮的余额曲线并不是实时健康检查。安静的报告或不变的余额,不能区分等待信号与终端故障。应将表现评估与即时运行监督视为不同任务。
观察实际执行交易的环境
对于 Windows VPS,主机及进程检查、终端观察和独立采集器可以覆盖不同故障路径。通过 指南 2检查资源压力及启动行为;成功登录 Windows 不能确认 EA 正常工作。
对于 MetaTrader 集成虚拟托管,应通过托管控制功能检查远程运行状态、同步,以及请求获取的终端和 Experts 日志。本地图表或本地心跳不能反映远程 EA。任何远程心跳都必须专门部署、兼容该环境并经过测试;Windows 服务和不受支持的 DLL 工具不能直接复制过去使用。
本地的 AutoTrading 不会停止托管副本。干预时应使用托管控制功能,并核实实际远程状态。监控系统应明确它观察的是主交易主机、本地准备终端,还是备用实例。
在模拟环境演练监控盲区
使用获授权的模拟环境及其独立状态文件。测试受控的终端关闭、报告通道中断、预期的品种休市间隔、主动暂停及恢复正常。区分真正的告警与成功的告警投递测试。不要为了测试看门狗而创建无人管理的实盘持仓。
记录已测试的配置、观察结果和剩余盲区。成功的监控可以减少不确定性,但不保证可用性、订单执行或策略表现。
EA 监控常见问题
没有新交易是否意味着 EA 故障?
不一定。应检查交易时段、信号规则、数据、权限及现有订单管理。正常策略可能正确地保持空闲。
心跳是否证明 EA 的所有功能都正常?
不是。它只能证明文档规定的报告已生成或收到。其价值取决于产生报告的检查点,以及哪些字段仍然有效。
标准 MT4 推送通知能否检测所有故障?
不能。成功交易通知不包含失败操作,停止运行的终端也无法可靠地报告自身完全故障。应分别测试自定义规则和独立的报告缺失监控。
心跳缺失是否应自动启动备用 VPS?
不应。先确认主实例的交易状态、当前经纪商订单及管理归属。报告缺失本身并不授权重复运行自动交易程序。
官方参考资料与适用范围
平台细节已依据 MetaQuotes 官方文档核对。检查形式、示例阈值和事故处理规则属于运行方面的教学指导,并非所提供的监控产品或测得的可靠性结果。界面标签因终端语言而异;请确认您自己安装版本中的标签。