Назад | Перейти на главную страницу

Что мониторить на веб-сервере?

Какие «параметры здоровья» вы, ребята, отслеживаете на веб-сервере (или sql) (Windows 2008)?

ОЗУ, ЦП, дисковое пространство, журнал событий, определенные веб-страницы, сеть .. больше?

Есть ли у вас аварийные сигналы, которые срабатывают при достижении чего-то критического, например, использование оперативной памяти более X% или что-то в этом роде?

У меня (или, точнее, у системных администраторов) есть доступ к WhatsUp Gold в качестве инструмента мониторинга. Но сейчас я думаю, что никаких сигнализаций не установлено.

Я провел последние несколько месяцев, исследуя именно этот вопрос. Мое исследование было сосредоточено на Nginx, но принципы те же и могут применяться к любому веб-серверу (Windows или другому).

Во-первых, немного теории: вы хотите отслеживать метрики по всему системному стеку - не только за самим приложением веб-сервера, но и за процессом, в котором оно выполняется, сервером, на котором он работает, и провайдером хостинга, в котором живет сервер. :

  • Потенциально плохие вещи (т.е. вещи, которые мог что-то пошло не так - заполнение диска, насыщение сети и т. д.)
  • Настоящие плохие вещи (т.е. то, что сделал пойти не так)
  • Хорошие вещи (особенно, когда они перестают происходить - например, посещения / касса)

Во-вторых, за чем следить. Я свел все к этим 14 пунктам. YMMV в зависимости от конкретной установки / серверного программного обеспечения, но я думаю, что принципы будут применяться независимо:

  1. Запросы в секунду (объем активности)
  2. Время отклика (производительность)
  3. Активные соединения (объем активности
  4. Коды ответов (2xx, 3xx, 5xx и их относительное распределение)
  5. Дескрипторы файлов процесса (это специфично для Nginx и относится к максимальному количеству рабочих и возможных подключений)
  6. Состояние процесса (живо ли серверное приложение?)
  7. Состояние сервера (сам ли сервер жив?)
  8. Средняя загрузка сервера (исправен ли сервер?)
  9. Использование сети сервера (достаточно ли пропускной способности?)
  10. Дисковое пространство (место для журналов / кеша)
  11. Статус хостинг-провайдера (AWS выключается == ваш сервер выключается)
  12. Истечение срока DNS (истечение срока DNS = ваш сервер выходит из строя)
  13. Срок действия SSL-сертификата (истечение срока действия сертификата = ваш сервер выходит из строя)
  14. Активность пользователя (ключевые страницы - просматриваются ли они и возвращают 200 ОК?)

Полная информация здесь, если интересно:

[Раскрытие информации: я являюсь аффилированным лицом Scalyr, компании, которая размещает связанное руководство и для которой я написал руководство]

Это зависит от того, что на самом деле делает сервер. Например, я знаю, что мои серверы Exchange 2007 будут использовать много памяти, это то, что делает Exchange, он захватывает столько, сколько может, поэтому мониторинг этого сервера на предмет использования High Ram не даст мне уснуть всю ночь, однако я хочу знать, у меня заканчивается место на диске, так как Exchange может перестать работать при нехватке места на диске. С другой стороны, меня не особо беспокоит использование диска на моем сервере печати.

На самом деле вам нужно посмотреть на свои серверы и определить, что вам нужно о них знать, что важно для их правильной работы, что полезно знать для целей истории или отслеживания, а что является лишним. Когда вы определили, что критично, вам действительно следует настроить сигналы тревоги или триггеры для этих событий. Какой смысл отслеживать что-то, если вы не знаете, когда что-то идет не так?

Идея мониторинга заключается в сравнении с исходным уровнем. Бессмысленно знать, что использование вашего диска составляет 90%, а ваша пропускная способность составляет 10 ГБ / день, если вы не знаете, нормально это или нет.

В основном возьмите все, что вы можете получить дешево (все данные RAW должны быть довольно дешевыми), и запишите базовый уровень, который поможет вам обнаружить аномалии. Аномалии включают в себя такие вещи, как программы, которые работают неправильно и съедают все дисковое пространство, утечки памяти, увеличивающие использование памяти, удвоение количества процессов при одинаковом количестве зарегистрированных пользователей и т. Д.

Главное - это то, что вы можете почерпнуть из необработанных данных и часто записывать образцы этих данных. Если объем вашего дискового пространства увеличивается очень медленно, то выборку дискового пространства не нужно выполнять каждые пять минут.

Я слежу за ЦП, дисковым пространством, очередью ЦП, проверкой связи (проверяя, что машина работает), за работой службы IIS, вызываю страницу ASPX, чтобы убедиться, что .NET работает и обрабатывается. Я вхожу в приложение, передавая имя пользователя и пароль, как пользователь, чтобы убедиться, что страница загружается и не генерирует 500 или тайм-аут.

Обычно я не отслеживаю используемую память, так как обычно это 100% или почти 100%. IIS неплохо справляется с поддержанием памяти в порядке, а IIS по умолчанию перезапускает пул приложений каждый день или около того, чтобы очистить все остальное.

Я стараюсь не контролировать ввод-вывод диска, так как это может быть все, что угодно. В некоторых системах SQL, Exchange и т. Д. Я буду отслеживать дисковую очередь для каждого диска, но с очень высоким порогом. Системы вырастут, поэтому я просто хочу знать, сойдут ли они с ума.