10 тыс. Сайтов x 5 URL для мониторинга
Для нашей Atlassian Hosted Platform у нас есть около 10 000 веб-сайтов, которые мы должны отслеживать. Эти сайты контролируются из удаленного местоположения для измерения времени отклика и доступности. Каждый сервер будет иметь в среднем около 5 дополнительных URL-адресов для проверки, что приведет к проверке URL-адресов по 50 КБ.
В настоящее время мы используем Nagios с check_http и нам требуется около 14 крупных Amazon-инстансов. Хотя серверы nagios не полностью перегружены, мы гарантируем, что все проверки будут завершены в течение 5-минутного цикла проверки.
В недавнем всплеске мы исследовали, можем ли мы сделать какие-либо оптимизации, чтобы:
- Используйте меньше ресурсов сервера , чтобы не только сократить расходы, но и избежать управления несколькими серверами nagios, которые не динамически перебалансируют проверки между несколькими хостами nagios.
- Завершите все проверки в меньшем окне (скажем, за 1 минуту), так как это увеличит MTTD
Глядя на это, мы хотели, чтобы технология была многократно используемой с нашей будущей идеей полностью масштабируемого и распределенного мониторинга (вспомните Flapjack или нового парня из блока Sensu ). Но пока мы хотели сосредоточиться только на проверках.
В первом посте этой серии мы рассмотрим интеграцию и опции в Nagios. Во втором посте блога мы предоставим подтверждение концептуального кода для запуска внешнего процесса (на основе ruby), который необходимо выполнить, и отчитаться перед nagios. Несмотря на то, что с Nagios работать не очень весело, многие решения пытаются заменить его, сосредоточившись на замене раздела проверок. Но Nagios дает вам больше отчетности, эскалации, управления зависимостями. Я не говорю, что там нет решений, но мы считаем, что это для другого этапа.
Проверьте HTTP
Канонический способ выполнения проверки в Nagios — выполнить Check_http .
Если бы он выполнял проверку, если слияние работает на https://somehost.atlassian.net/wiki, мы бы предоставили следующие варианты:
- -H (имя виртуального хоста), -I (ipaddress), -p (порт)
- -u (путь URL), -S (ssl), -f следовать (следовать перенаправлениям)
-
-t (тайм-аут)
$ /usr/lib64/nagios/plugins/check_http -H somehost.atlassian.net -p 443 -u /wiki -f follow -S -v -t 2 HTTP OK: HTTP/1.1 200 OK - 546 bytes in 0.734 second response time |time=0.734058s;;;0.000000 size=546B;;;0
Некоторые наблюдения:
- При каждой проверке конфигурации Nagios будет дважды выполнять разветвление и запускать exec check_http, избегая этого, можно было бы повысить производительность, поскольку fork считается дорогим.
- Если бы у нас было много URL на одном хосте, мы не можем использовать повторное использование соединения, делая его менее эффективным
- Для проверки статуса мы можем настроить его на использование -J HEAD, если наша проверка не зависит от содержимого страницы (экономия на времени передачи и сокращение времени проверки)
- Перенаправления: не проблема Nagios, но в настоящее время у нас довольно много переадресаций, основанных на логике страницы входа в систему, сокращение которых снова улучшило бы время проверки.
Мы можем уменьшить часть разветвлений, используя параметр use_large_installation_tweaks = 1 . Преимущества и предостережения объяснены в документах
Проверьте расписание
Сам Nagios пытается быть умным, чтобы запланировать проверки. Он пытается распределить количество проверок сервиса в пределах интервала проверки, который вы настраиваете. Дополнительную информацию можно найти в более старой документации Nagios .
Параметры конфигурации, которые влияют на планирование:
- normal_check_interval : сколько времени между повторным выполнением одной и той же проверки
- retry_check_interval : как быстро повторить проверку, если она не удалась
- check_period : общее время для полного цикла проверки
- inter_check_delay_method : метод для планирования проверок (
- service_interleave_factor : время между проверками на одном и том же удаленном хосте
- max_concurrent_checks : очевидно, нет?
- service_reaper_frequency : частота для проверки на мошеннические проверки
По умолчанию для inter_check_delay_method используется smart, если мы хотим выполнить проверки максимально быстро
- n = Не использовать задержку — запланируйте все сервисные проверки для немедленного запуска (т.е. одновременно!)
- d = использовать «тупую» задержку в 1 секунду между проверками обслуживания
- s = использовать «умный» расчет задержки для равномерного распределения проверок услуг (по умолчанию)
- x.xx = использовать предоставленную пользователем задержку между проверками x.xx секунд
Распределение чеков
Когда один хост больше не может его сократить, мы должны в конечном итоге масштабироваться. Вот некоторые решения, которые полностью живут в мире Nagios:
Наше будущее решение будет иметь аналогичный подход к отправке команды проверок и сбору результатов обратно в очередь, но мы бы хотели, чтобы оно было менее зависимым от решения Nagios и могло быть интегрировано с другими решениями для мониторинга (философия Think Unix Toolchain). ) Отличный пример идеи можно увидеть в презентации Velocityconf. Асинхронный мониторинг в реальном времени с Mcollective.
Отправка результатов проверки обратно в Nagios
Таким образом, с помощью распределения мы просто снова разделяем нашу проблему на более мелкие. Итак, давайте снова сосредоточимся на проблеме проверки одного хоста, в конце концов, чем больше проверок мы можем запустить на 1 хосте, тем меньше нам нужно распределять.
Пассивные проверки Nagios легко позволяют отсоединить проверки от основного цикла nagios и представить результаты проверки позже. NSCA (Nagios Service Check Acceptor) является наиболее часто используемым решением для этого.
У NSCA есть несколько ограничений:
- Только первые 511 байтов плагинов были возвращены мастеру, что ограничивает полезность информации, которую вы можете отобразить
- Была возвращена только 1-я строка данных, то есть вы должны были ограничить вывод вместе
- Связь NSCA использовала пакеты фиксированного размера, которые были неэффективными
- В то время как результаты были отправлены, Nagios будет ждать завершения, представляя узкое место
- Если была проблема со связью с мастером, результаты были отброшены
Это привело их к использованию NRD (дистрибьютор результатов Nagios)
«При развертывании NCSA никто не говорит о том, что он отправляет сервисные проверки последовательно, а nagios выполняет сервисные проверки параллельно»
Это привело его к написанию высокопроизводительной замены NSCA, включающей подачу результата непосредственно в канал livestatus, а не по протоколу NSCA, запеченному в nagios. На аналогичном замечании Jelle Smet создал NSCAWEb. Легко отправляйте пассивные проверки хоста и обслуживания в Nagios с помощью внешних команд
Мы бы использовать Send NSCA Ruby Gem
Почему это относится к нашему решению? Без использования некоторых из этих оптимизаций наше узкое место перешло бы от запуска проверок к принятию результатов проверок.
Другим решением может быть запуск сервера NRPE, и мы могли бы использовать некоторую рубиновую логику от Metis — сервер ruby NRPE
Вывод
Даже после следующих оптимизаций:
- Используя голову против получить
- Большие настройки
- Настройка inter_check_delay_method
- Параллельные представления NSCA против последовательных представлений
мы все еще можем оптимизировать с помощью:
- Избегайте процесса разветвления, запустив все проверки из одного процесса
- Повторное использование http-соединения для нескольких запросов на один и тот же хост (возможно, даже http-конвейерная обработка)
В следующем посте мы покажем результаты проверки концептуального кода с использованием ruby / eventmachine / jruby и различных библиотек httpclient.