Comments 51
Очень прошу вас — переделайте веб-интерфейс на Twitter bootstrap.
Это займет всего полчаса, но пользоваться будет гораздо приятнее.
Это займет всего полчаса, но пользоваться будет гораздо приятнее.
посмотрите в сторону шаблонов
это уменьшит ваш скрипт в размерах и увеличит его читаемость
это уменьшит ваш скрипт в размерах и увеличит его читаемость
Есть еще log.io
Стоит посмотреть на splunk
Интересная штука, есть фришная лицензия.
Интересная штука, есть фришная лицензия.
Не пробовали ли Вы в качестве базы данных использовать что-нибудь типа mongodb (в ветке syslog-ng 3.3)?
По идее, первый и основной плюс — отсутствие необходимости в logrotate при использовании capped collections.
Плюс ещё и шардинг из коробки — удобно при необходимости держать и анализировать большое количество логов. У меня это пока что это только на стадии планирования, так что по поводу быстродействия ничего не скажу.
По идее, первый и основной плюс — отсутствие необходимости в logrotate при использовании capped collections.
Плюс ещё и шардинг из коробки — удобно при необходимости держать и анализировать большое количество логов. У меня это пока что это только на стадии планирования, так что по поводу быстродействия ничего не скажу.
Пока что не приходилось работать с noSQL БД, но интерес вызывает.
graylog2.org/ здесь mongodb пробовали, решили в итоге отказаться. Медленно и нестабильно при неприличном потреблении ресурсов памяти.
Мммм… Здесь, скорее, речь идёт о стабильности модуля afmongodb для syslog-ng. Сама-то монга работает достаточно шустро и стабильна.
500млн capped collection и все, не едет больше ))
Интересно. Сегодня тестировал — получил в среднем 15-20 тысяч записей в секунду (пишем в facility local5 фразу «This is test»), но при этом получил проблему в монге — writelock наступает уже на 50-70 тысячах, и некоторое количество записей дропается.
По 500 млн — проверю обязательно, спасибо. У меня всего 2G capped, должно хватить.
По 500 млн — проверю обязательно, спасибо. У меня всего 2G capped, должно хватить.
Как бы базе плохо не стало при большом количестве машин в сети. Есть идея возможности складывания в Redis с последующим выгружением в любую бд кроном, например.
Везет вам, 6.5 Гб за 7 месяцев. У меня зачастую столько в сутки бывает на центральном сислоге.
Логи сыпятся не все, а только нужных сервисов
Эт точно. Только что архивил и отсылал на анализ лог 19Гб от одного сервиса за один день, а центральный сислог впахивает как проклятый так как на него не один сервис такой пишет. Уже нужно рассматривать другие альтернативы или распределенные сервера.
Везет вам, 6.5 Гб за 1 сутки. У меня в сутки собирается около 200+ гигов логов.
Второй пост за квартал на тему 'как я складировал логи в mysql'? Тогда вам сюда -> graylog2 -> graylog2.org/
Грейлог загибается под нагрузками только в путь.
Возможно. У меня порядка 20 сообщений в секунду, сервер 2xXeon E5440 16GB ram, LA на уровне 0.03. Есть еще Splunk на примерно такой же нагрузке и таком же сервере — LA анаологично. Поделитесь вашим решением и нагрузками.
Нет не загибается. Наш грейлог тащит 100-120 rps по пику в минуту, а всего в нем сейчас лежит 500000000, половина из которых в GELF.
Проблемы есть, конечно, но больше в логике. Баги пофиксят, а связка прет как танк. Ни одно другое решение вам такой производительности не даст при схожем функционале.
Проблемы есть, конечно, но больше в логике. Баги пофиксят, а связка прет как танк. Ни одно другое решение вам такой производительности не даст при схожем функционале.
недописал)) в минуту в среднем 6000.
Это мало. У меня 6000 прилетает за 4 секунды:
# time /usr/sbin/tcpdump -n port syslog -c 6000 > /dev/null
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
6000 packets captured
6000 packets received by filter
0 packets dropped by kernel
real 0m4.047s
user 0m0.052s
sys 0m0.023s
Спасибо, полезно, опробую.
А нет ли чего еще попроще, чтобы логи разных хостов тупо в разные подпапки писать, но на центральном сервере?
Сначала у меня так и было, писалось в разные файлы, но ето неудобно при чтении и поиске
Так различные destination у syslog-ng — самое простое. Описанное Вами делается в 1.5 строки.
Хм, надо еще разок попробовать. А то в один файл писать получалось, а вот в разные для каждого хоста — нет.
Ставим разные sources (на каждый хост свой), и далее различные destination для каждого source. Логично, ИМХО.
/etc/rsyslog.d/50-default.conf:
(только вот не смог заставить СОЗДАВАТЬ папки при появлении новых хостов, пришлось забить имена всех существующих)
$template DynFile,"/var/log/%HOSTNAME%/%programname%.log"
$template MyTemplate,"%timegenerated% %HOSTNAME% %syslogtag% %msg%\n"
*.* ?DynFile;MyTemplate
&~(только вот не смог заставить СОЗДАВАТЬ папки при появлении новых хостов, пришлось забить имена всех существующих)
Кто-нибудь вообще думал о защите от подделки логов?!
Концепт:
злоумышленник (зная о централизованном сборе) заваливает сервер UDP-сообщениями об попытках SSH-логина с разных хостов, тем самым маскируя свои попытки-> Админ бросает тщетные попытки найти в мусоре истину.
Концепт:
злоумышленник (зная о централизованном сборе) заваливает сервер UDP-сообщениями об попытках SSH-логина с разных хостов, тем самым маскируя свои попытки-> Админ бросает тщетные попытки найти в мусоре истину.
Как видно из етой таблицы, фришная версия syslog-ng поддержывает TCP протокол и криптование, правда как оно там реализовано не углублялся
если злоумышленник имеет доступ к внутренней сети, или если файервол не режет udp с внешних сетей
А зачем разрешать слать на сислог сообщения всем кому ни попадя? Только доверенной сети, где и живет инфраструктура.
Посмотрите в сторону бесплатных систем мониторинга. Тот же, zenoss, например. Кроме централизованного syslog умеет ещё много чего полезного. Мониторинг ещё никому не мешал, тем более если оборудования много.
Sign up to leave a comment.
Централизованный syslog