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


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.