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

Альтернатива Sensu (?), Где пороги срабатывания сигнализации определены на сервере (не отслеживаемый клиент)

Вопрос / TL; DR;

Существует ли альтернатива Sensu (например, агент / сервер мониторинга операционной системы на основе RabbitMQ), который определяет пороги срабатывания сигнализации на центральном сервере мониторинга, а не на отслеживаемом клиентском сервере (как это делают Sensu и Nagios)?

RabbitMQ требуется, поэтому, боюсь, никаких Zabbix и др.

Задний план:

У меня есть большие среды (Windows и RHEL), в которых я не могу установить инструменты оркестровки (Puppet и др.), Поэтому количество установленных служб должно быть сведено к минимуму.

Я изучаю, могу ли я разработать единый агент, который собирает системную информацию, передает журналы (в Logstash) и отчеты о потреблении ресурсов. Он отправит все эти значения в RabbitMQ, а затем Logstash сможет подписаться на журналы, служба мониторинга может подписаться на метрики ресурсов (и создать из них аварийные сигналы), система CMDB может подписаться на системную информацию и т. Д.

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

Я не могу быть единственным человеком, который может найти такого полезного агента ...

Уточнение:

Если сервер под Sensu мониторинг заканчивается диск, агент Sensu проверяет дисковое пространство, сравнивает его с КРИТИЧЕСКИМ порогом, определенным на этом сервере, и, если порог пройден, через RabbitMQ на центральный сервер мониторинга отправляется КРИТИЧЕСКИЙ сигнал тревоги. Чтобы изменить порог без Puppet или чего-то подобного, требуется авторизация на сервере (верно?)

Как я нравится это работать заключается в том, что, когда агент мониторинга проверяет свое дисковое пространство, он просто отправляет количество доступного диска (или использованный диск и общее количество и т. д.) через RabbitMQ на центральный сервер, который затем сравнивает это значение с порогом, определенным на центральном сервере, и, если необходимо , отправляет сигнал тревоги.

Если необходимо изменить порог, его можно изменить на центральном сервере или можно сравнить несколько значений с нескольких серверов для создания сигнала тревоги.

Это своего рода моя основная проблема с Sensu, хотя я понимаю решение пойти с совместимостью с Nagios.

Также было бы предпочтительнее, если бы не требовался центральный сервер -> трафик отслеживаемого сервера. Я предполагаю, что можно создать кладж, в котором центральный сервер отправляет пороговые значения агенту, который затем запускает их как «локальные». Сеть для среды делает это исключительно сложным.

Спасибо за любые идеи!

Используя компоненты с открытым исходным кодом, я бы использовал следующие компоненты (если вам действительно нужно отправлять метрики через RabbitMQ):

  1. использовать собирать на стороне клиента для отправки метрик в RabbitMQ с его Плагин AMQP
  2. использовать сообщения от RabbitMQ, используя графит-amqp-инструменты и отправить их в Графитовый

Теперь у вас есть метрики в Graphite, вы можете запросить у них потребление ресурсов. В моей среде $ WORK у нас есть проверки, которые запрашивают Graphite, с пороговыми значениями предупреждений, установленными на сервере Nagios. Но теперь, когда у вас есть Graphite (у него есть http-интерфейс для запросов, который может возвращать графики, json, csv и результаты в виде обычного текста), вы можете создавать / использовать что угодно, если оно может запрашивать Graphite.

Порог может быть определен на стороне сервера мониторинга sensu, см. Стр. 9 http://samples.leanpub.com/sensumonitoringandmetrics-sample.pdf (но убедитесь, что safe_mode = false, если определение клиента на сервере не совпадает в точности с определением клиента, см. стр. 12)

Если я правильно понимаю, вам просто нужно отправить данные в RabbitMQ. Разве тема не о том, как отправить отчетные данные в RabbitMQ?

Возможно, вы могли бы использовать несколько вариантов:

  • безагентный мониторинг - вы можете использовать старый (хороший) snmp и анализировать его данные на сервер. Есть много инструментов, которые могут это сделать, а затем вы можете отправить его куда хотите.

  • мониторинг на основе агентов - вы можете использовать, например, cfengine, который может проверять обещания (извлеченные с центрального сервера) или который может просто сообщать о состоянии вашей файловой системы, а затем вы можете анализировать ее данные.

Да, именно это и делает dataloop.io. Как и Sensu, использует архитектуру на основе очередей для метрик в реальном времени и простой конфигурации, но предупреждения можно настроить на стороне сервера не только в сценариях, таких как Nagios / Sensu.

Sensu также требует, чтобы вы установили другие вещи, такие как Graphite, для получения графиков, поэтому настроить его не так просто.