main

Централизованный сбор логов с уведомлениями

Когда админу делать нечего - он бэкапы настраивает. Когда СОВСЕМ нечего - безопасность. © Профессиональная народная поговорка.

Итак, задача: централизованно собирать, хранить и (желательно) анализировать логи.

Дано:

  • ~100 хостов, ~100-800 мб логов в день всего.
  • сервер с софтрейдом, 3 Тб места, 1Гб памяти и старым Xeon'ом

Ограничения:

  • бюджета и железа под эту задачу никто не даст, разве что пост-фактум, когда "петух в жопу клюнет"
  • минимальное потребление ресурсов на сервере логов, минимум нагрузки на отправителя логов
  • делается для собственных нужд, поэтому наличием красивых отчётиков можно пренебречь

Разведка местности

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

Тем не менее, стоит отметить решения из первой категории (в порядке возрастания адекватности):

  • splunk -- на официальном сайте стандартное ко-ко-ко про "облака", "high availability", "99.999", "mission critical" и прочий булшит. Тот обрезок, что предлагается скачать "на попробовать", всем видом подразумевает дальнейшую дойку клиента за саппорт.
  • OSSIM -- это не просто анализатор логов, а "security information and event management", как они это называют. Понапихано всякого, в частности мониторинг доступности и считалка трафика.
  • logstash -- оно же "буратино" или "полено". Анализатор логов, довольно мощный, но с ма-аленьким недостатком -- жаба. Что ставит крест на использовании у нас.

Далее, те что реально ставились и тестировались.

  • Prelude -- таки анализатор логов, по схеме "агент/сервер". Есть агент (c++), коллектор (c++), анализатор (python) и вебморда (python).
  • ossec -- древний, но живой и здоровый проект. Основной функционал - анализатор логов, но в случае чего может и правило в фаервол добавить. Писан ещё до победоносного нашествия скриптоты, поэтому быстр и брутален. Вебморды к нему как-то не прижились, поэтому рассчитывайте только на логи и письмо в почту. Важно - имеет накопленную и общедоступную базу паттернов для логов.

Реализация / коллектор

Prelude долго у меня гонялся в тестовом варианте, но всё же не взлетел: 4 хоста - 8 гигов базы за 3 месяца1. Сами логи не хранит, только сгенеренные event'ы.

Окончательно он меня добил вот этим (случайно заметил через консоль mysql'а):

| 152490 | prelude-manager | 10.1.1.4:41330 | preludemanager | Query   |    0 | updating |
DELETE FROM Prelude_Node WHERE _parent_type = 'H' AND _message_ident IN
(32863, 32864, 32865, 32866, 32867,
 <ещё куча-куча id'ов>,
 <...>
 <ещё куча-куча id'ов>, 33861, 33862) |

Идентификаторы последовательные, общим числом в тысячу штук.

А так всё отлично - передача информации на коллектор шифруется, при отвале связи сообщения спулятся и досылаются, вебморда это всё кажет, импорт просто syslog'а по сети - есть, в общем - красота. Когда-нибудь обязательно его ещё погоняю, скажем следующую мажорную версию.

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

В качестве коллектора был выбран syslog-ng, из-за простоты и расширенных возможностей по организации файлов логов.

@version:3.5

# общие настройки
options { chain_hostnames(off); flush_lines(50); threaded(yes); };

# "сетевые" логи пишем в архив
source s_external { udp(ip(192.168.1.33) port(514)); };

destination d_archive {
  file("/mnt/logs/$YEAR-$MONTH-$DAY/$HOST.log"
    owner(nobody) group(nogroup) perm(0600) dir_perm(0700) create_dirs(yes));
};

log { source(s_external); destination(d_archive); };

# "свои" сообщения пишем в отдельный файл, для отладки и статистики
source s_internal { internal(); };

destination d_ownlog {
  file("/var/log/syslog-ng.log");
};

log { source(s_internal); destination(d_ownlog); };

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

# syslog-ng -s # проверяем конфиг
# service syslog-ng start # запускаем

На rsyslog это делается не так очевидно, но намного короче:

$CreateDirs on
module(load="imudp")
input(type="imudp" address="0.0.0.0" port="514" ruleset="logarchive")

$te