EDL — Enterprise Dynamic Logger
Долго думал в какой блог можно поместить этот топик: в «Я пиарюсь» или «Java», но остановился на «Java», чтобы получить максимальное количество отзывов и предложений да еще и максимально профессиональных.
Итак, представляю вам Enterprise Dynamic Logger (EDL).
EDL — это тул/фреймворк для несколько другой парадигмы логгинга. В основном нужен для работы в условиях, когда код на сервере менять нельзя и сам сервер перезагружать тоже нельзя. Т.е. production environment.
Общий подход — предварительная автоматическая расстановка log statement’ов в ключевых местах (вход-выход из метода, catch блоки и т.п.) и дальнейшее их динамическое включение runtime с помощью флажков со странички управления EDL.
Кейс использования довольно типичный —где-то на далёком сервере вылетает ошибка. Сходу понять из-за чего — трудно. Но есть предположение, что вот такой метод не вызвался или вызвался не с теми аргументами. Но воспроизвести ошибку локально не получается/долго/трудоёмко. Зато можно было бы посмотреть вызывался ли метод и с какими параметрами прямо на удалённом сервере, но вот незадача — в нужных местах, конечно же, нет логов.
В случае если на сервере установлен EDL (или классы обработаны таской EDL) предлагается следующее:
Установка EDL может осуществляться либо подменой Class Loader, либо во время/после компиляции приложения — через bytecode processing.
Плюсы:
Можно использовать как фреймворк для сбора статистики работы путём расстановки expression’ов, которые вызывают свои custom-счётчики и аналогично хранить такие настройки в отдельных файлах. Менять их на production без риска уронить сервер и необходимости перевыдачи приложения с новыми, расставленными вручную, вызовами к счётчикам.
Про эту разработку можно говорить еще очень и очень много, придумывать способы ее применения, но сейчас очень бы хотелось услышать твое мнение, уважаемый %username%, обо всем услышанном. Где бы ты хотел/мог/мечтал использоватьчто-то подобное? Чего не хватает этой разработке? Какие слабые места ты видишь?
Итак, представляю вам Enterprise Dynamic Logger (EDL).
EDL — это тул/фреймворк для несколько другой парадигмы логгинга. В основном нужен для работы в условиях, когда код на сервере менять нельзя и сам сервер перезагружать тоже нельзя. Т.е. production environment.
Общий подход — предварительная автоматическая расстановка log statement’ов в ключевых местах (вход-выход из метода, catch блоки и т.п.) и дальнейшее их динамическое включение runtime с помощью флажков со странички управления EDL.
Кейс использования довольно типичный —
В случае если на сервере установлен EDL (или классы обработаны таской EDL) предлагается следующее:
- Заходим на страничку EDL управления логированием,
- включаем логгер,
- выбираем методы, которые нужно логировать,
- добавляем по необходимости java expression’ы (чтобы логировать не каждый вызов, а только нужные),
- жмём кнопку Apply
Установка EDL может осуществляться либо подменой Class Loader, либо во время/после компиляции приложения — через bytecode processing.
Плюсы:
- Возможность вести анализ, когда код на сервере просто физически недоступен.
- Безопасные изменения, нет риска получить эксепшены, т.к. добавляются не произвольные рукописные лог-вызовы, а стандартные по шаблону (использование expressions — это отдельный разговор).
- Оптимизированный фреймворк. Во включённом состоянии (без учёта самого процесса записи log сообщений) вносит overhead в пределах всего 1-2% для типичного enterprise use case’а. В выключенном — ещё меньше.
- Аспектный подход к логированию — не нужно включать шаблонные лог стейменты («myMethod start», «myMethod end») в сам код в куче мест. Т.е. настройки логгинга можно описать в нескольких отдельных от кода xml файлах (например, по одному на модуль).
Можно использовать как фреймворк для сбора статистики работы путём расстановки expression’ов, которые вызывают свои custom-счётчики и аналогично хранить такие настройки в отдельных файлах. Менять их на production без риска уронить сервер и необходимости перевыдачи приложения с новыми, расставленными вручную, вызовами к счётчикам.
Про эту разработку можно говорить еще очень и очень много, придумывать способы ее применения, но сейчас очень бы хотелось услышать твое мнение, уважаемый %username%, обо всем услышанном. Где бы ты хотел/мог/мечтал использовать
комментарии (48)