Ведение журнала является фундаментальной частью приложений. Каждое приложение имеет различный вид механизма ведения журнала. Хорошо спроектированная система регистрации — это огромная утилита для системных администраторов и разработчиков, особенно для группы поддержки. Журналы экономят много ценных часов как для службы поддержки, так и для разработчиков. Когда пользователи выполняют программы на внешнем интерфейсе, система незаметно создает хранилище информации о событиях (записи журнала) для системных администраторов и группы поддержки.
После определения его значения давайте попробуем выяснить требования к ведению журналов для приложения. В новых версиях Java есть стандартный API ведения журналов (java.util.logging). Log4J также известная библиотека для ведения журналов. Мы внедрили прозрачную «услугу ведения журнала» в нашу структуру приложения. Вы можете предпочесть какие-либо реализации ведения журналов, но есть некоторые другие важные вопросы, на которые вы должны ответить при разработке приложения: что регистрировать, когда регистрировать, сколько регистрировать, как контролировать ведение журналов и как соотносить их с системой исключений. ,
Что войти
Некоторые исключения приложения должны регистрироваться: почему не регистрировать все исключения? Некоторые исключения являются управляемыми исключениями, которые генерируются приложением как предупреждение или как ошибка проверки для пользователя. Если все ошибки проверки или исключения приложения включены в журналы, журналы теряют свою полезность. Он будет содержать много записей, это затрудняет поиск ценных записей. Здесь мы должны различать исключения, если они должны быть зарегистрированы.
Мы использовали интерфейс меток Loggable, чтобы определить, включен ли он в журналы. Другая лучшая практика — иметь единый глобальный обработчик исключений. Таким образом, разработчики приложений не беспокоятся о регистрации любых исключений, которые они генерируют. Один обработчик исключений означает единый и аккуратный механизм регистрации исключений.
Некоторые события приложения должны регистрироваться: для основных компонентов приложения мы можем регистрировать события жизненного цикла, такие как запуск, остановка и перезапуск. Некоторые события, связанные с безопасностью, могут регистрироваться, например, попытки несанкционированного доступа по URL-адресу, вход в систему пользователя и т. Д. Некоторые пороговые значения ресурса могут быть превышены и должны также регистрироваться.
Некоторые состояния приложения должны регистрироваться: в некоторых кодах мы должны спросить: «Что может пойти не так в этом коде». Если это состояние возникает, мы можем сгенерировать исключение или зарегистрировать его (если мы не хотим прерывать текущий процесс) с некоторыми уровнями, такими как Ошибка, Предупреждение или Информация. Например, если соединение обычно освобождается, когда оно не передано, эта информация может быть записана как незафиксированное соединение, что указывает на некоторые проблемы с кодом приложения.
Некоторая отладочная информация может быть записана в журнал: В некоторых приложениях могут быть ошибки, и вы не можете найти причину этого. Вы можете добавить некоторые журналы отладки в свой код и повторно развернуть его для диагностики проблемы. Некоторые хронические ошибки заслуживают следов отладки, которые не могут быть обнаружены в среде разработки.
Выполненные SQL могут быть зарегистрированы: в некоторых случаях мы можем захотеть получить оператор SQL, выполняемый приложением. Мы должны легко включить вход без запуска / остановки системы. Допустим, пользователь жалуется на неверный результат отчета при выполнении отчета. Если мы не имеем понятия об этом, мы можем зарегистрировать SQL и отследить его.
Пользовательские HTTP-запросы могут быть зарегистрированы: нам может понадобиться то, что исходит от пользователя с полной информацией о параметрах. Чтобы добиться такого рода регистрации, мы должны подключить службу регистрации к сервлетам и страницам JSP.
Выполнение потоков может быть зарегистрировано: я упомянул реализацию BlackBox в наших приложениях в одном из моих предыдущих постов. Вы можете записать информацию о выполняющихся потоках в этот черный ящик, чтобы выяснить, что может пойти не так в случае сбоя системы.
Ошибки JavaScript могут регистрироваться: это может рассматриваться как первый элемент, но его реализация полностью отличается. У вас должен быть глобальный обработчик исключений JavaScript. В обработчике вы отправляете ошибку JavaScript с помощью AJAX для входа на сервер (при условии, что это не ошибка AJAX).
Некоторые лучшие практики
Как я уже говорил выше, система обработки исключений является важной отправной точкой для ведения журнала. Во всех наших сервлетах и JSP блоки основного кода имеют следующую структуру для обеспечения глобальной обработки исключений. Этот стандарт исключает работу регистрации исключений разработчиками (прозрачная унифицированная регистрация):
Мы назвали «Log Medium», чтобы указать, где хранить записи журнала, но в Java logging API это называется Handlers. Для некоторых типов журналов журналы базы данных удобны, так как вы можете выполнять мощные SQL-запросы к таблице журналов, что просто возможно в файлах.
Чтобы назначить сообщения журнала соответствующим уровням журнала также важно. В противном случае некоторые неправильные предупреждения могут ввести в заблуждение системных администраторов.
Мы использовали поток System.err для ведения журналов на уровне приложения, который совпадает с e.printStackTrace (), который может быть напечатан одновременно с нашей записью журнала глобального обработчика. Нам не понадобится трассировка стека всех исключений, но некоторые могут быть очень полезны, чтобы увидеть, где находится корень проблемы (например, StackOverflowException).
При регистрации исключений мы использовали следующий формат. В некоторых статьях рекомендуется включать предложение об отказе при сбое, но я думаю, что эта информация должна предоставляться пользователю, не включенному в журналы. Журналы редко читаются, но исключения находятся перед пользователями.
Запись в журнале должна отвечать на следующие вопросы: кто (имя пользователя) , когда ( отметка времени) , где (контекст, ServletOrPage, база данных) , что (команда) , результат (исключение)
В кластерной среде следует учитывать ведение журнала. Мы отделили один и тот же тип файлов журнала с суффиксом имени узла кластера к имени файла. В противном случае одновременная запись в журнал может привести к некоторым проблемам. system_node01.log system_node02.log
И, наконец, регистрация может быть очень интересным фактором снижения производительности. Если приложения начинают много регистрировать, производительность приложений может сильно упасть. У меня есть реальная история для этого. Однажды мы забыли включить файл образа в пакет развертывания. Он использовался на каждой странице. Когда мы запускали систему после установки, отклик страницы был очень медленным. Файлы журнала кажутся достаточно маленькими, что может не вызвать проблем. После открытия и чтения файлов журнала мы поняли, что частота журналов (с указанием изображения отсутствует) была высокой, и это вызывало проблему. В заключение, размер вашего файла журнала и частота записи журнала должны быть небольшими.
