Журналы с серверов с балансировкой нагрузки

Question

Извините, если это звучит как основной вопрос, но я новичок в веб-разработке.

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

Является ли это нормой для регистрации веб-приложений? Или есть простые решения для консолидации регистрации в одном месте? Каковы стандартные методы создания журналов, которые легко доступны разработчикам?

Answer 1

Зарегистрируйтесь на SQL, используя JDBC appender (или alternative version) вместо файлов.

Answer 2

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

Некоторых типов:

• Вход на встроенном в журналах машины (журнал событий или похожий.).
  Для этого получите доступ, чтобы вы могли получить к ним доступ удаленно, а также сопоставить/изучить по мере необходимости.
• Ведение журнала приложениями, которые обычно записываются в текстовые файлы на локальном компьютере. (IIS или другие.)
  Получите доступ к папкам, чтобы вы могли проанализировать их сами.
• Пользовательские регистрации.
  Я рекомендую войти в базу данных. (Хотя их необходимо часто обрезать/обобщать).
  Если при сбое регистрации в базе данных происходит сбой в машинных журналах.
  Примечание: это может повлиять на производительность, поэтому будьте осторожны, сколько вы делаете.

Если операции не хотят давать вам прямой доступ, посмотрите, можно ли создать резервную копию этих файлов в том месте, к которому вы можете получить доступ.

Answer 3

Log4J имеет как JMS appender (так что вы можете отправлять журналы в очередь сообщений - не так глуп, как это звучит в зависимости от того, сколько/какой вид обработки вам нужно сделать) и syslog Appender (локальный или удаленный) , Любой из них поможет вам собирать журналы в одном месте. Syslog appender может быть лучшим выбором только для того, чтобы собирать вещи в одном месте, поскольку системы Unix-ish очень долго выполняли syslog, и есть много стабильных функций, которыми вы можете воспользоваться.

Регистрация в базе данных может быть сложной для масштабирования в зависимости от вашего трафика, если вы не умны в отношении пакетных вставок. Я бы порекомендовал вам хранить этот материал в плоских файлах (например, объединен, конечно), чтобы вы могли гибко импортировать их в базу данных позже, или экспериментировать с такими вещами, как Hadoop (много примеров, основанных на анализе файлов журнала) - если у вас есть объем, чтобы оправдать эту сложность, конечно.

Answer 4

Одним из возможных вариантов облегчения доступа к журналам является запись их на общий диск с использованием NFS. Вы можете сделать некоторые манипуляции с отдельными каталогами на сервер, но у них есть оба этих каталога, видимые на сервере, на котором вы хотите оценить журналы.

Answer 5

У нас есть веб-ферма с надежной регистрацией, и вот как она реализована.

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

Использование MSMQ отделяет веб-приложение от сервера регистрации. Если сервер не подключен, сообщения размещаются на веб-сервере до тех пор, пока соединение не будет восстановлено. MSMQ обрабатывает перенос сообщений на целевой сервер. Таким образом, веб-сайт может продолжать делать свою работу без перерыва.

Сервер регистрации имеет свой собственный веб-интерфейс для запроса базы данных ведения журнала и может получать сообщения журнала из других приложений.

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