Мониторинг терминалов МТ4 через веб-браузер

декабря 24, 2017

Это статья стороннего автора - Solandr'а. Статья публикуется в рамках
сотрудничества с читателями.
Эта статья сугубо техническая и предназначена в первую очередь для трейдеров-управляющих, но может быть интересна также и инвесторам, интересующимся каким образом всё устроено на той стороне инвестиционного процесса, которая для инвестора является, как правило, чёрным ящиком.

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


Постановка задачи

В ходе своей деятельности успешным управляющим, как правило, приходится увеличивать количество управляемых счетов. Например, у управляющих возникают новые торговые идеи, которые нужно проверить на новом счёте, чтобы не испортить уже годами наработанную статистику старых счетов. Также инвесторы и управляющие компании могут попросить взять в управление счета, открытые ими на выбранных торговых площадках. Или же размер сумм в управлении на старом счёте уже достиг определённого предела, после которого брокер отказывается давать кредитное плечо более 1:25, что накладывает жёсткие ограничения по лотности открытых позиций и высокорисковые счета уже не могут работать в точном соответствии с торговым алгоритмом. Одним словом существует масса ситуаций, когда установка и настройка нового терминала МТ4 является единственно возможным решением поставленных задач. И как результат количество обслуживаемых терминалов МТ4 со временем начинает исчисляться десятками, накладывая на управляющего определённые требования по их операционному обслуживанию. Например рабочий стол торгового сервера с 32 терминалами МТ4 может выглядеть вот так:

Конечно же, некоторые умники, присутствующие, например, на форуме Альпари, могут заявить, что, дескать, “нужно сразу писать правильный код советника”, “вы просто не умеете программировать робастных советников” или же тому подобный бред, приходящий в голову первым при обсуждении внешних (по отношению к торговому советнику) систем мониторинга.  Но я на основании своего 4-х летнего опыта управления инвесторскими средствами могу заявить, что данные умники КАТЕГОРИЧЕСКИ НЕПРАВЫ! И в моей практике было достаточно много случаев, когда какие-то сбои и непредвиденные ситуации могли бы были быть замечены заблаговременно автоматически благодаря разработанной мониторинговой системе. Как говорят в армии, воинский устав написан кровью, ну а здесь моя мониторинговая система была написана по результатам ежедневной практики наблюдения за работой терминалов и разрешения множества нештатных ситуаций, регулярно возникающих на счетах по разным причинам.

И нельзя сказать сейчас, что данная работа полностью завершена и в будущем ничего такого нового нештатного не появится, что не потребовало бы доработки предлагаемой ниже мониторинговой системы. Поэтому приведённое ниже техническое решение является лишь только текущей версией системы мониторинга, которой пользуюсь в настоящий момент я. Но с течением времени в неё будут вноситься и другие дополнительные параметры для мониторинга, расширяя список проверок. Поскольку каждый управляющий имеет свои торговые системы, то предлагаемый код будет перерабатываться каждым управляющим в соответствии с его видением необходимости мониторинга того, или иного параметра его торговой системы, а также каких-либо иных системных параметров типа загрузки процессора, наличия интернета и т.д. Главная цель данной статьи - это продемонстрировать возможное техническое решение задачи мониторинга. И оно никоим образом не претендует на абсолютную грамотность или оптимальность самого подхода, поскольку я не являюсь каким-то профессиональным программистом и многие вещи грамотной реализации программных продуктов просто никогда не изучал. Поэтому это решение “As it is” без каких-либо гарантий того, что оно полностью подойдёт управляющим для решения именно их задач по мониторингу счетов, находящихся в управлении. В общем, представляю вниманию трейдерской публики решение задачи мониторинга, которое удалось реализовать мне в рамках имеющегося у меня опыта программирования.


Блок-схема мониторинговой системы и примеры информационных сообщений

Ниже приведена блок-схема мониторинговой системы. Как видно, на ней имеется 3 основных составляющих – это торговый сервер с установленными терминалами МТ4, веб-сервер и веб-браузер, который и показывает трейдеру-управляющему мониторинговую информацию о состоянии терминалов МТ4.

Система выводит данные на мой мониторинговый сайт (на страницу для личного пользования). Пример, иллюстрирующий упрощённый вид страницы, можно посмотреть здесь.

На каждый терминал выделено по одной строке, содержащей время последней проверки, параметры ближайших ордеров и название счёта. Если все мониторинговые проверки прошли успешно, то строка имеет краткую запись зелёным шрифтом. Если же на счёте проблемы, то сразу же вываливается более подробный мониторинг красным шрифтом, где отображено какая проверка была провалена (смотрите статус false). Теперь я из любого места с мобильного телефона проверяю состояние терминалов за 5 секунд максимум. Прикиньте сами, сколько вам потребуется времени для просмотра по диагонали вот этой вот страницы, если большую часть времени она вся зелёная?

По ссылкам, поставленным на названиях счетов, идёт переход ниже по странице на расширенную информацию о счёте, которая включает в себя последние 22 записи в логах терминала, а также другую информацию о терминале, как то загрузка процессора на торговом сервере, открытый и отложенный риск ордеров (аналог расчётов вот с этой страницы http://solandr.hldns.ru/), информацию по ближайшим отложенным ордерам.

В этом расширенном информационном разделе есть ссылка на скриншот экрана мониторинга в терминале. Ниже приведены скриншоты при нормальном прохождении проверок и при провале одной из проверок.


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

Рассмотрим более подробно что я вижу в своих автоматических проверках. В состоянии ОК (зелёная строка) я вижу время последней проверки. Проверка проходит раз в час. Далее парочку информационных параметров, отвечающих за ближайшие ордера. И завершает строку название ПАММ/МАМ/личного счёта.

По информационным параметрам ордеров я отслеживаю насколько на каждом из терминалов отложки разошлись у разных брокеров, и могу при необходимости вручную поправить глобальные переменные, чтобы параметры ордеров везде совпадали с флагманским счётом. Отличие в информационных параметрах ордеров на разных счетах может быть обусловлено различием в котировках у разных брокеров. Например, причиной тому может быть порванная история котировок из-за проблем на стороне сервера брокера. Также в начале недели эти параметры могут различаться из-за того, что на AlfaForex торговля на открытии рынка начинается на 1 час раньше, чем в среднем у остальных, а на NPBFX наоборот на 1 час позже. А поскольку для торгового эксперта входной информацией являются котировки, то он может принимать разные торговые решения. И мониторинговая система как раз легко помогает отследить такие расхождения и своевременно вмешаться в процесс торговли. Например, подкачать котировки для заполнения разрыва, или просто вручную скорректировать некоторые глобальные переменные терминала, если всё дело только в разнице времени начала/окончания торговли у разных брокеров.

В состоянии FAILED я вижу результаты всех проверок, которые этот FAILED сформировали (красный шрифт), а именно название счёта, название версии мониторингового советника, время последней автоматической проверки, название версии торгового советника, разрешение автоторговли в терминале, разрешение торговли в самом советнике, подключение терминала к брокеру, разрешение торговли экспертами со стороны брокера, разрешение торговли для счёта со стороны брокера, признак отсутствия в последних 22 строчках логов сообщений об ошибках, запускался ли прогон советника в последние 7 минут, проверка риска/лотности ордеров, запускалась ли функция анализа ошибок в последние сутки, параметры для синхронизации ордеров по разным брокерам, и в конце ФИНАЛЬНЫЙ РЕЗУЛЬТАТ проведённых выше проверок.

В целом было потрачено огромное количество времени, но зато теперь весь цикл проверки состояния всех терминалов занимает менее 5 секунд вместо 10 минут месяцем ранее. А это, на мой взгляд, неимоверно КРУТО, поскольку создана легко масштабируемая система мониторинга терминалов МТ4. И теперь удвоение имеющегося количества терминалов после первоначальных затрат времени на конфигурацию всей системы увеличивает время периодических проверок через веб-сайт совсем незначительно по сравнению с текущими 5 секундами времени.


Программная реализация

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

Для продолжения чтения необходимо скачать и распаковать файлы мониторинговой системы. Архив с файлами находится здесь.

Monitoring_expert_for_article.mq4 – мониторинговый экспер.

put_on_ftp_log.bat – CMD файл для осуществления передачи данных на веб-сервер.

Папка www содержит файл mon_index.html c включением в него PHP кода, который формирует итоговый вид страницы мониторинга, включая в него файлы с результатами итоговых проверок. Эти файлы находятся на сервере, с которого осуществляется показ html страницы.

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

Мониторинговый эксперт в результате своей работы формирует следующие файлы:
checks_result.html – итоговый результат проверки (зелёная или красная строка);
log.html – файл с расширенной информацией о счёте, включая логи терминала;
nearest_orders.html – ближайшие отложенные ордера BYUSTOP и SELLSTOP;
screenshot.gif – скриншот экрана терминала МТ4, где работает мониторинговый эксперт.

Файл put_on_ftp_log.bat, запускаемый на исполнение мониторинговым экспертом, копирует сформированные файлы на сервер и удаляет их с локального диска. 

Каждый терминал МТ4 копирует файлы в свою папку на сервере, например в www/mon.hib.ru/monitoring_example/accounts/account01.

Конечная папка указывается в самом файле put_on_ftp_log.bat для каждого терминала МТ4 отдельно.

Файл put_on_ftp_log.bat содержит в себе данные о подключении к серверу по FTP протоколу: IP адрес, логин и пароль.

В ходе своей работы файл put_on_ftp_log.bat формирует файл transport.txt, в который записывает всю последовательность команд, необходимую выполнить при копировании файлов на сервер. Далее даётся команда ftp со сценарием обмена transport.txt. По завершению работы обмена данными происходит удаление файлов с результатами мониторинга и файла transport.txt.

Рассмотрим более подробно основные части кода мониторингового эксперта monitoring_expert_for_article.mq4.

В строках 39-47 задаются базовые настройки, определяемые номером счёта, на котором запущен мониторинговый эксперт: название счёта, ссылка на мониторинг, минута, на которой происходит проверка состояния и обновляется информация о счёте на сервере, а также ссылка на скриншот. Нужно учитывать, что сервер обычно имеет какой-то лимит одновременно открытых сеансов подключения по FTP протоколу. Поэтому в случае нескольких одновременно открытых сеансов можно получить сбои при копировании данных, если есть ограничения на стороне сервера. Я лично для надёжности всегда провожу копирование данных через один одновременно открытый сеанс, который происходит с интервалом в минуту для каждого следующего счёта. В одном часе 60 минут. Я не думаю, что это вообще кому-то пригодится, но, тем не менее, при количестве счетов более 60 можно перейти на более частый интервал между сеансами, например 30 сек.

Мониторинговый эксперт содержит в себе условие, которое позволяет публиковать данные не только в определённую минуту, но также и при изменении количества открытых позиций, или отложенных ордеров для более оперативного обновления информации на сервере. Это условие расположено в строках 76-109. При изменении количества открытых или отложенных ордеров будет осуществляться внеочередное копирование новых файлов на сервер. Для исключения образования слишком большого количество параллельно открытых сеансов связи печать на каждом терминале осуществляется с некоторым случайным разбросом времени на интервале в 2 минуты. Иногда при совпадении времени печати один из терминалов не может обновить информацию. Но такое происходит крайне редко. Но желающие могут увеличить случайный интервал до 5-10 минут при большом количестве терминалов для гарантированной публикации оперативной информации по всем имеющимся счетам при изменении торговых позиций и отложенных ордеров.

В строке 120 формируется файл скриншота экрана, на котором работает мониторинговый эксперт. Примеры экранов приведены в предыдущей части.

В строках 126-166 происходит расчёт данных по риску открытых позиций и по отложенным ордерам.

В строках 169-190 формируется массив с логами, который пишет торговый эксперт в ходе своей работы. Логи, как это ни удивительно звучит, тоже получаются через глобальные переменные, формируемые торговым экспертом в ходе своей работы. На первый взгляд используемое решение с использованием глобальных переменных выглядит крайне коряво и неуклюже, и было бы гораздо проще читать напрямую лог-файл терминала. Но оно обусловлено тем фактом, что терминал МТ4 пишет логи сначала в буфер в оперативной памяти и только лишь затем, после его заполнения, записывает логи в файл на диске. Таким образом, в самом терминале можно видеть логи, которые ещё не были записаны на диск в течение целых суток! На мой вопрос к компании Metaquotes о возможных способах организации прямой записи всех логов сразу же в файл на диске компания ответила, что имеющийся режим работы обусловлен заботой исключительно о моём жёстком диске с целью исключения частых перезаписей лог файла на него. То есть получается, что компания-разработчик МТ4 в очередной раз решила за людей что именно для них  благо, а что нет, не принимая во внимание реальные потребности пользователей МТ4. В общем с записью логов в файл сложилась ситуация аналогичная разработке МТ5 терминала, заточенного исключительно под фондовый рынок, и который изначально был абсолютно не пригоден к торговле, к которой привыкли все пользователи продукта МТ4 за многие годы работы. И через много лет компании Metaquotes всё же пришлось все полезные наработки по развитию языка MQL переносить из нового МТ5 в более старый МТ4 вместо того, чтобы изначально сохранить уже имеющийся торговый функционал в новом продукте МТ5, дополнив его новым для работы на фондовом рынке. И как результат компания вынуждена и по сей день осуществлять поддержку и развитие параллельно двух версий продукта МТ4 и МТ5 вместо одной, как это традиционно происходит в мире софта.

В торговом советнике для организации такого режима передачи информации о логах, которые он пишет, используется функция _Print(), текст которой размещён в отдельном файле _Print_function.txt. Откорректировать любой торговый советник на предмет использования функции _Print() не составит никакого труда, поскольку для этого нужно лишь разместить текст из моего файла в советнике и автоматической заменой поменять “Print” на “_Print”. Это очень легко и быстро сделать.

В строчках 193-206 формируется файл log.html с расширенной информацией о счёте. В файл вносятся следующие данные: текущее локальное время, название счёта, ссылка на мониторинг счёта (при наличии), загрузка процессора на торговом сервере, количество открытых позиций и отложенных ордеров, прибыль открытых позиций, риски открытых позиций и отложенных ордеров, версии торгового и мониторингового экспертов, лог торгового эксперта (последние 22 записи).

В строках 208-230 формируется файл nearest_orders.html с информацией о ближайших отложенных ордерах.

Функция terminal_checks_function(), расположенная в строках 390-526, формирует файл сhecks_result.html, содержащий информацию об итогах мониторинговых проверок.

Какие проверки в ней выполняются, и что именно записывается в итоговый файл? В файл записывается следующая информация:
  • Время запуска мониторинговой проверки;
  • Версия релиза торгового советника;
  • Разрешение на авторторговлю в терминале; 
  • Наличие подключения к брокеру; 
  • Разрешение автоторговли на стороне брокера; 
  • Наличие в логах торгового советника подстроки “EM:”, говорящей об ошибках в работе торгового эксперта; 
  • Время последнего прогона кода торгового советника (оно должно быть не позже 14 минут назад);
  • Результат проверки объёма отложенных ордеров (осуществляется торговым советником с занесением результата проверки в глобальные переменные);
  • Проверка времени последнего запуска функции расшифровки ошибок торговых операций (оно должно быть более суток назад для прохождения проверки);
  • Финальный результат всех вышеперечисленных проверок.
На основании финального результата на экране, на котором работает мониторинговый эксперт, рисуется зелёный, или красный прямоугольник в зависимости от итогового статуса TRUE (все проверки прошли успешно) или FALSE (провал прохождения одной или нескольких проверок).

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


Заключение

Исходя из представленной выше информации видно, что это не готовый продукт, который можно быстро “запустить из коробки” и использовать через 5 секунд, а скорее всего один из возможных примеров технической реализации мониторинга счетов МТ4, реализованный через формирование текстовых (html) файлов и отправки их на веб-сервер. То есть для запуска данной мониторинговой системы трейдерам-управляющим придётся приложить определённые усилия для того, чтобы со всем этим разобраться. 

Но я считаю, что оно того действительно стоит! Потраченные дни на запуск подобного мониторинга впоследствии обернутся комфортом управления крупными средствами инвесторов и душевным спокойствием, когда управляющий, находясь в любом месте, где есть интернет, сможет, взглянув всего лишь только на один экран телефона, быть спокоен и уверен, что всё у него РЕАЛЬНО НАХОДИТСЯ ПОД КОНТРОЛЕМ и он может заниматься другими делами без регулярного полирования глазами экрана монитора, где у него крутятся десятки самых разношёрстных счетов, работающих у разных брокеров. В общем, успехов другим управляющим в настройке аналогичной мониторинговой системы на своих счетах! Вопросы можно задавать как здесь на сайте, так и в моей группе ВК https://vk.com/solandr.

А вопросы обязательно появятся, так как просто невозможно рассказать про абсолютно все программные вещи в рамках более-менее читабельной статьи, особенно когда люди ранее с этими вопросами не сталкивались. Я лично потратил много месяцев, работая как над самой идеологией мониторинга, так и над технической реализацией боевой системы “под ключ”. Теперь же с помощью представленного готового к использованию и настройке программного кода это время для трейдеров-управляющих может сократиться всего лишь до считанных дней.


Пару слов от Домоседа

Я очень благодарен Андрею за то, что он согласился поделиться с нами своими наработками в области мониторинговой системы. Подтверждаю, что подобное решение необходимо каждому управляющему в управлении которого находится более 8-10 торговых счетов. Более того, это даже не "наработки", это реально готовое решение, которое по мере необходимости можно спокойно "допиливать" под свои потребности.

Я так же создаю мониторинговую систему следящую за управляемыми мной торговыми счетами основываясь на решениях Андрея описываемых в этой статье.

Поделиться в соцсетях