Особенности структуры ведения журнала

Question

Я проектирую сервер для регистрации. Бизнес-логика для этого приложения написана на нескольких языках (C ++ и Java на данный момент, но другие языки могут быть добавлены в смесь на более позднем этапе.

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

Одним из важных соображений при проектировании (помимо обычных, таких как уровень ведения журнала) является производительность и поддержка нескольких целей ведения журнала (плоский файл, консоль, БД (?) И т. Д.).

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

Answer 1

Нужно ли делиться всеми вашими журналами?Я бы использовал любой механизм ведения журналов, который лучше всего подходит для каждой стадии логики (log4j или регистрация java в java, и я полагаю, что я не знаю библиотек журналирования C ++ достаточно, чтобы предложить одну).

По большей части,Журналы должны использоваться только для отладки и анализа вне приложения.Я бы не рекомендовал интегрировать ведение журналов как часть вашей бизнес-логики.Если вам действительно нужны данные в журналах, вам будет гораздо удобнее установить прямую связь, чем выплевывать журнал, чтобы он был украден другим приложением.

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

Answer 2

Проверьте это: http://logging.apache.org/log4j/1.2/manual.html

Взгляните на раздел производительности. Это поможет решить ваши проблемы, связанные с регистрацией в вашем приложении.

Что касается поддержки нескольких целей ведения журналов, это легко достижимо с помощью log4j, но вам нужно углубиться в некоторые детали (см. URL-адрес, который я вам опубликовал).

В общем, из моего опыта log4j отлично. Я сгенерировал тысячи статических и динамических журналов «значительного размера» (для моего приложения - этот термин может интерпретироваться по-разному для вашего приложения) без каких-либо проблем, несмотря на тяжелую обработку, которую я выполняю (для истории я оцениваю / моделирую распределенный алгоритм P2P в локальном ПК, и все идет хорошо, несмотря на создание сотен экземпляров регистратора для моделирования).

Answer 3

Есть данные, которые вы должны видеть в реальном времени, и данные, которые необходимо записать для автономной обработки. У них разные требования.

данные в реальном времени должны быть в машиночитаемом формате и обычно направлены в места, где они используются. Центральный регистратор может быть на этом пути, если он не задерживает информацию в реальном времени недопустимо. Для этого я бы использовал сокеты (или JMS), а не буферизованный файл.

Журналы автономной обработки могут быть в машиночитаемом формате (для ночных отчетов) или для чтения человеком (для отладки). Для этого я бы использовал файл или базу данных или и то, и другое. Файл может быть проще в управлении, особенно если он большой. База данных облегчает построение отчетов.

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