Об этом кейсе есть информация в статье, также я отвечал на похожий вопрос в коментариях ниже. Телеграм замониторен, если он упадёт, мы об этом узнаем и будет автоматически активирован резервный способ оповещений (это может быть что угодно sms/почта/sip телефония/другой мессенджер) и на всякий случай повалятся алярмы, чтобы разбудить дежурного, даже если если всё кроме телеграма работает.
Если телеграм сломается у дежурного — сработает механизм экстренного канала, об этом тоже в статье.
Да, кстати, если дежурный не среагировал на аварию через телеграм, ему через 15 минут будет звонит робот на мобильный/домашний — это как раз резервный механизм оповещения, об этом я не стал упоминать в статье, потому что технической реализацией пока не готов поделиться.
Не понял проблему с тем, что сложно понять где сервис починился, а где сломался. У нас сервис легко идентифицировать по уникальному сочетанию hostname — servicename и если последнее сообщение для него RECOVERY, значит с ним всё порядке, если же другое — значит до сих пор лежит.
С другой стороны согласен, что когда сообщений не 3, а 33 — это проблема и «апки для мобилки» не хватает, поэтому мы тоже пользуемся aNag.
На счёт замечания про icinga2 — спасибо за предложенное вами решения.
В конце статьи я довольно подробно описал, почему мы не используем «настоящего» бота, с блекджеком и REST API. Не совсем уловил связь между статьёй и предложенным вами сервисом. Не могли бы вы раскрыть свою мысль чуть подробнее, пожалуйста.
Не знал, что существует такая вещь, как «облачный мониторинг с SLA». Спасибо за расширение моего кругозора, я обязательно взгляну на эту систему и изучу её возможности, может быть и для нас эта вещь окажется незаменимым инструментом.
Я думаю используемый подход к мониторингу всегда обусловлен бизнес-требованиям и другой спецификой компании.
Возможно подход с SLA для нас не подойдёт, в случае серьёзного многочасового простоя ключевых сервисов прямые потери компании будут очень большие, что наврятли кто-то захочет возмещать(нам же придётся ещё доказывать, что из-за недоставленный сообщений всё случилось), а в случае относительно незначительной аварии, возмещение этих потерь не будет для нас вопросом горящим и на Телеграм мы не обидимся. Разумеется у нас есть и автоматические сценарии для фаловеров и автоматический «хилинг» каких-то поломок, основная задача — обслуживание распределённого кластера.
Кроме того, самое страшное не те деньги, что мы сможем посчитать и выставить в счёт по SLA, их и так можно снова заработать, пускай даже за месяца работы. Самый неблагоприятный сценарий — это потеря лица компании на рынке и восстановление репутации годами. Надеямся, что и Телеграму свой авторитет подставлять не хочется и они будут и дальше делать всё для того, чтобы работать стабильно и без серьёзных сбоев.
Работа описанной в статье связки нас не подводит и мы ей доверяем, её разовый отказ мы переживём, если косяки начнутся на регулярной основе, разумеется задуемся о миграции куда-то в срочном порядке, например на pagerduty.
В то же время, нам, как OPs отделу, нравится держать всё у себя и под своим чутким контролем. Как вы правильно заметили, если бесплатный чатик от Дурова сломается, мы об этом узнаем и ситуация быстро вернётся под контроль.
Мы также используем бесплатный Linux, если на экране появится Kernel Panic, нам это тоже никто не возместит, к сожалению.
Самый подробный материал на эту тему, известный мне, собран в этой статье. Обычная версия Nagios, как 3я, так и 4я, безусловно, не выглядит как современный способ мониторинга чего-либо и мы и в правду не против переехать на Icinga, Zabbix или другой активно развивающийся софт, но ещё не определились с выбором.
Хотя статья, на самом деле, вовсе не про Nagios и даже не про Telegram.
Спасибо за замечание. Да, конечно же, мы слышали про Slack, но так сложилось, что в компании используется Telegram, он нам нравится и переезжать с него на другой мессенджер пока что не планируем.
Как же «простое». Статья предполагает понимания что такое «ip адрес» от учителя. Узнать они его, многие большинство, не умеют. Умеют только по учебнику его как-то с маской подсети складывать в лучшем случае. Про цикл копирования ssh ключей я вообще молчу.
Может чуть автоматизировав всё это дело действительно хорошо получится.
В любом случае советую ознакомится с моим опытом по ссылке выше.
denis_l_eryomin Вы привели несколько интересных примеров в своей статье, но они будут полезны лишь единицам людям, по крайней мере в это стране, потому что:
1) На большинстве компьютеров в школах — винда
2) Даже если где-то и есть Linux, тот чувак, который его настроил, не будет заниматься тем, чем вы предлагаете, скорее вернёт винду на место
3) Ваше решение довольно сложное, новичок Linux не справится, а никаких интерактивных скриптов к статье вы не приложили
ИМХО, учителям и ученикам нужны «однокнопочные» кроссплатформенные решения.
В своё время я предпринял попытку создать такой концепт и выигрывал со своим проектов много первых мест в старших классах, в университетах, международных конкурсах и так далее, но оказалось, что ни эти призы ничего по жизни не дают, ни сам проект, как и другие инновации, не приносящие бабла, никому не нужны.
С++ вроде как обладает теме же свойствами «порядка», но ничем не сложнее, зато живой язык и скомпилировать код куда проще на современных ОС или даже в онлайн компиляторе, почему же не его использовать?
А образование да, вы правы, по всем предметам «отсталое» во всех смыслах.
по первому пункту большое спасибо за подробное описание
вот мой тикет в битрикс, где они признали баг
Здравствуйте, у меня Apache работает в режиме MPM-ITK
и скрипт restore.php вываливается с ошибкой
short_open_tag parameter must be turned on in php.ini
несмотря на то, что в php.ini я выставляю
short_open_tag = On (пробовал short_open_tag = 1)
и значение применяется как на Master так и на Local value (видно через phpinfo)
Дело в том, что в скрипте restore.php срабатывает условие вхождения в самый первый if
if (ini_get('short_open_tag') == 0)
для PHP в режимах CLI, CGI и Prefork ini_get('short_open_tag') возвращает строку(string) «1», php приводит значение «1» типа string в числовой тип, сравнивает число 1 с числом 0 и скрипт продолжает своё выполнение нормально, так как if (false)
но PHP в режиме MPM-ITK ini_get('short_open_tag') возвращает строку On и после приведения типов sting On это int 0
соответственно if (true) и скрипт завершает работу
И так, два вопроса
1) Возможно ли рассмотрения изменения условий проверки этих условий в отделе разработки. Возможно можно было бы сделать так или так
if (ini_get('short_open_tag') === 0)
if (ini_get('short_open_tag') == «0»)
2) Могу ли я как-то обойти эту проверку, чтобы воспользоваться скриптом? Если я меняю скрипт restore.php руками, то он автоматически скачивается снова и мои правки затираются.
Штатная показывает 1.65сек, мол медленно, в панели производительности все оптимально, xcache стоит.
Если телеграм сломается у дежурного — сработает механизм экстренного канала, об этом тоже в статье.
Да, кстати, если дежурный не среагировал на аварию через телеграм, ему через 15 минут будет звонит робот на мобильный/домашний — это как раз резервный механизм оповещения, об этом я не стал упоминать в статье, потому что технической реализацией пока не готов поделиться.
С другой стороны согласен, что когда сообщений не 3, а 33 — это проблема и «апки для мобилки» не хватает, поэтому мы тоже пользуемся aNag.
На счёт замечания про icinga2 — спасибо за предложенное вами решения.
Я думаю используемый подход к мониторингу всегда обусловлен бизнес-требованиям и другой спецификой компании.
Возможно подход с SLA для нас не подойдёт, в случае серьёзного многочасового простоя ключевых сервисов прямые потери компании будут очень большие, что наврятли кто-то захочет возмещать(нам же придётся ещё доказывать, что из-за недоставленный сообщений всё случилось), а в случае относительно незначительной аварии, возмещение этих потерь не будет для нас вопросом горящим и на Телеграм мы не обидимся. Разумеется у нас есть и автоматические сценарии для фаловеров и автоматический «хилинг» каких-то поломок, основная задача — обслуживание распределённого кластера.
Кроме того, самое страшное не те деньги, что мы сможем посчитать и выставить в счёт по SLA, их и так можно снова заработать, пускай даже за месяца работы. Самый неблагоприятный сценарий — это потеря лица компании на рынке и восстановление репутации годами. Надеямся, что и Телеграму свой авторитет подставлять не хочется и они будут и дальше делать всё для того, чтобы работать стабильно и без серьёзных сбоев.
Работа описанной в статье связки нас не подводит и мы ей доверяем, её разовый отказ мы переживём, если косяки начнутся на регулярной основе, разумеется задуемся о миграции куда-то в срочном порядке, например на pagerduty.
В то же время, нам, как OPs отделу, нравится держать всё у себя и под своим чутким контролем. Как вы правильно заметили, если бесплатный чатик от Дурова сломается, мы об этом узнаем и ситуация быстро вернётся под контроль.
Мы также используем бесплатный Linux, если на экране появится Kernel Panic, нам это тоже никто не возместит, к сожалению.
Хотя статья, на самом деле, вовсе не про Nagios и даже не про Telegram.
многиебольшинство, не умеют. Умеют только по учебнику его как-то с маской подсети складывать в лучшем случае. Про цикл копирования ssh ключей я вообще молчу.Может чуть автоматизировав всё это дело действительно хорошо получится.
В любом случае советую ознакомится с моим опытом по ссылке выше.
1) На большинстве компьютеров в школах — винда
2) Даже если где-то и есть Linux, тот чувак, который его настроил, не будет заниматься тем, чем вы предлагаете, скорее вернёт винду на место
3) Ваше решение довольно сложное, новичок Linux не справится, а никаких интерактивных скриптов к статье вы не приложили
ИМХО, учителям и ученикам нужны «однокнопочные» кроссплатформенные решения.
В своё время я предпринял попытку создать такой концепт и выигрывал со своим проектов много первых мест в старших классах, в университетах, международных конкурсах и так далее, но оказалось, что ни эти призы ничего по жизни не дают, ни сам проект, как и другие инновации, не приносящие бабла, никому не нужны.
Если интересно, можете ознакомится
А образование да, вы правы, по всем предметам «отсталое» во всех смыслах.
я обычно настраивал через файлик .settings_extra.php
вот один из довольно «тяжёлых» сайтов на сервере, развёрнутом по этой статье
и скрипт restore.php вываливается с ошибкой
short_open_tag parameter must be turned on in php.ini
несмотря на то, что в php.ini я выставляю
short_open_tag = On (пробовал short_open_tag = 1)
и значение применяется как на Master так и на Local value (видно через phpinfo)
Дело в том, что в скрипте restore.php срабатывает условие вхождения в самый первый if
if (ini_get('short_open_tag') == 0)
для PHP в режимах CLI, CGI и Prefork ini_get('short_open_tag') возвращает строку(string) «1», php приводит значение «1» типа string в числовой тип, сравнивает число 1 с числом 0 и скрипт продолжает своё выполнение нормально, так как if (false)
php.net/manual/ru/function.ini-get.php (string ini_get ( string $varname ))
php.net/manual/ru/language.operators.comparison.php ( == принудительно делает преобразование типов)
но PHP в режиме MPM-ITK ini_get('short_open_tag') возвращает строку On и после приведения типов sting On это int 0
соответственно if (true) и скрипт завершает работу
И так, два вопроса
1) Возможно ли рассмотрения изменения условий проверки этих условий в отделе разработки. Возможно можно было бы сделать так или так
if (ini_get('short_open_tag') === 0)
if (ini_get('short_open_tag') == «0»)
2) Могу ли я как-то обойти эту проверку, чтобы воспользоваться скриптом? Если я меняю скрипт restore.php руками, то он автоматически скачивается снова и мои правки затираются.
именно xcache, а не opcache?
вы уверенны, что в phpinfo(); short_open_tag показывается как включённый?
настройка в bx/bx_apache.conf ничем не должна отличаться от php.ini и вызывать каких-то проблем…
Штатная битриксовая проверка производительности сайта что показывала при этом?