Автоматический мониторинг ошибок в терминале - какие есть решения? - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
А зачем костылить свой пинг понг? Когда можно обойтись штатными средствами.
Это ненадежно. Для галочки так сделать можно, но будет работать только в тепличных условиях - как раз это костыль. Случаи зависания/падения терминала или MQL-программы, перезагрузки VPS (абсолютно надежных нет), когда коннект рапортуется нормально, а тиков в торговый день почему-то нет (баги разные бывают, МТ - многозвенная архитектура) и пр. остаются за кадром. Если требуется мониторить боевую торговлю, там нет мелочей. В соседней ветке недавно пролетало, как терминал забил диск логами до отказа, например, значит и диск надо мониторить. Для надежного мониторинга онлайн сервисов (коим и онлайн-торговля является) производится куча сложного специального софта. Не обязательно брать что-то из этого целиком, но можно хотя бы присмотреться и от этого свои решения строить.
PS. Прикладной ping работает по обратному принципу: терминал должен периодически (довольно часто) посылать во внешний мир пакеты со статусом основных подсистем (включая параметры роботов), а на внешнем сервере при неполучении очередного пакета нужно бить тревогу (отправлять оттуда sms-ы и пр.)
Это ненадежно. Для галочки так сделать можно, но будет работать только в тепличных условиях - как раз это костыль. Случаи зависания/падения терминала или MQL-программы, перезагрузки VPS (абсолютно надежных нет), когда коннект рапортуется нормально, а тиков в торговый день почему-то нет (баги разные бывают, МТ - многозвенная архитектура) и пр. остаются за кадром. Если требуется мониторить боевую торговлю, там нет мелочей. В соседней ветке недавно пролетало, как терминал забил диск логами до отказа, например, значит и диск надо мониторить. Для надежного мониторинга онлайн сервисов (коим и онлайн-торговля является) производится куча сложного специального софта. Не обязательно брать что-то из этого целиком, но можно хотя бы присмотреться и от этого свои решения строить.
PS. Прикладной ping работает по обратному принципу: терминал должен периодически (довольно часто) посылать во внешний мир пакеты со статусом основных подсистем (включая параметры роботов), а на внешнем сервере при неполучении очередного пакета нужно бить тревогу (отправлять оттуда sms-ы и пр.)
Да, я понимаю проблематику, конечно соглашусь, что пинг понг надёжнее мониторинг, но это уже выходит за рамки текущих штатных возможностей терминала. Кроме клиента сокета и вебреквеста.
Так как действительно, если терминал упадёт, то не как мы это не узнаем, только сторонним софтом. Или через WinAPI можно попробовать мониторить процесс терминала, и куда то слать отчёт.
По этому в текущей ситуации можно комбинировать задачи. Какие то задачи поручить сервисам, а критичные задачи, в виде мониторинга падения, на сторонний софт, или WinAPI.
Ещё как вариант, можно подумать над облачными технологиями типа serverless. И туда слать пакет, со своим набором флагов. А там уже как хочешь так и обрабатывай.
Но это уже требует понимания работы с облачными сервисами, хотя бы на начальном уровне.
Мониторить внутреннее состояние терминала можно только изнутри терминала. Логи на диске будут с задержкой, а других данных для анализа нет.
Осталось определиться со списком "нештатных ситуаций", которые нужно отслеживать.
можно вот таким способом :
https://www.mql5.com/ru/blogs/post/729896
набросать робот/индикатор который публикует состояние на внешний (в примере дан локальный) MQTT сервер и время от времени посылает heat-beat
любым скриптом (или разных гуев, есть и под андроид) можно всё увидеть..
Мониторить внутреннее состояние терминала можно только изнутри терминала.
Ошибаетесь
Ошибаетесь
Я вижу на картинке отпарсенный журнал. Это сделать элементарно. Не вижу, что сообщения в журнале появляются без задержки. Я не знаю,есть ли задержка при выводе в журнал, не проверял. Но судя по тому, что в терминале многие вещи делаются отложенно, пакетами, то возможно.
Я вижу на картинке отпарсенный журнал. Это сделать элементарно. Не вижу, что сообщения в журнале появляются без задержки. Я не знаю,есть ли задержка при выводе в журнал, не проверял. Но судя по тому, что в терминале многие вещи делаются отложенно, пакетами, то возможно.
когда нужно тик-в-тик то конечно надо писать сов/индикатор/сервис который это дело осуществляет
а когда скорость ответной реакции от 3-5- минут (быстрее на писк телефона ничего не сделаешь), то парсить логи самое то. Внешний софт, не требующий никаких вообще вмешательств в работу терминала
и кэширование журналов, это та ещё идея от разработчиков :-) потому как журналы обычно пишутся без кешей. на всех уровнях проставляются галочки - "максимально гарантировать физическую запись данных"
когда нужно тик-в-тик то конечно надо писать сов/индикатор/сервис который это дело осуществляет
а когда скорость ответной реакции от 3-5- минут (быстрее на писк телефона ничего не сделаешь), то парсить логи самое то. Внешний софт, не требующий никаких вообще вмешательств в работу терминала
Я ответил к тому, что:
Логи на диске будут с задержкой
Ошибаетесь
А по поводу
и кэширование журналов, это та ещё идея от разработчиков :-) потому как журналы обычно пишутся без кешей. на всех уровнях проставляются галочки - "максимально гарантировать физическую запись данных"
Я, когда пишу свои логи, всегда использую FileFlush(). Ну, хотя бы...
В принципе разработчикам терминала, не составит труда придумать реализацию.
Что бы функция слала как пользовательские сообщения, так и из списка всех не штатных ситуаций, даже в момент падения терминала.
Вот это круто было бы. Если разработчик читает, возьмите идею на подумать.