Мониторинг работоспособности каждую секунду - плохо для сервера?


11

Мне интересно, есть ли возможность проверить, работает ли сервер, выполняя «HTTP GET Request» каждую секунду?

Может ли любой сервер справиться с этим?


Другой вариант заключается в обратном: вместо того, чтобы следить за сервером снаружи, следите за сервером изнутри, например, с ru-on.com . Вы в основном устанавливаете небольшой скрипт на своем сервере, который очень часто проверяет связь с другим сервером, так что вы можете контролировать время безотказной работы, не усложняя жизнь веб-серверу.
— Максим Заславский

3
@ Максим, есть несколько проблем с твоим предложением. Во-первых, он не проверяет, что служба HTTP работает на сервере. Во-вторых, существует проблема того, что происходит, когда сам сервер не работает. Это все еще необходимо контролировать. Кроме того, тот же результат может быть получен простым wget против локальной машины.
— Джон Гарденье

Ответы:


26

Может ли «любой» сервер справиться с этим? Наверное.

Должны ли вы сделать это? Возможно нет.

Задайте себе несколько вопросов:

  1. Как быстро вы будете реагировать на сбой?
  2. Сколько просмотров страниц вы обычно получаете в секунду?
  3. Сколько последовательных ошибок вы хотите увидеть перед тем, как назвать его «Отключено» и отправить предупреждение?
  4. Есть ли у вас соглашение об уровне обслуживания с внутренними или внешними клиентами, которое необходимо соблюдать?
  5. Исходя из перечисленных выше вопросов, что кажется разумным временем для мониторинга и ответа?

Когда я впервые научился программировать, я решил, что хочу сделать секундомер. Когда я наконец-то получил работающее приложение, я заметил, что загрузка процессора на моем ноутбуке составляла 100% при каждом запуске.

У моего цикла выполнения не было цикла ожидания. Это только продолжало выполняться через функцию времени.

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


6

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

Может ли ваш сервер справиться с этим? У нас нет ничего, на что можно было бы ответить на такой вопрос, но если у вашего сервера есть проблема, решающая его, то я бы предположил, что он будет совершенно неадекватен для того, что еще он обслуживает.


3

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


1

Большинство коммерческих программ мониторинга предлагают интервал 1 или 5 минут по умолчанию. Это кажется хорошим интервалом проверки.


Pingdom, например, позволяет вам установить интервал, а затем, обнаружив первый сбой, увеличить частоту, с которой он отправляет эхо-запрос на сервер, чтобы проверить, работает ли он.
— Анкур Банерджи

>, увеличьте частоту .. => но минимум все равно 1 мин или?
— sapguy

На бесплатных аккаунтах я думаю, что самое низкое, что предлагает Pingdom - это 1 минута. У меня нет премиум-аккаунта, поэтому я не могу сказать, предлагают ли они возможность более частых проверок за них.
— Анкур Банерджи

1

Нет ничего плохого в мониторинге сервера каждую секунду, просто он не очень эффективен, особенно на серверах с высокой нагрузкой, где запрос Apache может зависать на пару секунд, вызывая резервное копирование ваших запросов или выдачу ложных предупреждений в этот конкретный момент, но это не неправильно'. Проверки за одну секунду не заставят вас быстрее реагировать, и в 99,9% случаев обстоятельства столь же важны проверки за 10 или 30 секунд.


0

Я согласен на 100% с Джозефом здесь. Если вы все еще хотите осуществлять какой-либо мониторинг в режиме реального времени, вы можете рассмотреть возможность прослушивания журнала веб-сервера на наличие ошибок сервера и отсутствия новых записей в журнале в течение определенного периода времени. Это не приведет к нагрузке на сервер, но вызов оповещений на основе этого является проблемой :)


0

Разрешение в 1 секунду действительно высокое и, вероятно, не нужно. Однако я предпочитаю collectd, поскольку он был разработан для гораздо более высокого разрешения (10 секунд), чем другие инструменты OSS, такие как munin (5 минут).

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.