Зачем нужен мониторинг серверов?
Мало просто создать компьютерную инфраструктуру. За ней нужно ещё и присматривать, ведь в ней могут возникнуть какие-то неисправности. Причём, в данном случае не очень важно, идёт ли речь об аппаратных серверах или о виртуальных — сегодня в прикладном смысле их можно не различать. В ходе мониторинга о наблюдаемом объекте собирают сведения, по которым можно своевременно узнать о возникновении проблемы и, соответственно, незамедлительно начать принимать меры по её устранению. В принципе, имеются универсальные извещатели о проблемах — пользователи информационной системы. Но сообщения от них всегда приходят позже, чем о них должен был бы узнать системный администратор. Представьте, бухгалтерская система перестала работать поздно вечером. Но её пользователи начнут сообщать о неисправности только утром, когда не они смогут исполнять свои служебные обязанности. Кроме того, не все технические проблемы сразу проявляются в пользовательском интерфейсе или проявляются в нём однозначно. В самом простом варианте мониторинга проверяют лишь факт работоспособности наблюдаемого объекта. Однако мониторинг может выявлять не только уже возникшие проблемы, но и те, вероятность появления которых возрастает. Например, наблюдение за объёмом свободной дисковой или оперативной памяти может предупредить о приближающемся их дефицита. Здесь следует сделать одно уточнение. Сбор данных бывает «контактным» или «дистанционным». В первом случае наблюдение ведётся программами, работающими на самом наблюдаемом сервере (их часто называют агентами). Во втором — программами, работающими на других компьютерах и наблюдающими по сети. Во многих случаях для выявления самого факта функционирования оборудования, достаточно просто отправить ему некий запрос по сети, дождаться ответа и сравнить его с ожидаемым. В связи с тем, что сегодня практически все информационные системы используются через интернет или, по крайней мере, через локальную сеть, далее мы будем рассматривать только дистанционный мониторинг.
За чем наблюдать?
Как уже было сказано, во время мониторинга можно фиксировать самые разные характеристики наблюдаемого объекта. Обычно в связи с компьютерной инфраструктурой требуется проверять функционирование серверов и служб, работающих на них. В Windows по-английски эти службы называются services, а в Linux — demons или daemons. Работу служб обеспечивает операционная система сервера. Если перестала нормально действовать операционная система, проверять работоспособность его служб бессмысленно. Но при нормально работающей операционной системе сбой в работе одной из его служб вполне возможен, и его нужно вовремя выявить.
Серверы
Для активной проверки работоспособности сервера нужно отправить ему запрос и получить ответ. Самый простой способ проверить работоспособность сервера через интернет: отправить ему служебный запрос ping. Ответ на запрос не только подтвердит работу хоста по указанному IP-адресу, но охарактеризует качество сетевого пути. C:\>ping 1cloud.ru
Обмен пакетами с 1cloud.ru [5.200.50.90] с 32 байтами данных: Ответ от 5.200.50.90: число байт=32 время=3 мс TTL=123 Ответ от 5.200.50.90: число байт=32 время=3 мс TTL=123 Ответ от 5.200.50.90: число байт=32 время=8 мс TTL=123 Ответ от 5.200.50.90: число байт=32 время=3 мс TTL=123 Статистика ping для 5.200.50.90: Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь) Приблизительное время приема-передачи в мс: Минимальное = 3 мс, Максимальное = 8 мс, Среднее = 4 мс
Однако ping-запросы некоторые межсетевые экраны могут блокировать. В таком случае контролируемому серверу можно отправить стандартный запрос на установление соединения по протоколу TCP. Положительный ответ подтвердит работоспособность сервера. TCP-запрос является более универсальным средством проверки работоспособности хоста. Тем не менее, если есть возможность использовать ping-запросы, лучше пользоваться ими. Они создают меньшую нагрузку на наблюдаемый сервер. Важно понимать, что отсутствие ответа далеко не всегда означает, что сам сервер не работает. Источник проблемы может находиться в сети между наблюдателем и наблюдаемым. В таких случаях правильнее говорить не о неработоспобности сервера, а о его недоступности.
Службы
Службы (services и demons) — это программы, работающие на сервере в фоновом режиме и выполняющие какие-то прикладные или системные функции. Пример такой службы: веб-сервер (IIS, Apache, …). В русском языке сложилось так, что сервером могут назвать и аппаратную часть, и операционную систему, и службу. Это создаёт определённую путаницу, поэтому важно уточнять, о чём в данный момент идёт речь. В одной операционной системе может работать много разных служб. Как правило, они привязаны к разным IP-портами, поэтому их доступность можно и нужно проверять отдельно. При этом речь уже будет идти о сетевых протоколах следующего уровня — прикладного. Например, о таких.
| Протокол | Служба | IP-порт |
| FTP | Передача файлов | 20, 21 |
| SSH | Защищённый протокол передачи данных | 22 |
| SMTP | Пересылка электронных писем | 25 |
| DNS | Служба доменных имён | 53 |
| HTTP | Веб-сервер | 80, 8008, 8080 |
| POP3 | Получение электронных писем | 110 |
| IMAP | Получение электронных писем | 143 |
| SSL | Веб-сервер по защищённому протоколу HTTPS | 443 |
| MySQL | База данных | 3306, 3307 |
Как наблюдать?
При организации системы мониторинга возникает много подзадач: откуда наблюдать, как часто проверять, как реагировать и тому подобные задачи.
Место наблюдения
Если прикладная информационная система предназначена для публичного обслуживания неограниченного круга пользователей, и она должна быть доступна из любой точки интернета, то и проверять её доступность нужно из разных мест, в которых могут находиться пользователи. Наличие нескольких точек наблюдения позволяет сделать предварительный вывод о причине возможной недоступности сервера. Если при его очередном опросе ответ не пришёл только в часть точек наблюдения, а в другую — пришёл, это означает, что сам сервер нормально работает, а источник проблемы находится где-то на сетевом маршруте к точкам наблюдения, в которых не был получен ответ сервера. Именно поэтому важно иметь несколько точек наблюдения, причём, достаточно разнесённых друг от друга. Конечно, здесь имеется в виду сетевая разнесённость, которая не обязательно совпадает с географической.
Периодичность
Как часто проверять доступность наблюдаемого сервера? — Вопрос непростой. Чтобы вовремя выявить проблему, опрашивать нужно достаточно часто. Но слишком интенсивные запросы могут заметно увеличить нагрузку как на сам сервер, так и на сетевую инфраструктуру. Оптимальную периодичность следует выбирать с учётом здравого смысла и реальной потребности в быстроте выявления возможных аварийных ситуаций.
Протоколирование
Сведения, порождаемые системой мониторинга, крайне желательно где-то сохранять, например, в log-файлах или базе данных. Эти сведения важны как сами по себе, например, для формальных отчётов или биллинга, так и в качестве источника ценной информации для последующего анализа и улучшения работы прикладной системы. Объём протокольных данных может быть самым разным. Он зависит и от размера наблюдаемой системы, и от её характера или характеристик, и от возможностей системы мониторинга.
Автоматизация
В системе мониторинга было бы мало смысла, если она только регистрировала какие-то данные. — Данные нужно автоматически анализировать, выявлять проблемы и как-то на них реагировать. Самая простая и очевидная реакция на обнаруженную проблему: оповещение о ней системных администраторов. Способы оповещения могут быть разными: электронная почта, SMS-сообщение, сервисы мгновенных сообщений, … В зависимости от организации управления системой, могут быть автоматически приняты какие-то срочные меры по временному преодолению проблемы. Например, модуль управления может самостоятельно отключить неисправные серверы или переключить прикладную систему с основных серверов на резервные.
Локализация и изоляция проблемы
Когда под наблюдением находится сложная информационная система, нужно учитывать, что часть обнаруженных в ней проблем может быть следствием других, более общих. Предположим, мы наблюдаем несколько веб-серверов, которые находятся за общим для них маршрутизатором. Если этот маршрутизатор выйдет из строя, веб-серверы окажутся недоступными из всех точек наблюдения. В такой ситуации важно правильно понять, что первопричина проблемы находится в маршрутизаторе, а не в веб-серверах. В мощных системах мониторинга такая локализация может производиться автоматически. В менее мощных, решать эту задачу приходится самим системным администраторам.
Заключение
- Балансировка нагрузки
- Скорость передачи данных в облаке 1cloud
- Масштабирование в облаке
- Публичность подсети
- Объектное хранилище для файлов в облаке
Как проверить состояние сервера
Невозможно представить работу современного бизнеса, вне зависимости от его масштабов, рода деятельности без серверного оборудования. От того, насколько правильно оно будет подобрано, его изначального качества во многом зависит стабильность, эффективность и продолжительность службы. Но на этом останавливаться на стоит. В рабочем процессе необходимо регулярно выполнять мониторинг серверов. Проверять то, насколько корректно работает система хранения данных, программное обеспечение, службы, сервисы. Это позволит вовремя среагировать на непредвиденные ситуации и исключить серьезные проблемы, чреватые потерей клиентов, прибыли, производственными простоями.
Надо понимать, что сбои может давать даже самая надежная техника. И это не повод для паники. Надо просто регулярно проводить проверку ее работоспособности. Выполнять эти работы вручную – нерентабельно. Сил, времени и денег будет затрачено намного больше, чем эффект от достигнутого. Поэтому работы по контролю над функционированием серверов выполняют автоматизированные системы. Специалисту останется только вовремя реагировать на сбои. Но, обо всем по порядку.
Зачем нужен мониторинг серверов?
Вы работаете системным администратором? Представьте, что ваше привычное утро начинается не с чашки ароматного кофе, а с кучи звонков и сообщений и том, что сервер не работает, трудовая деятельность компании парализована. Согласитесь, ощущения не из приятных. Никто не застрахован от подобной ситуации. Но ее можно предотвратить, если регулярно будет выполняться проверка сервера.
Она позволяет в режиме реального времени следить за производительностью машины, ее функциональностью, заполненностью памяти и выявлять проблему до того, как ее влияние коснется работников офиса, скажется на оттоке покупателей, репутации бизнеса. Предусмотрев заблаговременно комплексный мониторинг серверного оборудования, вы сможете:
- держать под контролем всю аппаратную составляющую машины;
- предотвращать непредвиденные и не особо приятные инциденты со сбоями;
- получать мгновенное оповещение о проблемах, что позволит быстро их решить;
- минимизировать время и затраты труда на ручную проверку функционирования системы.
Соответствующие автоматизированные системы могут работать не только с сервером. Их также можно использовать и для контроля над работой всей корпоративной сети. Особенно актуально это стало при расширении локальных сетей. Сегодня они включают удаленные пользователей, мобильные гаджеты, беспроводные сети облачные технологии, интернет вещей и пр.
Аренда выделенного
сервера
Разместим оборудование
в собственном дата-центре
уровня TIER III.
Конфигуратор сервера
Подбор оборудования для решения Ваших задач и экономии бюджета IT
Какие данные о состоянии сервера позволяет получить его проверка?
Проверка состояния сервера позволяет определить следующие параметры:
- состояние памяти;
- производительность процессора;
- потоки трафика, проходящие через оборудования;
- статус системы охлаждения и температура окружающей среды;
- заполненность HDD или SSD-дисков, если они подключены в вашей машине;
- общее состояние сервера;
- статус заданий.
Этой информации будет вполне достаточно для того, чтобы понять, насколько забита ваша система хранения данных, как работает оборудование, с какими потоками трафика оно сталкивается, насколько загружен центральный процессор и пр. Можно даже определить, насколько эффективно в корпоративных серверах работает система охлаждения. Программа, контролирующая все эти показатели, работает автоматически, предусмотрен режим оповещений. То есть системный администратор сразу же узнает, если возникнет проблема с функционированием сервера.
Как правильно организовать мониторинг серверов
Правильная настройка мониторинга сервера при помощи соответствующего приложения – это только решение части задач, стоящих перед администратором. Он еще должен убедиться в том, насколько корректно работает сам ресурс, не пропадает ли интернет-соединение. Это обеспечит доступность сайта вашей компании или интернет-магазина для потенциальных клиентов, деловых партнеров, покупателей в режиме 24/7. Так, доступность сайта для пользователей стоит проверять каждый час-два. Также комплексный мониторинг будет включать проверку на наличие или отсутствие проблем с:
- Работоспособностью DNS-сервера. Бывают ситуации, когда сайт физически доступен, но его адрес не определяется, или работает он с ощутимыми задержками по времени.
- Стабильностью подключения к базе данных.
- Временем отклика. Особенно это актуально при выполнении «тяжелых» задач.
- Периодическим выполнением технических работ.
Советы специалистов по мониторингу серверов
Обеспечить простой, удобный и эффективный мониторинг состояния сервера помогут советы специалистов:
- Используем готовые решения.
- Обеспечить связь между системой и лицами, которые будут устранять поломки.
- Проведение дополнительных проверок при длительном отсутствии оповещений.
- Исключаем из работы слишком простые метрики.
- Доверьте мониторинг своего сервера специалистам.
Остановимся более подробно на каждом из этих моментов более подробно.
Готовые решения
Процедуры проверки на стороне сервера уже давно стандартизированы и вносить в них корректировки не стоит. Вы ведь не создаете собственную систему контроля версий, веб-сервер, операционную систему. Не стоит экспериментировать и с мониторингом. Здесь уже существуют надежные и проверенные временем решения: Prometheus, Grafana, Netdata, ELK, InfluxData и пр. Среди них есть и бесплатные. После того, как вы определите инструмент мониторинга, стоит выполнить визуализацию состояний. В результате должна получиться страница (панелька) с основными показателями. Так вам будет намного проще и удобнее контролировать их.
Обеспечение взаимодействия
Также стоит сделать так, чтобы соответствующие данные напрямую передавались лицам, которые будут устранять эти сбои, в том числе в виде кодов. Но следует понимать, что в случае возникновения авариных ситуаций визуальный мониторинг может не дать желаемого результата. Дело в то, что в большинстве случаев невозможно понять причину сбоя, только взглянув на панельку. Надо получить как можно больше сопутствующей информации. И здесь существенную пользу окажут оповещения. Они должны быть полезными, информативными и содержать те данные, которые бы хотел получить тот или иной человек. Оповещения должны содержать следующие данные:
- то, насколько серьезная авария;
- какие сервисы, службы она затронула;
- какие показатели могли спровоцировать возникшие сложности;
- какие действия должен предпринять человек (в виде инструкций), который получил соответствующее предупреждения.
Также заранее стоит подобрать подходящий для вашего бизнеса канал оповещения. Это может быть рассылка в мессенджерах, через электронную почту, корпоративную сеть и пр. Надо просто учесть, на какие каналы сотрудники компании среагируют максимально быстро. От этого зависит, насколько быстро будут устранены проблемы.
Нет оповещений – нет проблемы: меняем подход
Еще один совет специалистов: не стоит думать, что, если нет оповещений от системы мониторинга серверов, значит в работе оборудования нет ошибок. Надо понимать, что сбои в работе компьютеров разного уровня сложности – это нормальное явление. И происходить они могут достаточно часто. Ситуация, когда за несколько недель работы не «вылезло» ни одно из подобных оповещений должна вас насторожить. Возможно, при выполнении настроек мониторинга была допущена какая-то ошибка, были подключены не все параметры.
Работу системы мониторинга надо постоянно совершенствовать, улучшать, добавлять новшества. Стоит использовать структурированные логи, чтобы установить наличие скрытых проблем и их первопричин. Можно применять и другие инструменты. Главное, чтобы вы получили информацию, которая позволит выявить сбои и их причины.
Долой простые метрики
Упрощенные метрики для контроля над работой сервера – не вариант, если хотите постоянно быть в курсе происходящего с вашей машиной. Почему этого делать не стоит можно понять на простом примере. Так, есть общедоступный API, выделенный специально под обработку сложных вычислительных задач. В этом случае минимизируется время отклика, пользователь получает ответ на запрос практически мгновенно. Чтобы контролировать такую работу, в настройках мониторинга указана цифра 3 секунды. То есть, если время обработки будет выше, выскочит оповещение с ошибкой.
Вроде бы все выглядит красиво. Но что получаем на практике? В статистике отображается осредненный показатель по всем запросам, ищущим через данный API. Как пример: поступает 100 запросов. 95 из них обрабатывается за 1 секунду. Остальные же 5 – по 30 секунд. Средний показатель скорости обработки – 2,45. То есть получается, что программа не будет информировать вас о сбоях. И 95 ваших клиентов будут полностью довольны скоростью взаимодействия. А вот как быть с теми 5 людьми, которым приходиться ожидать отклика по полминуты?
Это и есть наглядный пример упрощенной метрики. Поэтому от нее и стоит отказаться, чтобы не было недовольных и производительность проверялась бы по каждому пользователю.
Доверяем работы специалистам
Сделать мониторинг серверов профессионально сможет далеко не каждый системный администратор. А низкое качество системы чревато недостаточной эффективностью ее работы. Поэтому пренебрегать компетентной помощью не рекомендуется. И обратиться за этими работами стоит к специалистам компании «Xelent». В этом случае вы сможете на 100% быть уверены в стабильности работы вашего сервера.
За предварительными консультациями можно обращаться к специалистам через онлайн-форму связи или по телефону.
Популярные услуги
Dedicated сервер
Под dedicated сервером подразумевают аренду серверного компьютера для решения задач конкретного проекта. Клиент получает возможность свободно распоряжаться ресурсами виртуальной машины, устанавливать любое программное обеспечение и создавать необходимое количество баз данных.
VDS Windows сервер
Любой постоянно развивающийся интернет-проект в определенный момент своего существования начинает нуждаться в неограниченном трафике. С помощью VPS Windows сервера можно быстро решить проблему с масштабированием ресурсов в рамках крупной системы.
Аренда FTP сервера
Разработчики приложений часто сталкиваются с ситуаций, когда нужно создать backup файлов, но места для его хранения нет. Аренда FTP сервера в Xelent поможет решить эту проблему.
Как проверить, работает ли интернет
Иногда бывает так: компьютер вроде подсоединён к сети, а интернета нет: сайты не грузятся, ютуб не работает, жизнь замерла. При этом значок соединения есть, но по факту ничего не работает. Рассказываем, как проверить, в чём дело, и что можно выяснить до звонка в техподдержку.
Что будем делать
В каждой операционной системе для компьютеров есть две команды, которые чаще всего используются для диагностики работы интернета. Наша задача — выяснить, может ли сама операционная система выходить в интернет или он ей тоже недоступен. Случается такое, что система может выходить в сеть, а программы (браузер, например) — нет. Это значит, что с интернетом всё в порядке, а причину надо искать в программах.
Что понадобится
Чтобы понять, есть ли интернет в принципе, используют две команды:
- ping
- tracert в Windows или traceroute в Linux и MacOS
Это консольные команды, поэтому для работы с ними понадобится командная строка или терминал. Чтобы начать с ним работать в Windows, нажмите сочетание клавиш Win+R, в появившемся окошке напишите cmd и нажмите Enter. В MacOS делается по-другому: нажимаете ⌘+пробел, пишете terminal и нажимаете Enter.
Ping
Командой ping мы проверяем, может ли операционная система связаться с выбранным сервером или сайтом в интернете.
- Компьютер посылает запрос на выбранный сервер и засекает время.
- Как только пришёл ответ от сервера — выводим время, за которое запрос дошёл до места и вернулся обратно.
- Если ответа нет — будет сообщение, что превышено время ожидания.
- Так будет происходить раз за разом до тех пор, пока мы не нажмём Ctrl+С.
Если мы всё время получаем сообщение, что превышено время, то, скорее всего, с интернетом что-то не так: запросы отправляются, но по каким-то причинам не возвращаются. Тут надо уже разбираться с провайдером.
Давайте разберём, что здесь происходит, на примере такой строчки:
64 bytes from 87.250.250.242: icmp_seq=4 ttl=247 time=15.995 ms
64 — это размер нашего запроса в байтах. Его можно сделать больше или меньше для разных случаев.
87.250.250.242 — адрес одного из серверов Яндекса, который отвечает за ya.ru.
icmp_seq=4 — сейчас перед нами будет результат отправки пятого ICMP-пакета (потому что нумерация начинается с нуля).
ttl=247 — время жизни пакета составляет 247 пересылок. Про время жизни поговорим чуть ниже.
time=15.995 ms — запрос до сервера и обратно шёл почти 16 миллисекунд. Этого вполне хватит для обычного использования интернета, но может быть критично много для игр.
В самом конце программа сообщает, что у нас 10 пакетов ушло, 10 пришло и 0% потерь, то есть соединение стабильное.
Что такое TTL, или время жизни пакета
Перед тем, как говорить о следующей команде, расскажем про TTL.
Когда данные разделяются на части для отправки через сеть, это называется пакетом. Основное, что делают сетевое оборудование и служебные сервисы, — получают пакеты и пересылают их дальше. Но бывает так, что по разным причинам пакет начинает ходить по кругу: сервер1 → роутер → сервер 2 → роутер → сервер 1 и так далее. Если таких пакетов станет много, они забьют всю сеть и новые данные отправить не получится.
Решение придумали такое: одним из параметров пакета сделали TTL, что расшифровывается как «Время жизни пакета» (time to live). Каждый раз, когда пакет пересылается от одного устройства к другому (такие пересылки называются «хопами»), это значение уменьшается на 1. Как только этот параметр у пакета станет равен нулю, маршрутизатор удаляет этот пакет.
Tracert или traceroute
В разных операционных системах эта команда пишется по-разному:
- tracert — в Windows;
- traceroute — в Linux и MacOS.
Ещё они немного различаются форматами и параметрами отправляемых пакетов, но в целом делают одно и то же: выводят весь маршрут, который проходит пакет от вашего компьютера до выбранного сервера.
С помощью этой команды сисадмины выясняют, на каком этапе сеть перестаёт работать как нужно и кто виноват: оборудование клиента, общедомовый роутер или сервер провайдера.
Работает это так:
- Компьютер отправляет первый запрос на выбранный сервер и устанавливает ему TTL=1.
- Это значит, что пакет дойдёт только до следующего устройства, например домашнего роутера, и на этом его путь закончится.
- Компьютер показывает время прохода пакета до первого устройства.
- Затем компьютер отправляет второй запрос на выбранный сервер и устанавливает ему TTL=2. Теперь запрос может пройти два устройства — домашний роутер и, например, общедомовый.
- Компьютер показывает время прохождения пакета до второго устройства.
- Так, шаг за шагом, компьютер увеличивает TTL до тех пор, пока пакет не дойдёт до финального сервера.
В итоге мы получаем полную карту прохождения пакета, и если пакет где-то стопорится и дальше не идёт — скорее всего, проблема в этом узле или сразу после него. Так техподдержка выясняет, где поломка и что делать дальше.
Теперь практика. Например, команда traceroute thecode.media покажет весь маршрут пакета до сайта «Кода»:
Время прохождения пакета в миллисекундах здесь уже не так важно, как IP-адреса, которые идут первыми в статистике. В нашем примере маршрут был такой:
- router.lan (192.168.88.1) — домашний роутер;
- 192.168.55.1 — районный роутер провайдера;
- * * * — какой-то сервер или маршрутизатор, который специально не отвечает на trace-запросы, поэтому адреса мы не видим;
- lag-2-435.bgw01.bryansk.ertelecom.ru (109.194.8.18) — сервер городского провайдера в Брянске;
- ertelecom.w-ix.ru (193.106.112.151) — сервер другого провайдера;
- selectel.w-ix.ru и 92.53.93.57 — серверы Селектела, на которых размещается наш сайт;
- 31.184.208.243 — адрес сервера, на котором работает «Код».
А вот как выглядит трассировка до того же сайта, но при подключении через мобильный интернет:
Шагов стало больше, и появилось больше узлов, которые не отвечают на trace-запросы, — это могут быть вышки сотовой связи и внутреннее магистральное оборудование провайдера. На восьмом запросе наш пакет дошёл до сервера 46.229.142.76 — это сетевой узел «Мегафона» в Нижнем Новгороде, через который запросы по скоростному магистральному каналу отправляются в интернет.
Что дальше
Впереди будет ещё несколько практических занятий, которые помогут лучше разобраться с тем, как работают привычные нам вещи. Подпишитесь, чтобы не пропустить остальное.
Получите ИТ-профессию
В «Яндекс Практикуме» можно стать разработчиком, тестировщиком, аналитиком и менеджером цифровых продуктов. Первая часть обучения всегда бесплатная, чтобы попробовать и найти то, что вам по душе. Дальше — программы трудоустройства.
Как вовремя узнать, что ваш сервер не работает?
Случается, что сайты перестают работать. Причины могут быть самые разные: в датацентре «упал» канал, сервер вырубился, кто-то что-то намудрил с базой или файлами на сервере, сисадмин неудачно обновил ПО или переносил аккаунты. Или кое-кто забыл оплатить хостинг.
В большинстве случаев такая ситуация нежелательна, а устранить ее надо как можно скорее. Для этого нужно как можно скорее узнать о случившемся. Но как? Для себя и для наших клиентов мы используем сервисы мониторинга сайтов. О них я сегодня и расскажу.
Как это работает
Принцип прост: где-то постоянно работает программа, которая периодически обращается к вашему серверу и проверяет его работу. Если что-то не так, программа оповещает вас по электронной почте или даже по SMS.
В простейшем случае программа проверяет, доступен ли сервер. Но ведь может случиться и так, что сервер доступен, а вместо главной страницы вашего интернет-магазина пользователи видят позорное «хостинг не оплачен» или «аккаунт заблокирован».
Правильные сервисы мониторинга позволяют отследить и такую ситуацию. Они могут проверять страницы сайта на наличие определенных меток. Такой меткой может быть фрагмент верстки или HTML-комментарий.
Совсем продвинутые сервисы позволяют проверять даже валидность ssl-сертификата.
По итогам недели или месяца сервис может прислать отчет. Тут-то вы и проверите заявления вашего хостера про uptime серверов.
Можно ли сделать такую штуку самому?
Конечно, можно и самому «замутить» такой скрипт, это несложно. Но у сервисов есть важное преимущество: во-первых, все вопросы с программированием, тестированием и поддержкой уже решены.
Во-вторых, если ваш скрипт физически будет расположен на одном сервере, то его работоспособность будет зависеть от работоспособности этого сервера. У специализированных сервисов таких серверов десятки.
Сколько это стоит
Базовые функции предоставляются бесплатно. За умеренную плату можно получить SMS-уведомления
Чем пользуемся мы
Basicstate.com
Этот сервис сначала пытается отрезолвить адрес сайта по DNS, затем — установить HTTP-соединение, отправляет HTTP-запрос. Потом анализирует код ответа и пытается получить страницу. Проверка — каждые 15 минут.
Сбои на разных этапах будут засчитаны как ошибки разного типа. Таким образом, можно локализовать проблему. И очень полезно в ситуациях, когда из подсети хостера «все работает», а извне — недоступно.
Сервис позволяет «повесить» на один аккаунт неограниченное количество сайтов.
Интересная фишка — множественные уведомления. Например, сразу при обнаружении проблемы сервис может записать в отчет, если сайт не работает и через 15 минут (бывает, что это просто сервер перезагружался) — уведомит вас по email и SMS, а если и через час все плохо, может и в саппорт хостеру написать.
Host-tracker.com
Большой и довольной продвинутый сервис, кстати, с русскоязычной версией. Уведомления может отправить и по ICQ, и в Gtalk (другие jabber’ы я не пробовал).
Проверка на бесплатном аккаунте — каждые 30 минут. Пишут, что у них 45 точек мониторинга. В начальный платный тариф входит проверка наличия ключевого слова на странице. Это может пригодиться, если вы хотите мониторить какой-то сервис. Пишете скрипт, который при вызове проверит работоспособность и выведет нужное слово на страницу по специальному адресу, сервис будет периодически обращаться по этому адресу и отслеживать ключевое слово.
В заключение
В общем, коллеги, предлагаю добавить подключение к сервису мониторинга сайтов в ваши стандарты обслуживания клиентов.