Как настроить центральный сервер регистрации и разделить события регистрации от тестирования и производства? - PullRequest
Новая
       15

Как настроить центральный сервер регистрации и разделить события регистрации от тестирования и производства?

2 голосов
/ 24 апреля 2009

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

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

if (!production)
  logWrapper.logTest(error);
else 
  logWrapper.logProd(error);

Я не хочу этого, потому что он тесно связывает что-то, например имя сервера, ссылается на него, и теперь код может работать только с одним из двух имен серверов: prod и test. Также я не могу декларативно установить это в конфигурации из-за вероятности того, что разработчик не установит это правильно и не загрязнит репозитории журналов. Есть предложения?

Несколько деталей, некоторые не будут учитываться, но я все равно перечислю их:

  • Только веб-приложения, работающие на Oracle Application Server 10.1.3.4 сейчас и в будущем Oracle WebLogic
  • будет использовать центральный сервер регистрации, как показано в этом примере: http://timarcher.com/?q=node/10 ... ЗА ИСКЛЮЧЕНИЕМ, что центральный сервер будет регистрировать текстовые файлы и не будет отправлять электронную почту!
  • Будет использовать log4j и, возможно, он будет обёрнут через slf4j (slf4j отчасти неуважительно упоминать, поэтому игнорируйте его по большей части ..)

Ответы [ 6 ]

2 голосов
/ 24 апреля 2009

Без большого количества подробностей о вашей среде сложно дать конкретный ответ, но если бы я настраивал ведение журнала для обработки нескольких сред, вот подход, который я бы выбрал.

1) Приложения не должны заботиться о регистрации. Например, следующее должно работать во всех средах: 

logger.warn("message", error);

2) Создайте конфигурацию log4j (или любую другую структуру ведения журнала) для настройки ведения журнала. Это можно сделать одним из двух способов. Первый способ - создать test_log4j. {Xml, properties}, prod_log4j. {Xml, properties} и т. Д. Для каждой среды. Это делает настройку для каждой среды очень простой, а добавить новую среду - просто добавить новый файл. Альтернативой является создание одного log4j. {Xml, properties} и использование замены свойства стиля ant для вставки соответствующих значений для каждой среды. Значения свойств могут быть получены из файлов свойств среды или из аргументов -Dkey = value, передаваемых в JVM. Это больше стиль СУХОЙ конфигурации, предполагающий, что конфигурация для каждой среды очень похожа. В качестве примера для изменения уровня ведения журнала между средами: 

<logger name="my.example">
  <level value="${my.example.level}"/>
</logger>

3) Создайте сценарий запуска, который определяет среду (возможно, на основе компьютера или какого-либо файла на компьютере), а затем загружает правильную конфигурацию. Это может быть либо правильная конфигурация log4j, либо правильные файлы свойств, либо правильные аргументы -Dkey = value.

1 голос
/ 25 апреля 2009

Эта конкретная проблема решена в logFaces , фактически это одна из основных проблем, которую она должна была решить - централизовать и уменьшить затопление журналов. В конфиге вашего приложения. Вы указываете имя приложения, например, «Мое производственное приложение». Все выписки из приложения будут поступать на централизованный сервер регистрации и будут доступны в хранилище для запросов и в режиме реального времени. Вы не меняете свой код, это всего лишь вопрос конфигурации. Обычно у нас есть несколько экземпляров одного и того же приложения в разработке и несколько версий в QA, каждый разработчик может настроить свое средство просмотра для извлечения того, что происходит на других. Я часто слежу за хостами QA и знаю, что есть проблема еще до того, как они ее осознают. Другой интересный сценарий - это когда вы хотите увидеть, что происходит во всех приложениях одновременно, но сосредоточиться только, скажем, на уровне данных.

Раскрытие информации : я являюсь автором этого продукта.

1 голос
/ 24 апреля 2009

Вы не упомянули, какую СУБД вы используете. Если вы используете Oracle, вы можете использовать функцию SYS_CONTEXT (), чтобы получить имя базы данных. Оттуда вы можете определить, находитесь ли вы в разработке / dev / qa / test / etc.

Вот хорошая статья о sys_context ()

0 голосов
/ 08 мая 2009

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

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

Когда дело доходит до самой настройки сервера, я бы сказал, просто зайдите в syslog или журнал событий Windows NT с соответствующей настройкой log4j. Таким образом, вы можете также регистрировать другие части конечных систем на том же сервере регистрации. Хорошая система журналирования тогда показала бы, на каком сервере было сгенерировано событие, поэтому должно быть достаточно ясно, произошло ли событие от prod или тестирования.

Для хорошего веб-интерфейса системного журнала, вы можете проверить http://www.phplogcon.org/

0 голосов
/ 24 апреля 2009

Я действительно думаю, что вам нужно установить это в конфиге. Это правильное решение.

0 голосов
/ 24 апреля 2009

Используйте различные файлы конфигурации ведения журнала для производства и подготовки.

Вы можете сделать это несколькими разными способами

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

2) Просто имейте один файл, но заменяйте его соответствующим файлом при тестировании или производстве.

...