Есть два типа людей – которые уже делают мониторинг
своего веб-сервиса, и которые скоро начнут это делать.
В этом материале мы с вами разрушим 5 мифов о мониторинге и раскроем 5 фактов, которые нужно знать любому кто владеет достаточно серьёзным бизнесом в онлайне.
Вам пока везёт. У вас ещё ни разу не падал сайт во время вашего выступления на конференции. У вас нерадивые сотрудники случайно не удаляли важный контент. У вас не пропадал файл главной презентации продукта, о чём вы узнавали через неделю от своих инвесторов. У вас не возникало ошибок программного обеспечения (“движка”) сайта, в результате которых на экран высыпались диагностические сообщения и всё переставало работать.
Раскрою секрет – абсолютное большинство системных администраторов, даже если они просиживают штаны в вашем офисе (а не удалённо), не сидят круглосуточно за отслеживанием ситуации на ваших серверах. Ведь обычно всё работает (см. миф 1), а когда перестанет – вы ведь сразу им позвоните. Однако подумайте, что вы услышите в ответ на звонок сисадмину в 9 утра воскресенья после его бессонной ночи с заболевшим маленьким ребёнком. Думаю, вы сможете пополнить ваш запас обсценной лексики. А какие блага вам придётся сулить, упрашивая чтобы кто-то остался трезвым на новогодние каникулы?
Рад за вас, что вы можете тратить многократно больше денег на “железо”, чем это требуется. Возможно, благодаря избыточной мощности вы защищены от ddos-атак. Однако, никакое “железо” не спасёт вас от таких банальных вещей как ошибки в программном обеспечении сайта или переполнение жёсткого диска. Если вам не доводилось видеть, как лог ошибок возрастает до 600 гигабайт буквально за минуты – и забивает всё свободное место – то у вас ещё всё впереди.
Безусловно, хостер скорее всего обнаружит, что ваш сервер упал, и направит вам уведомление. Однако реальность состоит в том, что между нормальной работой и “уже упал” есть бесконечное число градаций, а проблемы развиваются по нарастающей. Сначала откажет часть какого-либо внутреннего функционала вашей CMS, затем начнёт притормаживать база данных (например, на функциях заказа ваших продуктов), затем часть страниц с “динамическими” блоками перестанет открываться по таймауту (видели 504 Gateway Timeout? – это оно).
Затем переполнится допустимое число соединений с БД, на страницах начнут “высыпаться” ошибки, и большинство страниц и функций сайта перестанут работать вообще. При этом главная страница, особенно если она у вас технически оптимизирована под нагрузку (её часто оптимизируют, так как на неё приходит больше всего траффика), честно останется жить до конца. А ведь большинство “сторонних” решений будет отслеживать только основной адрес вашего сайта – главную страницу, ведь они не могут извне получить доступ и узнать что происходит “внутри” вашего сервера.
Когда сервер упадёт, хостер предложит вам перезагрузить его, а в случае физической неисправности – подождать 2-3 дня для замены. У хостеров, как правило, нет в резерве большого выбора серверов, и нужно время чтобы их переарендовать. Однако с причинами и последствиями падения вам придётся разбираться самостоятельно, и тратить дополнительные деньги на восстановление всего функционала, миграцию на новый сервер, восстановление траффика, разъяснения с клиентами и партнёрами и т.д.
7 августа в 21:13 молния ударила в трансформатор датацентра Amazon в Ирландии, что привело к его полному отключению.
7 сентября в 00:05 по московскому времени датацентр Hetzner сообщил, что его магистральный кабель повреждён в ходе экскаваторных работ. Восстановление заняло несколько дней.
Этот список можно продолжить. Следует помнить, что за красивыми словами об “облаках” скрываются всё те же самые сервера, каналы, маршрутизаторы и люди. Оцените вероятность ущерба, особенно если вы (как в мифе 4) полагаетесь на своего хостера. Реальность состоит в том, что сайты и сервера “падают”, это факт, и владельцу бизнеса нужно понимать, как предотвратить такую угрозу.
Однако не всё так печально. К счастью, всё уже давно придумано до нас, и остаётся лишь воспользоваться готовыми решениями. Вот факты, которые вам нужно знать:
Следует мониторить скорость её загрузки, контент, наличие необходимых слов в тексте и отсутствие сообщений об ошибках. Также можно и нужно мониторить особо ресурсоёмкие (например, фильтр по каталогу) или особо важные для бизнеса страницы (например, форму заказа). Современные решения позволяют отслеживать, например, факт нарастания времени загрузки – и сигнализировать об этом.
Одна латвийская компания предлагает решение “под ключ” за 800 евро. Однако следует знать, что стоимость услуг аналогичных SaaS-сервисов не превышает расходов на вечерние покупки в продуктовом магазине, и соизмерима с заправкой вашего автомобиля бензином на пару недель.
Именно автоматическое отслеживание ситуации внутри сервера может дать сигнал о начале проблемы за какое-то время до того, как она приведёт к фатальным ошибкам вашего сервиса, – что даст вам (или вашим сотрудникам) время чтобы прореагировать и исправить её. В то время как другие компании реагируют только по факту обнаружения “видимой невооружённым глазом” проблемы, вы сможете предотвратить угрозу задолго до её развития.
Как сторонний мониторинг может узнать, что происходит внутри? Очень просто: на ваш сервер устанавливается небольшая программа (“клиент”), которая потребляет лишь доли ресурсов, однако “снимает” несколько десятков или даже сотен показателей. С заданной периодичностью (например, 30 секунд) информация отправляется в SaaS-службу мониторинга, который анализирует изменения и принимает решения о тех или иных действиях.
Возможно, она даже не успеет послать вам уведомление. В этом ключе особенно выгодно пользоваться SaaS-решениями, которые избавляют вас от необходимости аренды, настройки и содержания дополнительного сервера для службы мониторинга.
Не следует относиться к мониторингу как к простой системе уведомлений одного человека (вас) о проблемах на сервере. В конце концов, вы можете не быть техническим специалистом, вы можете быть в отпуске, вы можете заниматься другими важными делами. Профессиональная служба мониторинга подразумевает не просто уведомление о проблемах, но и ступенчатую эскалацию проблем, и даже автоматические действия – например, отдачу команды на перезагрузку какого-либо процесса или всего сервера.
Эскалация – это настройка ступенчатых уведомлений, которая, например, сначала уведомляет дежурного системного администратора, затем (в случае если проблема не решается) через некоторое время отправляет сообщение его начальнику, а если и это не поможет – другим людям в вашей компании или лично вам. В качестве последней меры система мониторинга может сама отдать запрограммированную команду, которая выполнится на вашем сервере – например, чтобы обнулить логи и содержимое временной директории, перезапустить зависший процесс, или перезагрузить сервер целиком.
Оригинал: http://www.dobryakov.com/blog/1299/
Проведите конкурс среди участников CMS Magazine
Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.
Директор по производству в Тактика
В своей работе мы часто встречаемся с различными проблемами на серверах наших клиентов. Кто-то постоянно падает, у кого-то время загрузки/отклика большое, у третьих скорость низкая и т.д. Из-за нестабильных серверов бюджеты по контекстной рекламе могут улетать «в трубу». А до сайтов, которые находятся в продвижении, не может «достучаться» бот поисковой системы, и всё может закончиться печально.
Во избежание подобных ситуаций, мы сделали простейший сервис «простукивания» сайтов. Сервис с заданной периодичностью проверяет доступность сайтов клиентов. И, если сайт недоступен, отправляет уведомление на почту нашему проект-менеджеру и клиенту. В течение5-10 минут поднимается паника, и проблема устраняется существенно быстрее.
Кстати, сделать уведомление о недоступности сайта по SMS, не так и сложно. Для этого всего лишь надо завести отдельную электронную почту на Mail.ru и настроить оповещение по SMS о новых входящих письмах. При недоступности какого-то сайта, сервис отправляет письмо на этот e-mail, а Mail.ru отправляет SMS оповещение о новом письме. Всё просто.
На второй стадии мы сделали оповещения об изменениях контента страниц на сайтах клиентов. Это особенно важно для тех сайтов, которые находятся на продвижении. Часто тексты, мета-теги, содержимое тегов <title> на целевых страницах продвигаемых сайтов изменяется по каким-либо причинам. Система своевременно уведомляет менеджера о случившихся изменениях. Таким образом, мы выявляем проблему практически моментально, не дожидаясь индексации не желаемых изменений поисковыми системами. Или, что еще хуже, «падения» сайта по каким-то поисковым запросам.
Вся система, кстати, находится на стороннем сервере.
А за идею про «факт нарастания времени загрузки» — спасибо, очень интересно. Возможно, будем внедрять у себя.