Java жүйесіне кіру: немен, қалай, қайда және немен?

Барлығына сәлем, JavaRush қауымдастығы! Бүгін біз Java журналы туралы сөйлесетін боламыз:

1. Бұл не, неге олай. Қандай жағдайларда қолданған дұрыс, қандай жағдайда олай емес?
2. Java-да тіркеуді іске асырудың қандай түрлері бар және бұл әртүрлілікпен не істеуіміз керек?
Тіркеу деңгейлері. Қосымшаның не екенін және оны қалай дұрыс конфигурациялау керектігін талқылайық.
3. Тіркеу түйіндері және оларды қалай дұрыс конфигурациялау керек, сонда бәрі біз қалағандай жұмыс істейді.

Бұл материал кең аудиторияға арналған. Бұл Java-мен енді танысып жатқандарға да, қазірдің өзінде жұмыс істеп жатқандарға да түсінікті болады, бірақ оны logger.info(“log something”); Let's Go арқылы ғана түсінді!

Тіркеу не үшін қажет?

Кіру мәселені шешетін нақты жағдайларды қарастырайық. Міне, менің жұмысымнан мысал. Басқа қызметтермен біріктірілген қолданба нүктелері бар. Мен бұл нүктелерді тіркеуді «алиби» ретінде қолданамын : егер интеграция жұмыс істемесе, мәселенің қай жағынан шыққанын анықтау оңай болады. Сондай-ақ дерекқорда сақталған маңызды ақпаратты тіркеу ұсынылады. Мысалы, әкімші пайдаланушысын жасау. Бұл журналға кіру жақсы болар еді.

Java журналын жүргізу құралдары

Java жүйесіне кіруге арналған белгілі шешімдерге мыналар жатады:

• log4j
• JUL - java.util.logging
• JCL - jakarta commons журналы
• Кіру
• SLF4J - java үшін қарапайым каротаж қасбеті

System.err.println

Бастапқыда, әрине, System.err.println болды (консольге шығаруды жазу). Ол әлі де жөндеу кезінде журналды жылдам алу үшін пайдаланылады. Әрине, бұл жерде ешқандай параметрлер туралы айтудың қажеті жоқ, сондықтан оны еске түсіріп, әрі қарай жалғастырайық.

Log4j

Бұл әзірлеушілердің қажеттіліктерінен жасалған толыққанды шешім болды. Бұл өте қызықты құрал болып шықты. Әртүрлі жағдайларға байланысты бұл шешім ешқашан JDK-ге кірмеді, бұл бүкіл қауымдастықты қатты ренжітті. log4j жүйесінде конфигурациялау опциялары болды, осылайша журнал жүргізуді бумада қосуға com.example.typeжәне ішкі бумада өшіруге болады com.example.type.generic. Бұл тіркеуге қажет нәрсені қажет емес нәрселерден жылдам ажыратуға мүмкіндік берді. Мұнда log4j екі нұсқасы бар екенін атап өткен жөн : 1.2.x және 2.x.x, олар бір-бірімен үйлеспейді . log4j қосымшасы сияқты тұжырымдаманы қосты , яғни журналдар жазылатын және орналасу - журналды пішімдеу құралы. Бұл сізге қажет нәрсені және оны қалай қажет ететінін ғана жазуға мүмкіндік береді. Қосымша туралы сәл кейінірек айтатын боламыз.

JUL - java.util.logging

Негізгі артықшылықтардың бірі шешім болып табылады - JUL JDK (Java әзірлеу жинағы) құрамына кіреді. Өкінішке орай, оның дамуы кезінде танымал log4j негізі емес, оның дамуына әсер еткен IBM шешімі болды. Негізі қазір JUL бар, бірақ оны ешкім қолданбайды. «Солай-соңынан»: шілдеде тіркеу деңгейлері Logback, Log4j, Slf4j жүйелеріндегіден ерекшеленеді және бұл олардың арасындағы түсінікті нашарлатады. Тіркелгіні жасау азды-көпті ұқсас. Ол үшін импорттау керек:

java.util.logging.Logger log = java.util.logging.Logger.getLogger(LoggingJul.class.getName());

Класс атауы журналдың қайдан келетінін білу үшін арнайы беріледі. Java 8-ден бастап өтуге болады Supplier<String>. Бұл жолды бұрынғыдай әр уақытта емес, шынымен қажет болған кезде ғана санауға және жасауға көмектеседі. Тек Java 8 шығарылымымен әзірлеушілер маңызды мәселелерді шешті, содан кейін JUL шын мәнінде қолдануға жарамды болды. Supplier<String> msgSupplierАтап айтқанда, төменде көрсетілгендей аргументі бар әдістер :

public void info(Supplier<String> msgSupplier) {
   log(Level.INFO, msgSupplier);
}

JCL - jakarta commons журналы

Ұзақ уақыт бойы ағаш кесуде салалық стандарт болмағандықтан және көптеген адамдар өздерінің жеке тіркеуші журналын жасаған кезең болғандықтан, олар JCL - басқаларға қолданылатын жалпы қаптаманы шығаруға шешім қабылдады. Неліктен? Кейбір тәуелділіктер жобаға қосылғанда, олар жобадағы тіркеушіге қарағанда басқа тіркеушіні пайдалана алады. Осыған байланысты олар жобаға өтпелі түрде қосылды, бұл барлығын біріктіруге тырысқанда нақты қиындықтар туғызды. Өкінішке орай, қаптаманың функционалдығы өте нашар болды және ешқандай толықтырулар енгізбеді. Әркім өз жұмысын орындау үшін JCL пайдаланса, ыңғайлы болар еді. Бірақ іс жүзінде олай болмады, сондықтан JCL пайдалану қазіргі уақытта жақсы идея емес.

Кіру

Ашық дереккөздің жолы қаншалықты қиын... Logback оның мұрагерін жасау үшін log4j сияқты әзірлеушімен жазылған. Идея log4j сияқты болды. Айырмашылықтар тіркелу кезінде болды:

• жақсартылған өнімділік;
• slf4j үшін қосымша жергілікті қолдау;
• Сүзу опциясы кеңейтілді.

Әдепкі бойынша, кері кіру кез келген параметрлерді қажет етпейді және DEBUG деңгейіндегі және одан жоғары барлық журналдарды жазады. Конфигурация қажет болса, оны xml конфигурациясы арқылы жасауға болады:

<configuration>
    <appender name="FILE" class="ch.qos.logback.core.FileAppender">
        <file>app.log</file>
        <encoder>
            <pattern>%d{HH:mm:ss,SSS} %-5p [%c] - %m%n</pattern>
        </encoder>
    </appender>
    <logger name="org.hibernate.SQL" level="DEBUG" />
    <logger name="org.hibernate.type.descriptor.sql" level="TRACE" />
    <root level="info">
        <appender-ref ref="FILE" />
    </root>
</configuration>

SLF4J - java үшін қарапайым каротаж қасбеті

Шамамен 2006 жылы log4j негізін қалаушылардың бірі жобаны тастап, slf4j - Java үшін Қарапайым журнал жасау қасбетін жасады - log4j, JUL, ортақ логгиндер және логбек айналасындағы қаптама. Көріп отырғаныңыздай, ілгерілеу олардың қаптаманың үстіне орауыш жасағанына жетті... Оның үстіне ол екі бөлікке бөлінеді: қолданбада қолданылатын API және қосымша ретінде қосылатын іске асыру. тіркеудің әрбір түрі үшін бөлек тәуелділіктер. Мысалы, slf4j-log4j12.jar, slf4j-jdk14.jar. Дұрыс іске асыруды байланыстыру жеткілікті және бұл: бүкіл жоба онымен жұмыс істейді. Slf4j журналға арналған жолды пішімдеу сияқты барлық жаңа мүмкіндіктерді қолдайды. Бұрын мұндай мәселе болған. Журнал жазбасы бар делік:

log.debug("User " + user + " connected from " + request.getRemoteAddr());

Жолды біріктіруге байланысты нысанда userжасырын түрлендіру бар user.toString()және бұл уақытты талап етеді, бұл жүйені баяулатады. Қолданбаны жөндеуден өтсек, бәрі жақсы. Бұл сынып үшін тіркеу деңгейі INFO және одан жоғары болса, мәселелер басталады. Яғни, бұл журналды жазуға болмайды және жолды біріктіру де орындалмауы керек. Теориялық тұрғыдан мұны журналдар кітапханасының өзі шешуі керек еді. Оның үстіне, бұл log4j бірінші нұсқасының ең үлкен мәселесі болып шықты. Олар қалыпты шешімді жеткізбеді, бірақ оны келесідей орындауды ұсынды:

if (log.isDebugEnabled()) {
    log.debug("User " + user + " connected from " + request.getRemoteAddr());
}

Яғни, бір журнал жолының орнына 3(!) жазуды ұсынды. Тіркеу codeтағы өзгерістерді азайтуы керек және үш жол жалпы көзқарасқа қайшы келеді. slf4j-де JDK және API-мен үйлесімділік мәселелері болмады, сондықтан әдемі шешім бірден пайда болды:

log.debug("User {} connected from {}", user, request.getRemoteAddr());

мұндағы {}әдісте берілген аргументтерді кірістіруді білдіреді. Яғни, біріншісі -ге , екіншісі - -ге {}сәйкес келеді . Осыған байланысты, егер журналға тіркеу деңгейі журналға рұқсат берсе ғана, бұл хабарды бір хабарламаға біріктіруге болады. Осыдан кейін SJF4J тез танымал болды және қазіргі уақытта ең жақсы шешім болып табылады. Сондықтан, біз бума мысалын пайдаланып журналды қарастырамыз . user{}request.getRemoteAddr()slf4j-log4j12

Нені тіркеу керек

Әрине, сіз бәрін тіркемеуіңіз керек. Кейде бұл қажетсіз және тіпті қауіпті. Мысалы, егер сіз біреудің жеке деректерін кепілге берсеңіз және ол қандай да бір жолмен белгілі болса, әсіресе Батысқа бағытталған жобаларда нақты проблемалар туындайды. Бірақ міндетті түрде тіркелетін нәрсе бар :

1. Қолданбаның басталуы/соңы. Қолданба біз күткендей іске қосылып, күткендей аяқталғанын білуіміз керек.
2. Қауіпсіздік сұрақтары. Бұл жерде парольді болжау әрекеттерін тіркеу, маңызды пайдаланушылардың логиндерін тіркеу және т.б.
3. Кейбір қолданба күйлері . Мысалы, бизнес процесінде бір күйден екінші күйге көшу.
4. Сәйкес тіркеу деңгейімен жөндеуге арналған кейбір ақпарат .
5. Кейбір SQL сценарийлері. Бұл қажет болған нақты жағдайлар бар. Тағы да, деңгейлерді шебер реттеу арқылы тамаша нәтижелерге қол жеткізуге болады.
6. Орындалған ағындарды (Thread) дұрыс жұмыс тексерілген жағдайларда тіркеуге болады.

Танымал тіркеу қателері

Көптеген нюанстар бар, бірақ мұнда бірнеше жалпы қателер бар:

1. Артық тіркеу. Теориялық тұрғыдан маңызды болуы мүмкін әрбір қадамды тіркемеу керек. Ереже бар: журналдар өнімділікті 10% артық емес жүктей алады. Әйтпесе өнімділік проблемалары болады.
2. Барлық деректерді бір файлға тіркеу. Бұл белгілі бір уақытта оқуды/жазуды қиындатады, белгілі бір жүйелерде файл өлшеміне шектеулер бар екенін айтпағанда.
3. Қате тіркеу деңгейлерін пайдалану. Әрбір тіркеу деңгейінің анық шекаралары бар және оларды сақтау керек. Егер шекара анық емес болса, сіз қай деңгейді пайдалану керектігін келісе аласыз.

Тіркеу деңгейлері

Тіркеу деңгейлері қандай? Журналдарды қандай да бір дәрежеде разрядтау үшін белгілі бір белгілер мен айырмашылықтарды беру қажет болды. Осы мақсатта ағаш кесу деңгейлері енгізілді. Деңгей қолданбада орнатылған. Егер жазба белгіленген деңгейден төмен деңгейге жататын болса, ол журналға енгізілмейді. Мысалы, бізде қолданбаны жөндеу үшін пайдаланылатын журналдар бар. Қалыпты өндірістік жұмыста (қолданбаны мақсатты түрде пайдаланған кезде) мұндай журналдар қажет емес. Сондықтан журналға жазу деңгейі жөндеуге қарағанда жоғары болады. Мысал ретінде log4j көмегімен деңгейлерді қарастырайық. JUL-дан басқа басқа шешімдер бірдей деңгейлерді пайдаланады. Мұнда олар төмендеу ретімен:

• ӨШІРУЛІ: журналдар жазылмайды, барлығы еленбейді;
• FATAL: қате, одан кейін қолданба жұмыс істей алмайды және тоқтатылады, мысалы, JVM жадтың жеткіліксіздігі қатесі;
• ҚАТЕ: Шешілуі қажет мәселелер болған кездегі қателік деңгейі. Қате қолданбаны тұтастай тоқтатпайды. Басқа сұраулар дұрыс жұмыс істеуі мүмкін;
• ЕСКЕРТУ: ескертуі бар журналдарды көрсетеді. Күтпеген әрекет орын алды, соған қарамастан жүйе қарсылық көрсетіп, сұрауды аяқтады;
• INFO: қолданбадағы маңызды әрекеттерді жазатын журнал. Бұл қателер емес, бұл ескертулер емес, бұл жүйенің күтілетін әрекеттері;
• DEBUG: қолданбаны жөндеу үшін қажет журналдар. Жүйе өзінен күтілетін нәрсені дәл орындауын қамтамасыз ету немесе жүйенің әрекетін сипаттау үшін: «1-әдіс жұмыс істей бастады»;
• TRACE: ең төменгі тіркеу деңгейімен жөндеуге арналған төменгі басымдылық журналдары;
• БАРЛЫҚ: жүйедегі барлық журналдар жазылатын деңгей.

Қолданбаның бір жерінде INFO журналын тіркеу деңгейі қосылса, INFO-дан бастап және FATAL-ға дейінгі барлық деңгейлер журналға жазылады. Тіркеу деңгейі ӨЛКЕН болса, тек осы деңгейі бар журналдар жазылады.

Журналдарды жазу және жіберу: Қосымша

Біз бұл процесті log4j арқылы мысал ретінде қарастырамыз: ол журналдарды жазу/жіберу үшін кең мүмкіндіктер береді:

• файлға жазу үшін - шешім DailyRollingFileAppender ;
• қолданба консоліне деректерді алу үшін - ConsoleAppender ;
• деректер базасына журналдарды жазу үшін - JDBCAppender ;
• TCP/IP арқылы жіберуді басқару үшін - TelnetAppender ;
• журнал жүргізу өнімділікке әсер етпейтініне көз жеткізу үшін - AsyncAppender .

Бірнеше басқа іске асыру бар: толық тізімді мына жерден табуға болады . Айтпақшы, егер қажетті қосымша қол жетімді болмаса, бұл мәселе емес. Log4j файлын қабылдайтын Appender интерфейсін енгізу арқылы өзіңіздің қосымшаңызды жаза аласыз .

Тіркеу түйіндері

Демонстрация үшін біз slf4j интерфейсін және log4j іске асыруды қолданамыз. MainDemoТіркелгіні жасау өте қарапайым: журналға тіркеу жүргізілетін классқа келесіні жазу керек :

org.slf4j.Logger logger = org.slf4j.LoggerFactory.getLogger(MainDemo.class);

Бұл біз үшін тіркеуші жасайды. Журнал жазбасын жасау үшін жазбалар қандай деңгейде жасалатынын көрсететін көптеген әдістерді қолдануға болады. Мысалы:

logger.trace("Method 1 started with argument={}", argument);
logger.debug("Database updated with script = {}", script);
logger.info("Application has started on port = {}", port);
logger.warn("Log4j didn't find log4j.properties. Please, provide them");
logger.error("Connection refused to host = {}", host);

Біз сыныптан өтіп жатсақ та, соңында пакеттері бар сыныптың толық аты жазылады. Бұл кейінірек тіркеуді түйіндерге бөлуге және әрбір түйін үшін тіркеу деңгейін және қосымшаны теңшеуге болатындай етіп жасалады. Мысалы, сыныптың аты: com.github.romankh3.logginglecture.MainDemo- онда тіркеуші құрылды. Міне, оны тіркеу түйіндеріне бөлуге болады. Негізгі түйін нөлдік RootLogger болып табылады . Бұл бүкіл қолданбаның барлық журналдарын қабылдайтын түйін. Қалғанын төменде көрсетілгендей бейнелеуге болады: Қосымшалар өз жұмысын журналға тіркеу түйіндерінде арнайы конфигурациялайды. Енді мысал ретінде log4j.properties пайдалану арқылы біз оларды конфигурациялау жолын қарастырамыз.

Log4j.properties қадамдық конфигурациясы

Енді біз бәрін кезең-кезеңмен реттеп, не істеуге болатынын көреміз:

log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender

Бұл жол org.apache.log4j.ConsoleAppender іске асыруын пайдаланатын CONSOLE қосымшасын тіркеп жатқанымызды айтады. Бұл қосымша мәліметтерді консольге жазады. Содан кейін файлға жазатын басқа қосымшаны тіркейік:

log4j.appender.FILE=org.apache.log4j.RollingFileAppender

Қосымшаларды әлі де конфигурациялау қажет болатынын ескеру маңызды. Бізде тіркелген қосымшалар болғаннан кейін, біз түйіндерде қандай тіркеу деңгейі болатынын және қандай қосымшалар қолданылатынын анықтай аламыз.

log4j.rootLogger=DEBUG, ПОНСОЛ, ФАЙЛ

• log4j.rootLogger барлық журналдарды қамтитын негізгі түйінді конфигурациялайтынымызды білдіреді;
• теңдік белгісінен кейін бірінші сөз журналдардың қай деңгейде және одан жоғары жазылатынын көрсетеді (біздің жағдайда бұл DEBUG);
• содан кейін үтірден кейін қолданылатын барлық қосымшалар көрсетіледі.

Арнайы тіркеу түйінін конфигурациялау үшін келесі жазбаны пайдалану қажет:

log4j.logger.com.github.romankh3.logginglecture=TRACE, OWN, CONSOLE

мұнда log4j.logger.ол белгілі бір түйінді конфигурациялау үшін пайдаланылады, біздің жағдайда бұл. com.github.romankh3.logginglecture. Ал енді CONSOLE қосымшасын орнату туралы сөйлесейік:

# CONSOLE appender customisation
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.threshold=DEBUG
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=[%-5p] : %c:%L : %m%n

Мұнда біз қосымша өңдейтін деңгейді орнатуға болатынын көреміз. Нақты жағдай: ақпарат деңгейі бар хабарламаны тіркеу түйіні қабылдады және оған тағайындалған қосымшаға жіберілді, бірақ ескерту деңгейі және одан жоғары қосымша бұл журналды қабылдады, бірақ онымен ештеңе істемеді. Әрі қарай, хабарламада қандай үлгі болатынын шешу керек. Мен мысалда PatternLayout пайдаланамын, бірақ мұнда көптеген шешімдер бар. Олар осы мақалада ашылмайды. FILE қосымшасын орнату мысалы:

# File appender customisation
log4j.appender.FILE=org.apache.log4j.RollingFileAppender
log4j.appender.FILE.File=./target/logging/logging.log
log4j.appender.FILE.MaxFileSize=1MB
log4j.appender.FILE.threshold=DEBUG
log4j.appender.FILE.MaxBackupIndex=2
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.layout.ConversionPattern=[ %-5p] - %c:%L - %m%n

Мұнда сіз журналдардың қай файлға жазылатынын конфигурациялай аласыз, оны көруге болады

log4j.appender.FILE.File=./target/logging/logging.log

Жазба файлға өтеді logging.log. Файл өлшеміне қатысты проблемаларды болдырмау үшін максималды орнатуға болады: бұл жағдайда 1 МБ. MaxBackupIndex - мұндай файлдардың қанша болатынын айтады. Осы саннан көп жасалса, бірінші файл жойылады. Тіркеу конфигурацияланатын нақты мысалды қарау үшін GitHub жүйесіндегі ашық репозиторийге өтуге болады.

Нәтижені біріктірейік

Өзіңіз сипатталғанның бәрін орындап көріңіз:

• Жоғарыдағы мысалдағыға ұқсас жеке жобаңызды жасаңыз.
• Егер сізде Maven пайдалану туралы біліміңіз болса, біз оны пайдаланамыз; егер жоқ болса, онда кітапхананы қалай қосу керектігін сипаттайтын мақалаға сілтеме .

Жинақтау

1. Біз Java-да қандай шешімдер бар екенін айттық.
2. Барлық дерлік белгілі журнал кітапханалары бір адамның бақылауымен жазылған: D
3. Біз нені тіркеу керектігін және нені тіркеу керектігін білдік.
4. Біз тіркеу деңгейлерін анықтадық.
5. Біз каротаждық түйіндермен таныстық.
6. Біз қосымшаның не екенін және ол не үшін қажет екенін қарастырдық.
7. Біз log4j.proterties файлын қадам бойынша конфигурацияладық.

Қосымша материалдар

1. JavaRush: журнал жүргізу. Стектрас допын босатыңыз
2. JavaRush: Логер лекциясы
3. Хабар: Java журналын жүргізу. Сәлем Әлем
4. Habr: Java журналы: қорқынышты түс туралы оқиға
5. Youtube: Головач курстары. Тіркеу. 1-бөлім , 2-бөлім , 3-бөлім , 4-бөлім
6. Log4j: қосымша
7. Log4j: орналасу

Менің басқа мақалаларымды да қараңыз:

• Әңгімелесу тесті қалай ашық бастапқы кітапханаға айналды
• Әуе билеттерінің бағасын бақылау жүйесін құру: қадамдық нұсқаулық [1 бөлім]
• Skyscanner API үшін клиент құру және оны jCenter және Maven Central жүйесінде жариялау бойынша нұсқаулық [1-бөлім]
• Intellij IDEA жүйесінде жөндеу: жаңадан бастаушыларға арналған нұсқаулық