Как настроить центральный сервер регистрации и разделить события регистрации от тестирования и производства?
Как лучше всего настроить центральный сервер журналирования (или, возможно, 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 ответов
Без большого количества подробностей о вашей среде сложно дать конкретный ответ, но если бы я настраивал ведение журнала для обработки нескольких сред, вот подход, который я бы выбрал.
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.
Вы не упомянули, какую СУБД вы используете. Если вы используете Oracle, вы можете использовать функцию SYS_CONTEXT(), чтобы получить имя базы данных. Оттуда вы можете определить, находитесь ли вы в разработке / dev / qa / test / etc.
Эта конкретная проблема решается в logFaces, на самом деле это одна из основных проблем, которую она должна была решить - централизовать и уменьшить затопление журналов. В вашем приложении конфиг. Вы указываете имя приложения, например, "Мое производственное приложение". Все выписки из приложения будут поступать на централизованный сервер регистрации и будут доступны в хранилище для запросов и в режиме реального времени. Вы не меняете свой код, это всего лишь вопрос конфигурации. Обычно у нас есть несколько экземпляров одного и того же приложения в разработке и несколько версий в QA, каждый разработчик может настроить свое средство просмотра для извлечения того, что происходит на других. Я часто слежу за хостами QA и знаю, что есть проблема еще до того, как они ее осознают. Другой интересный сценарий - это когда вы хотите увидеть, что происходит во всех приложениях одновременно, но сосредоточиться только на, скажем, уровне данных.
Раскрытие: я являюсь автором этого продукта.
Используйте разные файлы конфигурации регистрации для производства и подготовки.
Вы можете сделать это несколькими разными способами
1) Сохраните в своем приложении два разных файла конфигурации (один для этапа и один для производства), и пусть ваше приложение имеет некоторый код запуска, который знает, какой файл конфигурации использовать, в зависимости от того, на каком компьютере он находится, или, возможно, некоторые настройки в файле конфигурации приложений. это устанавливает настройку среды.
2) Просто имейте один файл, но заменяйте его соответствующим файлом при тестировании или в производстве.
Mattkemp в значительной степени прибил этот. Единственное, что я могу добавить, это то, что ключевое различие между производством и тестированием, которое я ожидаю, заключается в том, что у test-версии, вероятно, будет постоянно активна запись отладки, в то время как в prod вы будете активировать отладку только в редких случаях странного поведения.,
Кроме этого, по крайней мере, я бы ожидал примерно одинаковые типы записей журнала при тестировании и производстве, поскольку все, что может произойти во время тестирования, может происходить и во время производства (и будет).
Когда дело доходит до самой настройки сервера, я бы сказал, просто зайдите в syslog или журнал событий Windows NT с соответствующей настройкой log4j. Таким образом, вы можете также регистрировать другие части конечных систем на том же сервере регистрации. Хорошая система журналирования тогда показала бы, на каком сервере было сгенерировано событие, поэтому должно быть достаточно ясно, произошло ли событие от prod или тестирования.
Для хорошего веб-интерфейса системного журнала, вы можете проверить http://www.phplogcon.org/
Я действительно думаю, что вам нужно установить это в конфиге. Это правильное решение.