3.1 Списък на нивата на събитието
Регистрирането е процес на записване на всички събития, които се случват, докато програмата работи. Вашето задължение като програмист е, record everything important
защото тогава, когато production
има странни и/or сериозни грешки, няма да имате нищо друго освен тези регистрационни файлове.
Всяка грешка ще бъде отстранена многократно по-бързо, ако имате цялата информация за нея и за цялата история на обажданията. Но оттук следва едно просто заключение - да регистрирате всичко като цяло: извиквания на всички методи, стойности на всички параметри.
Това също не е опция - твърде много информация е също толкова лошо, колкото и твърде малко. Имаме нужда от интелигентно регистриране. Напequalsо от човек за човека. И тук стигаме до първия факт за логването – всички записи в журнала са разделени на категории още в момента на тяхното създаване.

Програмистът, когато записва събитие в дневника, трябва сам да реши колко важна е тази информация. Степента на сериозност на събитието се избира от автора на съобщението. Има log4j
5 нива на важност на регистрираната информация:
DEBUG
INFO
WARN
ERROR
FATAL
По-долу ще разкажем за тях по-подробно.
3.2 ОТСТРАНЯВАНЕ НА ГРЕШКИ
Нивото DEBUG
се счита за най-малко важно. Информацията, която се записва в регистрационния файл с това ниво на важност, е необходима само по време на отстраняване на грешки в приложението. За да се регистрира информация, необходима по време на отстраняване на грешки, се използва методът debug()
.
Пример:
class Manager {
private static final Logger logger = LoggerFactory.getLogger(Manager.class);
public boolean processTask(Task task) {
logger.debug("processTask id = " + task.getId());
try {
task.start();
task.progress();
task.complete();
return true;
} catch (Exception e) {
logger.error("Unknown error", e);
return false;
}
}
}
Обърнете внимание, методът debug
е в самото начало на метода (методът все още не е имал време да направи нищо) и записва стойността на променливата, предадена на метода, в журнала. Това е най-честият случай на използване на метода debug()
.
3.3 ИНФОРМАЦИЯ и ПРЕДУПРЕЖДЕНИЕ
Следващите две нива са INFO
и WARN
. Има два метода за тях - info()
и warn()
.
Нивото INFO
се използва просто за информационни съобщения: това и това се случва. Когато започнете да анализирате грешка в дневника, може да бъде много полезно да прочетете нейния фон. Методът е идеален за това info()
.
Нивото WARN
се използва за писане на предупреждения (от думата предупреждение ). Обикновено при това ниво на важност се пише информация, че нещо се е объркало, но програмата знае Howво да прави в тази ситуация.
Например, в процеса на записване на файл на диск се оказа, че такъв файл вече съществува. Тук програмата може да регистрира предупреждение (предупреждение), но да покаже на потребителя диалогов прозорец и да предложи да избере различно име на файл.
Пример:
class FileManager {
private static final Logger logger = LoggerFactory.getLogger(FileManager.class);
public boolean saveFile(FileData file) {
logger.info(“save the file ” + file.getName());
boolean resultOK = SaveUtils.save(file);
if (resultOK) return true;
logger.warn(“file writing problem ” + file.getName());
String filename = Dialog.selectFile();
boolean result = SaveUtils.save(file, filename);
return result;
}
3.4 ГРЕШКА и ФАТАЛ
И накрая, двете най-важни нива на регистриране са ERROR
и FATAL
. За тях има и специални методи със същите имена: error()
и fatal()
.
Те също решиха да разделят грешките на две категории - обикновени грешки и фатални грешки . Фаталната грешка най-често води до срив на приложението (за настолни applications) or срив на уеб услуга (за уеб applications).
Друг добър пример е операционната система Windows. Ако вашата програма току-що се е сринала, тогава от гледна точка на операционната система това е Error
. И ако самата операционна система е паднала и виждате синия екран на смъртта на Windows, тогава това вече е Fatal error
.
В applicationsта на Java събитията най-често Error
се Fatal
свързват с повдигнати изключения. Пример:
class Manager {
private static final Logger logger = LoggerFactory.getLogger(Manager.class);
public boolean processTask(Task task) {
logger.debug("processTask id = " + task.getId());
try {
task.start();
task.progress();
task.complete();
return true;
} catch (Exception e) {
logger.error("Unknown error", e);
return false;
}
}
}
3.5 Какво да регистрирате
Разбира се, не си струва да регистрирате всичко подред. В повечето случаи това рязко влошава четливостта на дневника и в крайна сметка дневникът се записва на първо място, за да бъде прочетен.
Освен това не можете да записвате различна лична и финансова информация в дневника. Сега с това стриктно и лесно можете да попаднете на глоби or съдебни дела. Рано or късно такъв труп ще изтече настрани и тогава няма да има проблеми.
И така, Howво трябва да се регистрира?
Първо, трябва да регистрирате началото на приложението . След стартиране на приложението се препоръчва да регистрирате неговия режим на работа и различни важни настройки - това ще улесни четенето на журнала в бъдеще.
Второ, трябва да регистрирате състоянието на всички услуги на трети страни , с които работи вашето приложение: системи за поща, всяHowви външни услуги. Като минимум трябва да осигурите момента на свързване с тях, за да сте сигурни, че работят правилно.
Трето, всички изключения трябва да бъдат регистрирани . Ако се очакват, тогава информацията за тях може да бъде написана компактно. Пълната информация за изключенията дава 50%-80% важна информация при търсене на грешка.
Трябва също така да регистрирате изключването на приложението . Приложението трябва да приключи нормално и да не извежда десетки грешки в дневника. Често на това място можете да намерите блокирани задачи, проблеми с пула от нишки or проблеми с изтриването на временни файлове.
Не забравяйте да регистрирате всичко, свързано със сигурността и оторизацията на потребителя . Ако потребител се опита да влезе or да нулира паролата си 10 пъти подред, тази информация трябва да бъде отразена в регистрационните файлове.
Регистрирайте възможно най-много информация за асинхронни задачи - изключенията често се губят в такива нишки. За асинхронна задача не забравяйте да регистрирате нейното начало и край. Успешното завършване трябва да се регистрира по същия начин като проблемното.
Какво друго? Стартиране на времеви задачи, стартиране на съхранени задачи SQL-procedures
, синхронизиране на данни, всичко свързано с разпределени транзакции. Мисля, че това е достатъчно за начало. Ще добавите към този списък в бъдеще.
GO TO FULL VERSION