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

Question

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

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

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

Answer 1

Вход в SQL с использованием приложения JDBC (или альтернативная версия ) вместо файлов.

Answer 2

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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