Инструмент мониторинга файла журнала

Мы ищем инструмент, который

  • может анализировать файлы журналов и проверять, соответствует ли определенный шаблон, например, «ОШИБКА» или «FATAL» содержится в строке файла журнала.
  • может проверить, присутствует ли файл журнала или был ли он изменен в определенный момент времени - это для проверки того, выполнялась ли подпрограмма, поскольку они всегда генерируют файлы журнала
  • если эти проверки сработали, отправляет нам электронное письмо
  • (необязательно) собирает несколько событий за заданный период времени, чтобы отправить одно письмо вместо множества

Нефункциональные требования

  • он должен быть установлен локально на нашем компьютере, поскольку мы работаем внутри интрасети и за брандмауэрами. Попытка получить правила исключения, чтобы использовать интернет-программное обеспечение в качестве сервисных решений, не вариант.
  • мы работаем только на серверах Red Hat Linux, поэтому решения для Windows не подходят
  • (необязательно) мы запускаем несколько серверов, поэтому было бы неплохо иметь мастер, который собирает входные данные со всех этих серверов (агентов) и координирует оповещения. Но мы также готовы установить и настроить несколько установок из инструмента на нескольких машинах.
  • (необязательно) с открытым исходным кодом, чтобы мы могли внести свой вклад, но закрытый исходный код также приветствуется, также, если это стоит денег, мы готовы платить
  • (опционально) консультация по установке приветствуется

Что мы рассмотрели до сих пор

  • Nagios — с нашей точки зрения предлагает слишком много для того, что мы хотим. Для нас это похоже на кувалду, чтобы расколоть этот орех
  • Стек ELK плюс плагин Watcher — кажется, полностью удовлетворяют наши потребности. Хотя он также предоставляет слишком много функций, которые нам не нужны. История логов нам не нужна, поэтому часть Kibana для нас не представляет интереса, да и целый сервер elasticsearch тоже многовато.
Если вы можете решить проблему «файл существует» отдельно (например, используя cron-job со сценарием оболочки), будет ли вариант Fail2ban ? Вместо части «Запрет» он также может использовать уведомления или другие действия (вы даже можете определить свои собственные действия, так как вы можете определить свои фильтры — так, например, его можно настроить для отправки отчетов непосредственно в базу данных). Если это удовлетворит ваши потребности, дайте мне знать, и я напишу соответствующий ответ с некоторыми дополнительными подробностями.
Спасибо за ваш вклад, @Izzy, но мы ищем универсальное решение.
Так и думал - вот почему я написал это как комментарий, а не как ответ. Я по-прежнему оставляю его там — вы можете передумать, если не появится реальное/подходящее универсальное решение. Я не знаю, что Fail2Ban тоже может оповещать об отсутствующих логах — но тогда мне это было не нужно, и я просто мог пропустить. Он обнаруживает «ротацию журнала», поэтому он может делать даже больше. Я далек от того, чтобы использовать весь его потенциал, я думаю;)
Это должно быть программное обеспечение корпоративного класса? Я знаю человека, который создал полностью настраиваемую альтернативу Nagios для локального мониторинга и выполняет почти все, что вам нужно. Он находится на ранних стадиях развертывания, но мы могли бы связаться с вами, когда закончим.

Ответы (1)

Я ищу инструмент, как и вы в течение некоторого времени.

Этот выглядит хорошо:

https://hekad.readthedocs.org

Вот основные функции (с домашней страницы):

Heka — это система программного обеспечения для потоковой обработки с открытым исходным кодом, разработанная Mozilla. Heka — это инструмент типа «швейцарский армейский нож» для обработки данных, полезный для самых разных задач, таких как:

  • Загрузка и анализ файлов журнала из файловой системы.
  • Прием данных метрик типа statsd для агрегирования и пересылки в вышестоящие хранилища данных временных рядов, такие как graphite или InfluxDB.
  • Запуск внешних процессов для сбора операционных данных из локальной системы.
  • Выполнение анализа в реальном времени, построение графиков и обнаружение аномалий любых данных, проходящих через конвейер Heka.
  • Доставка данных из одного места в другое с использованием внешнего транспорта (например, AMQP) или напрямую (через TCP).
  • Доставка обработанных данных в одно или несколько постоянных хранилищ данных.
Инструмент мониторинга файла журнала
СпросиСетьПолитика конфиденциальности1y, 0v