MetaTrader теряет соединение на VPS: проверяем задержку и маршрут до брокера

Как понять, что MetaTrader действительно теряет соединение с брокером

Если MetaTrader показывает No connection, сначала нужно определить, потерял ли сеть весь VPS или связь исчезла только между терминалом и торговым сервером. Работающий RDP этого вопроса не решает: ваш компьютер подключается к VPS по одному сетевому маршруту, а MetaTrader идёт от VPS к брокеру совсем по другому.

Картина бывает разной: котировки полностью останавливаются, индикатор соединения становится красным, терминал через несколько секунд подключается повторно, проблема затрагивает только один MT4/MT5 либо одновременно перестают работать все запущенные терминалы. Снаружи это выглядит похоже, но причины могут находиться в совершенно разных местах.

Что зафиксировать до перезапуска терминала

Перезапуск MetaTrader иногда возвращает соединение, но для диагностики это почти всегда должно быть не первым действием. До закрытия терминала запишите точное время сбоя и проверьте несколько признаков:

• продолжают ли обновляться котировки в других MT4/MT5;
• доступен ли Windows VPS по RDP;
• открываются ли сайты внутри самого VPS;
• не завис ли интерфейс MetaTrader;
• какое сообщение появилось во вкладке Journal;
• сколько длился разрыв — секунды, минуты или соединение не восстановилось;
• повторяется ли проблема только у одного брокера.

Если одновременно исчезает RDP, браузер внутри VPS не имеет доступа наружу и все торговые терминалы теряют связь, область поиска одна. Если браузер работает, два терминала продолжают получать котировки, а третий стоит с красным индикатором, копать нужно уже в другом месте.

Что проверить в Journal MetaTrader до диагностики сети

Journal MetaTrader нужно посмотреть до перезапуска терминала, потому что журнал привязывает событие к конкретному времени. Сам Journal не всегда способен назвать причину, но он помогает отделить сетевой обрыв от проблем авторизации, выбора торгового сервера и состояния самого терминала.

В MetaTrader 4 журнал находится во вкладке Journal окна Terminal, в MetaTrader 5 — во вкладке Journal окна Toolbox. Если нужен сохранённый лог, удобнее открыть File → Open Data Folder и уже оттуда перейти к журналам. Это надёжнее жёстко прописанного пути: разные экземпляры MetaTrader могут использовать разные каталоги данных.

Что искать около времени обрыва

Интересуют не все строки подряд, а записи непосредственно перед потерей соединения и сразу после восстановления. Формулировки зависят от версии терминала и инфраструктуры брокера. В журнале могут встречаться сообщения о потере соединения, повторном подключении, ошибке авторизации или попытке соединиться с другим сервером.

Условная временная последовательность может выглядеть так:

21:14:03 — терминал работает нормально
21:14:17 — сообщение о потере/ошибке соединения
21:14:18 — повторная попытка подключения
21:14:25 — соединение восстановлено

Здесь нас интересует интервал 21:14:17–21:14:25. Именно его потом нужно сравнивать с ping, состоянием CPU/RAM и сетевой трассировкой.

Journal и Experts — не одно и то же

Когда проблема возникает во время работы советника, откройте и Experts. Если Journal фиксирует потерю связи, а в Experts в тот же момент идёт поток ошибок или видно ненормальное поведение EA, направление проверки меняется.

Обратная картина тоже показательна: несколько независимых MetaTrader почти одновременно теряют подключение, при этом процессы отвечают нормально, CPU не забит, память не закончилась. Один советник здесь уже выглядит слабым подозреваемым.

Типичная проблема с плавающими обрывами выглядит так: пользователь видит красный индикатор, через несколько секунд соединение возвращается, а ping запускается уже после восстановления. В этот момент сеть снова идеальна. Поэтому время события зачастую ценнее самого разового теста.

Не перегружен ли Windows VPS в момент обрыва MetaTrader

Перед сетевой диагностикой нужно исключить ситуацию, когда Windows VPS упирается в CPU, память или диск. MetaTrader может выглядеть как терминал с проблемным соединением, хотя пакеты продолжают ходить нормально: процесс просто не получает ресурсы вовремя, интерфейс подвисает, графики обновляются рывками.

Откройте Task Manager непосредственно на VPS и смотрите показатели во время проблемы или сразу после неё. Особенно интересны CPU, Memory, Disk и процессы terminal.exe/terminal64.exe.

CPU: общий процент иногда обманывает

Если VPS имеет несколько виртуальных процессоров, общий CPU может выглядеть вполне терпимо, хотя один логический процессор упёрся в потолок. Для некоторых советников и вычислений внутри терминала это реальный сценарий: один поток забивает ядро, а суммарная загрузка сервера остаётся далёкой от 100%.

В Task Manager можно переключить график CPU на отображение логических процессоров и посмотреть нагрузку по отдельным ядрам. Параллельно отсортируйте процессы по CPU.

Особенно полезно поймать проблему в момент активного рынка. Если при увеличении потока тиков один terminal64.exe резко начинает грузить CPU, интерфейс тормозит, но непрерывный ping по-прежнему идёт ровно, сетевой маршрут пока не главный подозреваемый.

RAM и paging

Если свободная память закончилась, Windows начинает активнее работать с файлом подкачки. Сам pagefile нормален. Плохо другое: когда системе постоянно приходится вытеснять рабочие данные из RAM и возвращать их обратно, а несколько терминалов одновременно ждут ресурсы.

Для более подробной картины откройте Resource Monitor. На вкладке Memory посмотрите потребление памяти процессами и активность hard faults. Один всплеск ничего не доказывает. Если же нехватка памяти совпадает по времени с зависанием нескольких терминалов и активной работой диска, версия с перегрузкой VPS становится гораздо сильнее.

Диск

Обновление Windows, антивирусная проверка, интенсивная запись журналов или другие программы могут временно загрузить хранилище. В Resource Monitor можно посмотреть активность диска и время отклика операций. Если нужна более глубокая диагностика, Performance Monitor позволяет дополнительно наблюдать дисковые счётчики, включая очередь операций.

Здесь тоже не стоит цепляться за одно мгновенное значение. Ищите совпадение: RDP начинает вязнуть, окна MetaTrader открываются с задержкой, диск резко активен — и всё происходит в тот же момент.

Как отличить перегрузку VPS от сетевого обрыва

Самый полезный контр-тест — держать непрерывный ping запущенным параллельно с MetaTrader. Допустим, MT5 перестал нормально перерисовывать график, RDP реагирует с задержкой, переключение вкладок занимает несколько секунд, но:

Reply from 1.1.1.1: bytes=32 time=12ms TTL=57
Reply from 1.1.1.1: bytes=32 time=13ms TTL=57
Reply from 1.1.1.1: bytes=32 time=12ms TTL=57
Reply from 1.1.1.1: bytes=32 time=13ms TTL=57

Если одновременно Task Manager показывает проблему с CPU или памятью, а сеть продолжает отвечать ровно, искать потерю пакетов первым делом уже нет смысла. Сначала нужно разобраться, почему захлёбывается сам Windows VPS или конкретный terminal-процесс.

Если CPU, память и диск стабильны, терминал отвечает быстро, а в момент No connection появляются сетевые симптомы, можно двигаться дальше. Узкое место не похоже на нехватку ресурсов VPS.

Как проверить базовую стабильность сети VPS через ping

Для кратковременных обрывов MetaTrader ping нужно запускать непосредственно внутри Windows VPS и оставлять работающим достаточно долго. Четыре успешных ответа доказывают только то, что узел отвечал несколько секунд в момент проверки. Для сбоя, который появляется раз в несколько часов, это почти ничего не даёт.

Откройте Command Prompt на VPS и запустите непрерывную проверку стабильного внешнего адреса:

ping 1.1.1.1 -t

Здесь 1.1.1.1 используется как контрольный внешний узел, а не как замена сервера брокера. Если такой ping идёт ровно, это говорит о работоспособности общего внешнего соединения VPS по конкретному маршруту. Маршрут до брокера при этом всё ещё может вести себя иначе.

Для ограниченного теста можно отправить, например, 100 запросов:

ping 1.1.1.1 -n 100

Что смотреть в выводе ping

В строках ответа нас интересует time — RTT. В итоговой статистике Windows покажет Minimum, Maximum, Average и количество потерянных пакетов.

Если большинство ответов приходит с похожей задержкой, но периодически появляются Request timed out или RTT резко подскакивает, среднее значение всё равно может выглядеть прилично. Именно поэтому для плавающей проблемы одна строка Average мало что решает.

Проверяйте общий Интернет и брокера отдельно

Лучше держать два независимых теста: один до стабильного внешнего адреса, второй — до сервера брокера, если известный endpoint отвечает на ICMP.

ping 1.1.1.1 -t
ping <broker-host> -t

Если в момент No connection первый тест продолжает идти без потерь, а второй начинает давать timeout или сильные скачки, копать нужно в направлении брокера и маршрута к нему. Если оба теста одновременно обрываются, проблема уже ближе к общей сети VPS или вышестоящему каналу.

Как определить адрес, к которому подключён MetaTrader

Если брокер не публикует hostname торгового сервера, откройте Resource Monitor → Network → TCP Connections и найдите terminal.exe или terminal64.exe. В Remote Address будут видны удалённые адреса активных соединений процесса.

Другой вариант — узнать PID нужного процесса в Task Manager и выполнить:

netstat -ano | findstr ESTABLISHED

Последний столбец вывода содержит PID. Сопоставьте его с процессом MetaTrader.

Есть нюанс: один terminal-процесс может держать несколько TCP-соединений, а брокер может использовать несколько IP. Поэтому нельзя один раз увидеть адрес и считать, что MetaTrader всегда подключается только к нему. Лучше повторить проверку в нормальный момент и во время сбоя.

Можно ли сохранить длительный ping в файл

Если проблема появляется редко, вывод можно записывать:

ping 1.1.1.1 -t > C:\ping.txt

Такой файл удобен для просмотра потерь, но у стандартного вывода ping нет полноценной временной метки на каждой строке. Поэтому для точного сопоставления с Journal нужно отдельно фиксировать время начала теста и момент обнаруженного сбоя либо использовать более продвинутое логирование.

Какая задержка до брокера считается нормальной для MetaTrader

У MetaTrader нет одной универсальной цифры «правильного ping». Задержка зависит от расстояния между VPS и торговым сервером, магистрального маршрута, пиринга сетей и инфраструктуры конкретного брокера. Поэтому сами по себе 20, 60 или 120 ms не позволяют сказать, исправен VPS или нет.

Если мы ищем именно причину обрывов, красивая цифра 20 ms сама по себе мало что решает. Гораздо интереснее, что происходит с соединением через пять минут: остаётся ли RTT ровным, появляются ли серии timeout и совпадают ли они с сообщениями Journal.

Стабильные 80 ms и скачущие 20 ms — разные ситуации

Представим два условных маршрута. Первый постоянно держится примерно в одном диапазоне и не теряет ответы. Второй обычно даёт заметно меньший RTT, но периодически уходит в сильные пики и timeout. По минимальному ping второй выглядит привлекательнее. Для постоянного соединения MetaTrader он может оказаться хуже.

При диагностике смотрите одновременно на:

• средний RTT;
• максимальный RTT;
• разброс между соседними ответами;
• потери;
• серии timeout;
• совпадение скачков со временем No connection в Journal.

Для скальпинга, некоторых EA и других чувствительных к задержке сценариев абсолютный RTT имеет большое значение. Но это уже вопрос качества исполнения и требований торговой системы. Для поиска причины периодических disconnect стабильность маршрута важнее красивого минимального числа.

Как сравнить нормальный и проблемный период

Сделайте базовый замер, когда MetaTrader работает нормально. Например, отправьте несколько сотен запросов до одного и того же endpoint:

ping <broker-host> -n 300

Сохраните Average, Maximum и наличие потерь. Когда проблема повторится, выполните тест к той же цели ещё раз. Сравнивать домашний ПК с VPS или два разных адреса брокера бессмысленно — условия должны быть максимально одинаковыми.

Оценивать результат лучше не по принципу «стало на 15 ms больше — значит всё плохо», а по характеру изменения. Если обычный маршрут ровный, а в проблемный период появляются серии timeout и сильный разброс RTT, это уже диагностический сигнал. Если задержка выросла немного, но остаётся стабильной и без потерь, такой результат сам по себе не объясняет disconnect.

При наличии тестового VPS в другой локации повторите тот же замер до того же endpoint. Только так сравнение локаций имеет технический смысл.

Почему нельзя оценивать брокера по расстоянию до его офиса

Юридический адрес брокера и физическое размещение торгового сервера — разные вещи. Компания может работать с клиентами в одной стране, а MetaTrader-инфраструктуру держать в другом дата-центре или использовать сразу несколько площадок.

Поэтому предположение «брокер европейский, значит любой VPS в Европе будет рядом» слишком грубое. Проверять нужно реальный торговый endpoint и фактический маршрут до него.

Почему packet loss и jitter опаснее просто высокого ping

Типичная неприятная картина выглядит так: несколько минут ping идёт в диапазоне 18–22 ms, затем появляется скачок до 240 ms, два timeout подряд — и через несколько секунд снова 20 ms. Если именно в этот момент Journal фиксирует потерю соединения, средняя задержка за весь тест уже мало что говорит.

Reply: 18 ms
Reply: 19 ms
Reply: 21 ms
Reply: 240 ms
Request timed out
Request timed out
Reply: 22 ms
Reply: 20 ms

Packet loss в контексте ping означает отсутствие части ожидаемых ICMP-ответов. Jitter — изменение задержки во времени. Стандартный Windows ping не показывает jitter отдельным числом, но сильный разброс между соседними RTT хорошо виден прямо в последовательности ответов.

Среднее значение сглаживает такие короткие провалы. Сотни нормальных ответов легко «спрячут» несколько плохих секунд, хотя для постоянной TCP-сессии MetaTrader именно эти секунды могут быть самыми интересными.

Серия timeout важнее одиночного выброса

Один высокий RTT среди сотен нормальных ответов может быть случайностью. Несколько timeout подряд, повторяющиеся всплески в одно и то же время или совпадение с disconnect в Journal — уже совсем другая история.

Если проблема возникает редко, непрерывный ping -t полезнее короткого теста. Для статистики по маршруту можно дополнительно использовать:

pathping <broker-host>

pathping сначала определяет маршрут, а затем некоторое время собирает статистику. Поэтому полный результат появляется не сразу.

Один проблемный hop ещё ничего не доказывает

Промежуточный маршрутизатор может показывать высокий ICMP loss и при этом нормально передавать транзитный трафик. Причина проста: обработка диагностических ICMP-запросов для маршрутизатора не обязана иметь тот же приоритет, что и пересылка обычных пакетов.

Условный результат:

Hop 4          Loss 0%
Hop 5          Loss 60%
Hop 6          Loss 0%
Hop 7          Loss 0%
Destination    Loss 0%

Если после пятого hop следующие узлы и конечная точка снова отвечают без потерь, утверждать, что пятый маршрутизатор реально отбрасывает 60% пользовательского трафика, нельзя. На одном hop пугаться рано.

Чистый ICMP не гарантирует идеальную TCP-сессию

Обратная ситуация тоже возможна: обычный ping идёт чисто, но MetaTrader всё равно теряет конкретное TCP-соединение. ICMP и торговый TCP-трафик — не одно и то же. Разный трафик может обрабатываться разными правилами firewall, фильтрацией или оборудованием.

Поэтому отсутствие packet loss в ping не закрывает диагностику. Если известны endpoint и порт торгового сервера, дополнительно проверяйте TCP-доступность и обязательно смотрите Journal самого MetaTrader.

Сильное доказательство получается не из одной команды, а из совпадения событий: Journal фиксирует disconnect, в ту же секунду сетевой тест показывает провал или TCP endpoint перестаёт отвечать. Вот это уже материал для дальнейшего разбора.

Как проверить маршрут от VPS до сервера брокера

tracert показывает последовательность сетевых узлов между Windows VPS и выбранной целью. Он особенно полезен, когда общий Интернет работает нормально, а соединение с конкретным брокером нестабильно. Искать «виновный сервер» по первой звёздочке в трассировке нельзя.

Если известен hostname или IP торгового сервера, запустите:

tracert <broker-host>

Если обратные DNS-запросы замедляют вывод и имена узлов не нужны:

tracert -d <broker-ip>

Что смотреть в tracert

• на каком участке впервые заметно растёт RTT;
• сохраняется ли этот рост на последующих узлах;
• есть ли несколько последовательных проблемных hops;
• доходит ли трассировка до конечной сети;
• одинаков ли маршрут в нормальный момент и во время проблемы;
• не меняется ли путь между двумя замерами.

Условный фрагмент:

1    1 ms    1 ms    1 ms
2    3 ms    2 ms    3 ms
3    9 ms   10 ms    9 ms
4    *       *       *
5   11 ms   10 ms   11 ms
6   12 ms   13 ms   12 ms

Четвёртый hop не отвечает, но следующие узлы снова показывают нормальный RTT. Скорее всего, промежуточное оборудование просто не отвечает на диагностический ICMP или ограничивает такие ответы. Транзит при этом проходит.

Другой вариант:

1    1 ms    1 ms    1 ms
2    3 ms    3 ms    2 ms
3   10 ms    9 ms   10 ms
4  120 ms  145 ms  130 ms
5  135 ms  160 ms  149 ms
6  142 ms  171 ms  155 ms

Здесь рост начинается после определённого участка и сохраняется дальше. Такой результат уже интереснее, хотя одной трассировки всё равно мало. Нужен повторный замер и, желательно, совпадение с реальным ухудшением MetaTrader.

Сравните трассировку в норме и во время сбоя

Сохраните маршрут, когда всё работает:

tracert <broker-host> > C:\tracert-normal.txt

Затем повторите тот же тест во время проблемы:

tracert <broker-host> > C:\tracert-problem.txt

Если путь изменился, выросло число hops или высокая задержка появилась на другом участке, у поддержки уже есть два состояния одного маршрута, которые можно сравнивать.

Для более длительной проверки:

pathping <broker-host>

Что делать, если конечный сервер не отвечает на tracert

Некоторые конечные узлы не отвечают на ICMP или traceroute, хотя сам сервис работает. Если MetaTrader подключён, а последний hop показывает звёздочки, это само по себе не проблема.

Если известны endpoint и порт, используйте TCP-проверку:

Test-NetConnection <broker-host> -Port <port>

Порт нужно брать из реального соединения или документации брокера, а не угадывать.

Не определяйте географию только по имени маршрутизатора

Hostname узла иногда содержит код города или дата-центра, но это не гарантированная географическая метка. IP-геобазы тоже ошибаются. Для диагностики важнее реальное изменение RTT и пути, чем попытка доказать лишний круг трафика по одному имени hop.

Что делать, если Интернет на VPS работает, а отключается только один брокер

Если на одном Windows VPS запущены несколько MetaTrader и отключается только один брокер, сначала проверяйте конкретный торговый сервер, экземпляр терминала и маршрут до этой сети. Такой симптом плохо согласуется с полным обрывом Интернета на VPS.

Например, MT5 брокера A продолжает обновлять котировки, MT4 брокера B показывает No connection, RDP не прерывается, сайты открываются. Это ещё не доказывает проблему на стороне брокера, но перезагружать весь Windows VPS здесь явно рано.

Сравните терминалы как контрольные точки

Несколько MetaTrader на одном VPS дают удобный контрольный тест. Во время следующего сбоя проверьте:

• получают ли котировки другие брокеры;
• работает ли другой аккаунт того же брокера;
• использует ли проблемный терминал другой торговый сервер;
• есть ли отличия в Journal;
• не завис ли только один terminal.exe или terminal64.exe;
• совпадает ли удалённый IP проблемного соединения с тем, который проверялся ping/tracert.

Demo и Live тоже могут идти через разные серверы. Поэтому ситуация «Demo работает, Live нет» не означает автоматически проблему аккаунта. Сначала нужно понять, куда реально подключены оба терминала.

Проверьте TCP-соединение процесса

В Resource Monitor откройте Network → TCP Connections и найдите нужный terminal-процесс. Здесь можно увидеть Remote Address и состояние TCP-соединения.

Если известен порт:

Test-NetConnection <broker-host> -Port <port>

Порт не нужно угадывать. MetaTrader-инфраструктура у брокеров различается, поэтому проверять случайный 443 и считать это тестом торгового соединения бессмысленно.

Если терминал имеет несколько соединений, повторите проверку в момент нормальной работы и во время сбоя. Один и тот же брокер может использовать несколько адресов, балансировку или разные серверы для разных аккаунтов.

Не забудьте про Firewall и защитное ПО

Если проблема появилась после обновления Windows, установки антивируса, EDR или изменения правил Windows Firewall, проверьте, не ограничен ли конкретный terminal.exe. Особенно если другие приложения на VPS продолжают работать нормально.

Это не повод отключать firewall целиком. Нужна проверка правил для конкретного процесса и направления, а затем повторный тест соединения.

Если соседний терминал жив, копать весь VPS как полностью «без Интернета» уже нет смысла. Но и обвинять брокера рано. Между ними остаётся маршрут, TCP-сессия и сам terminal-процесс.

Поможет ли перенос MetaTrader VPS ближе к брокеру

Для MetaTrader важнее маршрут VPS → торговый сервер брокера, чем расстояние от пользователя до VPS. После запуска терминала котировки, торговые запросы и советники работают на удалённом сервере, а домашний компьютер в основном используется для RDP-управления.

Поэтому VPS для MetaTrader может находиться дальше от пользователя, но иметь более короткий и стабильный путь до брокера. RDP станет чуть медленнее, а MetaTrader — наоборот, получит лучший маршрут.

Географически ближе — не всегда сетево ближе

Два дата-центра в соседних странах могут использовать совершенно разные операторские сети. Один идёт к брокеру почти напрямую, второй отправляет трафик через несколько транзитных операторов. Карта этого не покажет.

Перед переносом сравнивайте:

• Average RTT до одного и того же торгового endpoint;
• Maximum RTT;
• потери на длительном тесте;
• разброс задержки;
• tracert/pathping;
• поведение в те часы, когда обычно возникает проблема.

Если есть тестовый VPS в другой локации, сравнивайте именно один и тот же сервер брокера. Тест до разных IP почти ничего не говорит о том, какая площадка лучше.

Когда смена локации действительно обоснована

Перенос VPS имеет технический смысл, если уже исключены проблемы самого терминала и ресурсов Windows, а сетевые тесты устойчиво указывают на текущее направление.

• обрывы повторяются именно на маршруте к брокеру;
• общий Интернет VPS при этом остаётся стабильным;
• в другой VPS-локации тот же endpoint показывает более ровный RTT и лучший маршрут;
• Journal по времени совпадает с сетевыми провалами;
• проблема воспроизводится не только в одном экземпляре terminal.exe.

Когда перенос пока не обоснован

• один терминал зависает, а остальные работают;
• одно ядро CPU постоянно упирается в потолок;
• RAM закончилась и Windows активно использует pagefile;
• Journal показывает проблему авторизации или конкретного аккаунта;
• торговый сервер недоступен сразу из нескольких независимых сетей;
• новая локация не проверялась до того же endpoint.

Если слабое место действительно находится на маршруте текущего провайдера, другая площадка с иным upstream может помочь. Если проблема внутри MetaTrader или на стороне торгового сервера, можно перенести все терминалы и получить тот же No connection на новом VPS.

Как за 10 минут определить, где искать причину обрывов MetaTrader

Причину обрывов MetaTrader проще искать в фиксированном порядке: Journal, ресурсы VPS, общий внешний канал, затем конкретный маршрут до брокера. За десять минут плавающий сбой может и не повториться, но подготовить диагностику и сузить область поиска за это время вполне реально.

Минимальный набор команд

ping 1.1.1.1 -t

ping 1.1.1.1 -n 100

ping <broker-host> -t

tracert <broker-host>

pathping <broker-host>

netstat -ano | findstr ESTABLISHED

Test-NetConnection <broker-host> -Port <port>

Все команды выполняются внутри Windows VPS. Если запускать ping с домашнего компьютера, вы проверяете маршрут своего интернет-провайдера, а не путь, по которому MetaTrader работает с брокером.

Как интерпретировать результат

Что отправить поддержке вместо «MetaTrader иногда отключается»

Для разбора плавающего обрыва нужны не общие описания, а данные одного и того же события. Подготовьте:

• точное время нескольких обрывов;
• сообщения Journal в эти минуты;
• информацию, работали ли остальные MetaTrader;
• состояние CPU, RAM и Disk;
• результат продолжительного ping;
• tracert или pathping до проблемного endpoint;
• IP/hostname торгового сервера, если его удалось определить;
• порт соединения, если он известен;
• уточнение, терялся ли RDP и работал ли обычный Интернет внутри VPS.

Если No connection появился в 18:07, а ping и tracert были сделаны в 18:40 после полного восстановления, оба результата могут оказаться идеальными. Намного ценнее поймать один обрыв целиком: строку Journal, состояние ресурсов и сетевой тест в одном временном интервале.