Оптимизация Graylog2 для сред с высоким логом

GrayLog2 — это бесплатная система сбора и корреляции журналов с открытым исходным кодом. Хотя он не соответствует списку функций Splunk, он предоставляет все основные возможности корреляции журналов, которые нам нужны.

Шаги для установки Graylog2 хорошо документированы в другом месте. Здесь я остановлюсь на некоторых из мер, которые были необходимы для дальнейшей эксплуатации системы для производственного использования. Поскольку наша среда получает от 2000 до 6000 журнальных сообщений в минуту (со случайными пиками до 40000!), Мы обнаруживаем, что наш набор данных растет очень быстро. В результате мы обнаружили, что наш сервер для хранения этих сообщений заполнялся очень быстро. Нам нужно было решение для сохранения диска с данными в виде плоских файлов — функция, которая в настоящее время не является частью приложения. Поэтому обсуждается архивация данных из MongoDB, как и наш собственный скрипт пересылки журналов, удобный инструмент Python для отправки сообщений из любого файла журнала на вашем сервере, основанный на совпадении или несоответствии регулярного выражения.

Эта статья посвящена версии Graylog2 0.9.5p2. Наше обновление до 0.9.6 было отложено до более поздней даты по причинам, о которых я расскажу позже в этом посте.

Стек приложений

Стек приложения состоит из следующих компонентов:

Из них только GELF Daemon написан собственными силами, с источником, обсужденным немного позже.

Все серверы в этой конкретной производственной среде работают под управлением версий RHEL 5 и RHEL 6, однако ничто не мешает этим технологиям работать в любой другой системе * NIX.

Архитектура

Вход / Back-конец

Все клиенты в среде пересылают свои журналы, используя либо собственную конфигурацию системного журнала, либо используя GELF. В то время как первый из них легко доступен для большинства сервисов UNIX, GELF — это более многофункциональный протокол, разработанный сообществом Graylog2, который может предоставить отдельные поля для индексации Graylog2.

Это требует, чтобы два порта были открыты для хоста регистрации от всех клиентов в среде.

Данные анализируются сервером Graylog2 и немедленно сохраняются в базе данных MongoDB. В нашем случае мы используем выделенный том NFS с нашего NetApp NAS, однако нет никаких причин, по которым локальное хранилище не будет работать так же хорошо.

Внимательно рассмотрите требования к оперативной памяти вашего сервера! MongoDB использует файлы с отображением в памяти, поэтому вам нужно иметь как минимум размер вашей коллекции баз данных * свободной в ОЗУ * на вашем хосте, в противном случае вы рискуете обменяться! В нашем случае у нас 8 ГБ ОЗУ на одном хосте с ограниченным набором 5 ГБ.

Фронтальный / Web

В отличие от большинства приложений на Rails, требования MySQL отсутствуют. Все данные для всего приложения хранятся в MongoDB. Кроме этого, веб-интерфейс является очень типичным проектом Rails, работающим под управлением Passenger. Производительность никогда не является серьезной проблемой, даже если приложение Rails работает на том же хосте, что и сервер Graylog2, которому, кстати, назначено 8 виртуальных процессорных ядер. Это оказалось более чем достаточным для нужд обработки информации журнала из нескольких сотен систем.

Закрытое хранилище

GrayLog2 использует ограниченные возможности хранения MongoDB. Ограниченная коллекция — это, по сути, таблица базы данных, которая использует механизм FIFO для ограничения использования хранилища. Для нашей таблицы журналов мы ограничены 5 ГБ общей памяти, которая должна быть способна хранить более недели журналов. Мы архивируем данные в файл через 24 часа и позволяем MongoDB удалять данные без помех.

Архивирование

Данные передаются из базы данных сообщений Graylog2 довольно быстро в нашей среде. Следовательно, мы активно архивируем данные в файл. MongoDB * очень * поддается такому подходу. Ниже приведен наш сценарий архивации, который выполняется каждый вечер на хосте Graylog2.

Обратите внимание, что пакет pymongo доступен в EPEL. Пожалуйста, сначала проверьте, как ваш пробег может отличаться!

#!/usr/bin/env python
from pymongo import Connection
import gzip
import time
import traceback
connection = Connection('localhost', 27017)
db = connection.graylog2
collection = db.messages
now = int(time.time())
today = time.localtime(time.time())
yesterday = time.localtime(now - 86400)
fileName = ('/data/dumps/messages_%s_%s.gz' % (yesterday[1], yesterday[2]))
handle = gzip.open(fileName, 'wb')
for doc in collection.find():
  if (now - (int(doc['created_at'])) > 0) and
     (now - int(doc['created_at']) < 86400):
    try:
      handle.write(u'%s %s %s "%s" message: "%s" full_message: "%s"\n' % (doc[u'host'],
       doc[u'facility'],
       doc[u'level'],
       time.ctime(int(doc['created_at'])),
       str(doc[u'message']).strip(),
       str(doc[u'full_message']).strip()))
    except:
      traceback.print_exc()
print "all done"
handle.close()

Запуск этого скрипта так же прост, как добавление в ваш локальный crontab.

Настройка клиента

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

class graylog_clients {
  file { "/etc/syslog.conf":
    owner => root,
    group => root,
    mode => 644,
    source => "puppet://puppet/puppetfiles/graylog_clients/etc/syslog.conf"
  }
  service { syslog:
    ensure => running,
    subscribe => File["/etc/syslog.conf"]
  }
  file { "/etc/gelfDaemon.conf":
    owner => root,
    group => root,
    mode => 644,
    source => "puppet://puppet/puppetfiles/graylog_clients/etc/gelfDaemon.conf"
  }
  file { "/usr/local/bin/gelfDaemon.py":
    owner => root,
    group => root,
    mode => 755,
    source => "puppet://puppet/puppetfiles/graylog_clients/usr/local/bin/gelfDaemon.py"
  }
  file { "/etc/init.d/gelfDaemon":
    owner => root,
    group => root,
    mode => 750,
    source => "puppet://puppet/puppetfiles/graylog_clients/etc/init.d/gelfDaemon"
  }
}
node /.*awesome-host-[0-9]$/ {
  include all_clients, app_servers, snort_servers, prod_servers, graylog_clients
}

Конфигурация для наших локальных серверов системного журнала, предоставляемых классом graylog_clients, очень проста:

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none    /var/log/messages
# The authpriv file has restricted access.
authpriv.*            /var/log/secure
# Log cron stuff
cron.*              /var/log/cron
# Everybody gets emergency messages
*.emerg             *
# Save news errors of level crit and higher in a special file.
uucp,news.crit            /var/log/spooler
# Save boot messages also to boot.log
local7.*            /var/log/boot.log
*.emerg         @awesome-graylog2-host
*.alert         @awesome-graylog2-host
*.crit          @awesome-graylog2-host
*.warning       @awesome-graylog2-host

Как видите, мы сделали очень мало в плане модификаций. Наш «Awesome Graylog2 Host» теперь получает все сообщения системного журнала, как и любой другой стандартный сервер системного журнала.

GELF Daemon

Наш демон GELF — это скрипт сбора журналов, который отслеживает журналы в режиме реального времени и передает их слушателю Graylog2 GELF, если они удовлетворяют определенным критериям. Мы написали это, чтобы решить некоторые проблемы, которые нелегко решить с помощью стандартного процесса syslog:

• Пересылка журналов, которые соответствуют регулярному выражению (и пропуск тех, которые не соответствуют)
• Объединение множества строк из одного события в одно сообщение журнала
• Создание нескольких хвостов в одном файле

Система, которая спровоцировала создание этого сценария, является одним из наших основных веб-приложений — очень, * очень * шумное приложение, которое любит создавать бесконечный поток отдельных строк журнала для одного запроса. Используя этот сценарий, мы можем получить краткую, единственную запись в Graylog2, когда возникают определенные исключения, вместо того, чтобы получать поток из множества отдельных записей журнала, как это было бы с простым перенаправителем системного журнала, не обрабатывающим символы новой строки.

Этот подход также творит чудеса для таких вещей, как медленные журналы MySQL. Мы можем включить это:

# Time: 120201 18:53:33
# User@Host: avidlifemedia_db[avidlifemedia_db] @ amazing-server [10.0.10.199]
# Thread_id: 1668392  Schema: awesome_production
# Query_time: 7.728352  Lock_time: 0.000049  Rows_sent: 1
# Rows_examined: 2475275  Rows_affected: 0  Rows_read: 1
SELECT things.* FROM blah...

Into this:
Time: 120201 18:53:33
User@Host: avidlifemedia_db[avidlifemedia_db] @ amazing-server [10.0.10.199]
Thread_id: 1668392  Schema: awesome_production
Query_time: 7.728352  Lock_time: 0.000049  Rows_sent: 1
Rows_examined: 2475275  Rows_affected: 0  Rows_read: 1
SELECT things.* FROM blah...

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

Демон GELF устанавливается Puppet, как и файл конфигурации для него. Единственное дополнительное действие — включить и запустить этот скрипт после установки модуля python-json.

yum install python-json -y
chkconfig gelfDaemon on
service gelfDaemon start