У нас есть несколько (20+) серверов приложений, расположенных в нескольких дата-центрах. Нам нужно централизовать файлы журналов и отслеживать их из одного окна.
Требования:
Я хотел бы узнать мнение о том, как лучше всего централизовать эти файлы журналов?
Один из подходов, который мы придумали, заключался в использовании Logstash (http://logstash.net/) и Graylog2 (http://graylog2.org/), и отправьте события журнала по сети в модуль мониторинга, либо напрямую TCP, либо через шину, такую как RabbitMQ.
Второй подход - иметь «общий» том SAN, на который все серверы приложений будут записывать свои файлы журналов.
Каковы плюсы / минусы вышеуказанных подходов? Какие предостережения нам следует опасаться? Лучшие практики?
С открытым исходным кодом nxlog вы можете централизовать файлы журналов с хостов Linux и Windows. Он может пересылать по UDP, TCP, SSL, имеет мощные возможности фильтрации, дисковую буферизацию и множество других функций.
Просто настройте централизованный сервер журналов, syslog-ng (или rsyslogd как, кажется, последняя тенденция) и настройте ваши серверные приложения / системный журнал для входа на ваш сервер системного журнала. Этот подход является чистым и апробированным во всем мире.
5-10 ГБ на приложение в день - это неплохо, но не то, что перегрузит ваш syslog-ng. Нет, сэр, это требует больше усилий. Несколько тысяч строк в секунду - это то, что я просматриваю каждый день, а серверы системного журнала в основном простаивают.
Мне лично нравится syslog-ng, потому что он позволяет подключать и играть. Если вы добавите новые серверы, указывающие на ваш сервер системного журнала, syslog-ng автоматически создаст необходимую иерархию каталогов для своих файлов журнала, системный администратор не потребуется.
Я оценивал LogRhythm год назад, и эта услуга была действительно отличной. Посмотрите, они могут гораздо больше, чем просто централизовать ваши журналы. Оповещения, нормализация, отчетность и т. Д.
Взгляните на этот документ из rsyslog:
http://rsyslog.com/doc/rsyslog_reliable_forwarding.html
При такой настройке вы можете пересылать сообщения в удаленный системный журнал (или graylog2-server, поскольку он может прослушивать сообщения системного журнала), и если удаленный сервер не работает, он будет помещать его в очередь локально на диске. У меня были проблемы с пересылкой на graylog2 при высокой нагрузке, если graylog2 или elasticsearch (graylog2 использует его для хранения) не успевают за скоростью сообщений, он поставит их в очередь в памяти, после того как вы заполните всю доступную память, он просто зависнет, пока вы убить его (потеря всех сообщений).