Журналы со сбалансированных с загрузки серверов
Извините меня, если это походит на основной вопрос, но я плохо знаком с веб-разработкой.
Мы загружаем баланс через несколько серверов. Приложения настроены для входа использования log4j. Каждый из них пишет в файлы журнала на их соответствующих серверах. Это означает, что исследование проблем означает получать журналы от всех этих серверов, которые утомительны, и означают проходить операцию в секунду, поскольку они управляют выравниванием нагрузки, и представляет задержки.
Действительно ли это - норма для входа веб-приложения? Или есть ли легкие решения консолидации входа в систему одного места? Что такое общепринятая практика для того, чтобы сделать журналы легко доступными разработчикам?
5 ответов
Выполнить вход в SQL с помощью JDBC-приложения (или альтернативной версии ) вместо файлов.
There is a wide variety of logging you can do, and which is available automatically.
Some types are:
- Logging to built in machine logs, (Event logs or similiar.).
For these, get access granted so you can access them remotely, and collate/examine as required. - Logging by applications which typically log to text files on the local machine. (IIS, or other.)
Получите доступ к папкам, чтобы вы могли анализировать их самостоятельно. - Пользовательское ведение журнала.
Я рекомендую войти в базу данных. (Хотя их нужно часто сокращать / резюмировать.)
Если запись в базу данных не удалась, происходит запись в журналы машины.
Примечание. Это может повлиять на производительность, поэтому будьте осторожны при ведении журнала.
Если операторы не желают предоставлять вам прямой доступ, посмотрите, можно ли выполнить дамп этих файлов в место, к которому вы можете получить доступ.
У нас есть веб-ферма с надежным ведением журнала, и вот как это реализовано.
Каждое веб-приложение генерирует сообщения журнала событий. С помощью MSMQ эти сообщения отправляются в частную очередь, размещенную на отдельном компьютере. На этой машине есть приложение, которое извлекает сообщения из очереди и записывает их в базу данных Sqlite.
Использование MSMQ отделяет веб-приложение от сервера журналов. Если сервер отключен, сообщения остаются на веб-сервере до тех пор, пока соединение не будет восстановлено. MSMQ обрабатывает перемещение сообщений на целевой сервер. Таким образом, веб-сайт может продолжать делать свою работу без перебоев.
Сервер регистрации имеет свой собственный веб-интерфейс для запроса базы данных регистрации и может также получать сообщения журнала от других приложений.
Мы назначаем классификацию каждому сообщению. Для сообщений с классификацией фатальных ошибок сервер журнала автоматически отправляет электронное письмо в службу поддержки. Другие нефатальные сообщения и сообщения трассировки просто записываются в базу данных для сводного отчета.
Log4J имеет оба приложения JMS (так что вы можете отправлять журналы в очередь сообщений - не так глупо, как кажется, в зависимости от того, сколько / какой вид обработки вам нужен делать!) и приложение системного журнала (локальное или удаленное). Любой из них поможет вам собрать журналы в одном месте. Приложение Syslog может быть вашим лучшим выбором просто для сбора информации в одном месте, так как Unix-системы уже очень давно используют syslog, и там есть много стабильных функций, из которых вы можете извлечь выгоду.
Запись в базу данных может быть трудной для масштабирования в зависимости от вашего трафика, если вы не разбираетесь в пакетных вставках. Я бы порекомендовал вам хранить эти вещи в плоских файлах (конечно же, слитых), чтобы у вас была возможность импортировать их в базу данных позже за один раз,
Один из возможных вариантов облегчения доступа к журналам - их запись на общий диск через NFS . Вы можете немного поработать с отдельными каталогами для каждого сервера, но при этом оба этих каталога будут видны на сервере, на котором вы хотите анализировать журналы.