3.1 Списък на нивата на събитието

Регистрирането е процес на записване на всички събития, които се случват, докато програмата работи. Вашето задължение като програмист е, record everything importantзащото тогава, когато productionима странни и/or сериозни грешки, няма да имате нищо друго освен тези регистрационни файлове.

Всяка грешка ще бъде отстранена многократно по-бързо, ако имате цялата информация за нея и за цялата история на обажданията. Но оттук следва едно просто заключение - да регистрирате всичко като цяло: извиквания на всички методи, стойности на всички параметри.

Това също не е опция - твърде много информация е също толкова лошо, колкото и твърде малко. Имаме нужда от интелигентно регистриране. Напequalsо от човек за човека. И тук стигаме до първия факт за логването – всички записи в журнала са разделени на категории още в момента на тяхното създаване.

Списък на нивата на събитието

Програмистът, когато записва събитие в дневника, трябва сам да реши колко важна е тази информация. Степента на сериозност на събитието се избира от автора на съобщението. Има log4j5 нива на важност на регистрираната информация:

  • 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, синхронизиране на данни, всичко свързано с разпределени транзакции. Мисля, че това е достатъчно за начало. Ще добавите към този списък в бъдеще.