Я хочу, чтобы каждый сервер отправлял журналы в / var / log и копировал их на удаленный сервер syslog-ng. Я слышал анекдоты о том, как удаленное ведение журнала может повредить ваше приложение, если в сети возникнут проблемы. Должен ли я беспокоиться о том, что мое приложение зависает при удаленном входе в систему, и как мне это исправить / обойти?
Нет. Во-первых, передача обслуживания является асинхронной в локальной операционной системе. Библиотеки системного журнала и локальный демон системного журнала либо примут сообщение и не смогут доставить его, либо быстро завершат работу, но в любом случае ваше приложение не зависнет. Во-вторых, сетевой протокол - (по умолчанию) udp, поэтому даже если ваше приложение заблокировано до тех пор, пока пакет не будет отправлен, он мгновенно уйдет и вернет управление вашему приложению, независимо от того, действительно ли оно дойдет до узла сбора.
Когда люди думают об удаленном ведении журнала, висящем на земле * nix, обычно это связано с тем, что они регистрировались на монтировании nfs, что, безусловно, может вызвать зависания. Системный журнал, вы в порядке.
Как и в случае с bagter / growse и gparent, описанным выше, я также столкнулся с ситуацией, когда вызовы vsyslog () зависают (от 30 до 20 минут) при использовании syslog-ng, когда удаленный сервер недоступен.
Замечу, что для воспроизведения этого мне пришлось перезагрузить syslog-ng (перезагрузка службы syslog-ng), пока удаленный сервер был недоступен (я фактически отключил сетевой порт на коммутаторе), и я одновременно генерировал значительный трафик для отправки на удаленный сервер.
также обратите внимание, что я веду журнал через UDP, что, как вы ожидаете, облегчит неблокирующую функцию срабатывания и забывания.
Я оптимистично настроен, что могу охарактеризовать это достаточно хорошо, чтобы сообщить об ошибке в syslog-ng, и обновлю здесь, если / когда я это сделаю.
Это действительно может произойти - существует ряд ситуаций, в которых может произойти такая блокировка, и все они в основном сводятся к заполнению очереди или буфера системного журнала, поэтому запись задерживается.
Это (обычно) имеет тенденцию усугублять проблему, потому что что-то начинает давать сбой и хочет сигнализировать об этом, но нужно дождаться, пока syslog примет их сообщения.
Обратите внимание, что есть также ошибки, которые могут вызвать неправильное поведение в таких ситуациях - в частности, rsyslog вызвал эту проблему на RH (https://bugzilla.redhat.com/show_bug.cgi?id=519203). Поэтому я определенно рекомендую проверять версии вашего программного обеспечения на наличие известных ошибок.
Также проверьте настройки DNS вашего системного журнала - для клиентов, отправляющих системный журнал, я не могу придумать никаких причин для использования DNS. Для принимающего сервера если вы можете обойтись без поиска DNS, возможно, стоит попробовать посмотреть, помогает ли это пропускной способности.
К счастью, есть также ряд исправлений (не специально для syslog-ng), но вам нужно будет пойти на какой-то компромисс, это короткая версия.
Если вы можете смириться с потерей некоторых данных, можно переключить ведение журнала на UDP. Очевидно, что, учитывая тип проблемы, которую вы описываете, кажется почти наверняка, что если вы сделаете это, вы воля потерять некоторые данные.
Другой вариант - более избирательно подходить к тому, что вы отправляете по сети, то есть фильтровать и / или устанавливать приоритеты одних потоков над другими. Насколько это помогает, частично зависит от того, какие параметры доступны в выбранной вами реализации системного журнала - у rsyslog довольно много параметров, с другими я не очень знаком.
Не всегда обязательно входить в сеть напрямую. Вы могли бы подумать о том, чтобы этого не делать, а вместо этого использовать какой-то агент анализа / анализа журнала (что-то вроде https://www.elastic.co/products/logstash) - это позволяет избежать касания работающей настройки системного журнала, сохраняя при этом удаленное ведение журнала (вы также можете настроить прослушивание агента на локальном хосте и пересылку данных системного журнала локально, если вы в настоящее время не храните данные в файле).
Аналогичным образом я бы порекомендовал вам проверить свою политику auditd и посмотреть, есть ли что-нибудь, что могло бы вызвать проблему. Примечательно, что если auditd ведет журнал в системном журнале, поток может быть весьма значительным, даже (или особенно) при использовании конфигураций «передовой практики» (например, тестов CIS). Я видел, что это вызывает проблемы в нескольких областях, и в некоторых случаях, когда audispd больше не может отправлять сообщения в системный журнал, он может блокироваться.
Наконец, для таких вещей, как rsyslog, у вас также есть варианты использования очереди диска и памяти для решения подобных проблем. Требуется небольшая настройка (rsyslog см. http://www.rsyslog.com/doc/v8-stable/concepts/queues.html), но позволяет построить гораздо более отказоустойчивую установку, если вы не против потратить ресурсы на решение проблемы.
Rsyslog предоставляет руководство по настройке высокой производительности (http://www.rsyslog.com/doc/v8-stable/examples/high_performance.html) и отказоустойчивые серверы системного журнала (http://www.rsyslog.com/doc/v8-stable/tutorials/failover_syslog_server.html). Я определенно рекомендую вам хотя бы исследовать центральный сервер журналов, чтобы убедиться, что он может справиться с объемом журналирования - и настроить его в противном случае (у меня был хороший опыт выполнения этого с помощью rsyslog, где довольно `` стандартная '' конфигурация приемника не успевала, но настройка позволила нам поддерживать на несколько порядков больше трафика).
Кроме того, подумайте о том, чтобы пересмотреть вашу конфигурацию ведения журнала в более общем плане - я знаю из (печального) опыта, что люди могут иметь тенденцию включать ведение журнала TRACE или DEBUG и оставлять его включенным, что обычно не делает syslog (или систему в целом) тоже много одолжений.
Я знаю, что это старое сообщение, но отвечу, если на эту страницу попадут другие люди.
Мы видели случай, когда удаленное ведение журнала приводит к зависанию сервера. Syslog-ng при потере сетевого доступа к своему лог-хосту начинает буферизацию. И когда буфер заполняется, он перестает читать из /dev/log файл, который становится "полным", что приводит к сбою нашего аудита, пытается записать в /dev/log.