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

Наборы инструментов для мониторинга журналов для Unix?

Какие есть хорошие инструменты для мониторинга журналов в системе? В настоящее время я использую logsentry, который в основном просто запускает grep в журналах, игнорирует регулярные выражения, которые я говорю ему игнорировать, и отправляет мне все остальное по почте, но я хотел бы найти что-то более умное (т.е. могу понять, что журнал Postfix выходит за рамки простого набора строк, на которые можно опираться, и тому подобного - контекстного знания).

На сервисах не запущено ничего особо экзотического - apache, memcached, postgres, postfix, openssh, squid, bind, mailman. О самом странном беге монотонный, который я не ожидал бы от какого-либо анализатора логов (поэтому было бы неплохо, если бы его можно было легко расширить с пониманием дополнительных сервисов).

Что-то, что может анализировать и обобщать информацию в ежечасных или ежедневных отчетах (например, 15 сообщений 404, зарегистрированных в этом файле журнала apache, 3 входа этого пользователя с IP-адресов x, y и z, 5 писем, отправленных этим пользователем, и 150 сообщений, полученных другим пользователь, диск X заполнен на 90%, 3000 неудачных попыток ssh с этих случайных IP-адресов и т.д.) были бы идеальными.

Я просмотрел несколько списков инструментов мониторинга журналов для Unix, но большинство из них, похоже, сводятся к tail -f или grep. Я надеюсь, что есть что-то, что я упустил из виду.

Я думаю о мониторинге двух типов. Существует мониторинг текущего состояния и ведение его истории на сервере мониторинга, а также есть история мониторинга (журналы).

Некоторая информация, которую вы указали, на самом деле не предназначена для отслеживания с помощью журналов. Например, дисковое пространство, вероятно, лучше контролировать плагином, который вызывает команду df или что-то в этом роде. Так что я бы посчитал этот мониторинг текущим состоянием, даже если вы его ведете.

мне нравиться Splunk для мониторинга журналов, но это дорого, если вам нужно делать то, чего нет в бесплатной версии. Для мониторинга таких вещей, как дисковое пространство, если процесс запущен, использование процессора и т. Д., Лично мне нравится Nagios. Думаю, эти две пары хорошо вместе.

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

Ты можешь использовать Осьминог за все вопросы, которые вы просили. (за исключением того, что `` диск заполнен на 90% '', как сказал Кайл, вероятно, лучше контролировать с помощью системных мониторов, таких как Nagios, Zabbix, ...)

Осьминог это решение для управления журналами:

  • Искать в журналах
  • Поднять оповещения из логов
  • Создавать отчеты из журналов

С участием Осьминог, вы можете «легко» создавать отчеты о чем угодно из любых журналов. (может быть не так просто, потому что вам нужна некоторая работа по определению шаблонов журналов и отчетов, но действительно мощно после этой первой работы)

Отказ от ответственности: я работаю над Осьминог.

Серьезно, вы хотите OSSEC. Он легко откладывает logsentry, logwatch и тому подобное.

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

Попробуйте, это самый простой в установке инструмент (просто запустите их скрипт install.sh) и наслаждайтесь.

Ссылка на сайт: http://www.ossec.net

Logwatch, который, как мне кажется, установлен и активен как в Debian, так и в Redhat, делает многие из отчетов, которые вы ищете. Я полагаю, что есть много общего с тем, что вы получаете от logsentry. По какой-то причине конфигурации logwatch на Redhat производят большой объем (особенно журнал samba), что делает его более бесполезным, в отличие от более жестких отчетов logwatch от Debian.

Лично я уделяю больше внимания тому, что может стать критичным. У меня есть задания cron, чтобы проверить, видят ли устройства RAID все исправные диски, и напишите мне, если нет. Я использую cacti для построения графика активной и общей очереди на серверах MX и SMTP (с помощью сценария оболочки, запрашиваемого через snmp). Точно так же у меня есть ежедневная статистика журналов postfix, которые отображаются в виде кактусов. Denyhosts блокирует чрезмерные сбои аутентификации ssh или других служб и электронные письма root. Даже температуру в серверной можно отслеживать, измеряя температуру ИБП APC (используйте apsupsd) и нанося ее на график кактусов. Cacti также будет отображать использование диска, нагрузку на сервер и т. Д. Самое замечательное в графиках то, что они показывают тенденции за несколько недель или лет, которые вы могли бы не заметить иначе. Например, сколько спама отмечено тегами или тенденции дискового пространства. Это позволяет планировать будущее.