Примеры реальной системы (загрузка и база данных) |
---|
|
Дата последнего изменения: 17.01.2024
Можно выделить следующие типы мониторинга самого сайта:
Мониторинг доступности - отслеживание того, работает ли он или нет. Наиболее оптимальным для простого мониторинга является десятиминутный интервал: большинство пользователей попытаются вернуться на сайт в течение 1-2 часов, а за это время можно как обнаружить проблемы, так и эффективно их устранить без особого вреда для бизнеса компании.
Мониторинг проблем - отслеживание нескольких параметров сайта с частотой не менее раза в минуту и из нескольких географических точек (чтобы максимально покрыть минутный интервал проверками и установить возможные проблемы, связанные с географией пользователей).
Среди возможных критериев проверки можно выделить проблемы с:
Этот метод особенно хорош, когда требуется отловить какую-то «плавающую» ошибку, а несколько независимых сервисов либо точек проверки позволяют добиться частоты проверки вплоть до раза в 10 секунд - а это более чем достаточно, чтобы обнаружить все, что необходимо.
Мониторинг может быть не долговременным (до обнаружения и исправления проблем) либо периодическим (в целях профилактики проблем).
Мониторинг работоспособности - сюда может относиться любой сложный функционал, который может быть затронут какими-либо изменениями на сайте, например, кабинет интернет-банка. В этом случае необходимо настраивать цепочки проверок либо задавать сложные условия для проведения проверок того или иного функционала сайта.
При построении отказоустойчивой распределенной инфраструктуры кроме обеспечения нескольких уровней надежности обычно закладывают и несколько уровней мониторинга системы. Среди них можно выделить:
Munin выдает большое количество информации о состоянии требуемого сервера. К наиболее часто проверяемым моментам относят:
Примеры реальной системы (загрузка и база данных) |
---|
|
Nagios как решение для мониторинга безусловно хорош. Но нужно быть готовым к тому, что кроме него придется использовать еще собственные скрипты и (или) Pinba (или аналогичное решения дл вашего языка программирования). Pinba оперирует UDP-пакетами и собирает информацию о времени выполнения скриптов, объеме памяти и кодах ошибок. В принципе, этого достаточно для создания полной картины происходящего и обеспечения требуемого уровня надежности сервиса в автоматическом режиме.
На уровне внутреннего мониторинга уже можно принимать решения о выделении дополнительных мощностей (если это возможно автоматически — то достаточно просто отслеживать средний уровень загрузки процессора на серверах приложений или базы данных, если это производится в ручном режиме — то можно высылать письма или jabber-сообщения) или их отключении. Также в случае возникновения аномального количества ошибок (обычно это происходит при отказе оборудования либо ошибки в новой версии веб-сервиса, и что является причиной, всегда можно установить за счет дополнительных проверок) можно слать уже экстренные уведомления по смс или звонить по телефону.
Также очень удобно настроить автоматическое добавление (или удаление) тестов при увеличении точек проверки (например, серверов ли пользовательских сайтов) с заданными шаблонами: например, проверка главной страницы, распределение времени выполнения PHP, распределение использования памяти для PHP, число nginx и PHP ошибок.
Мониторинг на уровне облачной инфраструктуры предлагает не такое большое количество провайдеров, и он является, скорее, информационным: реальные решения принимаются либо на основе внутренних данных, либо внешнего состояния системы. На промежуточном уровне можно только собирать статистику или подтверждать внутреннее состояние инфраструктуры.
Для Amazon CloudWatch здесь доступны следующие возможности проверки:
Также можно добавлять свои собственные метрики.
Уже по результатам мониторинга промежуточного (на уровне балансировщиков) можно принимать обоснованное решение о выделении или закрытии машин (инстансов) в кластере.
Здесь выбор решений очень большой. Если требуется отслеживать состояние серверов по всему миру, то лучшее решение — это Pingdom. Для российских реалий подойдет PingAdmin, Monitorus или WEBO Pulsar. Особенно удобно настроить проверку из нескольких географических точек и дергать удаленный скрипт уведомления, если сервис не доступен в течение 1-2 минут. Если при этом есть какие-либо проблемы внутри, то можно сразу переключаться на план "Б" (выключать неработающие сервера, отсылать уведомления и т.д.).
К дополнительным плюсам внешнего мониторинга можно отнести проверку реального времени ответа на стороне сервера (или реальных сетевых задержек). По этому параметру также можно настроить уведомления. Как дополнительная возможность в случае использования CDN: можно отслеживать полное время загрузки страниц сервиса и отключать или включать CDN для разных регионов.
Не стоит забывать и принимать во внимание некоторые нетипичные, но важные параметры, которые тоже необходимо отслеживать: