Java кирүү: эмне, кантип, кайда жана эмне менен?

Баарына салам, JavaRush коомчулугу! Бүгүн биз Java журналы жөнүндө сүйлөшөбүз:

1. Бул эмне, эмне үчүн. Кандай учурларда колдонуу жакшы, кайсы учурда андай эмес?
2. Java'да журналды ишке ашыруунун кандай түрлөрү бар жана бул көп түрдүүлүк менен эмне кылышыбыз керек?
Каттоо деңгээли. Келгиле, appender деген эмне экенин жана аны кантип туура конфигурациялоону талкуулайлы.
3. Түйүндөрдү каттоо жана аларды кантип туура конфигурациялоо керек, баары биз каалагандай иштеши үчүн.

Бул материал кеңири аудиторияга арналган. Бул Java менен жаңыдан таанышып жаткандар үчүн да, иштеп жаткандар үчүн да түшүнүктүү болот, бирок аны logger.info(“log something”); Let's Go менен гана түшүнгөн!

Каттоо эмне үчүн керек?

Келгиле, токойду кесүү көйгөйдү чече турган реалдуу учурларды карап көрөлү. Мына менин ишимден бир мисал. Башка кызматтар менен интеграцияланган колдонуу пункттары бар. Мен бул пункттарды каттоону “алиби” катары колдоном : интеграция иштебесе, көйгөй кайсы тараптан келип чыкканын аныктоо оңой болот. Ошондой эле маалымат базасына сакталган маанилүү маалыматты каттоо сунушталат. Мисалы, администратор колдонуучуну түзүү. Дал ушул нерсе кирүү үчүн жакшы болмок.

Java Logging Tools

Java менен кирүү үчүн белгилүү чечимдерге төмөнкүлөр кирет:

• log4j
• JUL - java.util.logging
• JCL - Jakarta commons logging
• Кирүү
• SLF4J - java үчүн жөнөкөй каротаждык фасад

System.err.println

Башында, албетте, System.err.println (консолго жаздырылган чыгаруу) бар болчу. Ал дагы эле мүчүлүштүктөрдү оңдоо учурунда журналды тез алуу үчүн колдонулат. Албетте, бул жерде эч кандай орнотуулар жөнүндө сөз кылуунун кереги жок, андыктан аны эстеп, уланталы.

Log4j

Бул иштеп чыгуучулардын муктаждыктарынан жаралган толук кандуу чечим болгон. Бул колдонуу үчүн абдан кызыктуу курал болуп чыкты. Ар кандай жагдайлардан улам, бул чечим эч качан JDKке кирген эмес, бул бүт коомчулукту капа кылды. log4j конфигурациясынын параметрлерине ээ болгон, андыктан журнал жазуу пакетте күйгүзүлүп com.example.type, субпакетте өчүрүлгөн com.example.type.generic. Бул журналга жазылуу керек болгонду керексизден тез ажыратууга мумкундук берди. Бул жерде log4j эки versionсы бар экенин белгилей кетүү маанилүү : 1.2.x жана 2.x.x, алар бири-бирине туура келбейт . log4j мындай концепцияны кошту appender , башкача айтканда, журналдар жазыла турган курал жана жайгашуу - log форматтоо. Бул сизге эмне керек жана кандайча керек экенин гана жазууга мүмкүндүк берет. Аппендер жөнүндө бир аз кийинчерээк сүйлөшөбүз.

JUL - java.util.logging

Негизги артыкчылыктарынын бири чечим болуп саналат - JUL JDK (Java өнүктүрүү комплекти) киргизилген. Тилекке каршы, аны иштеп чыгуу учурунда популярдуу log4j негизи эмес, IBM компаниясынын чечими анын өнүгүшүнө таасирин тийгизген. Негизи учурда ЖУЛ бар, бирок аны эч ким колдонбойт. "Ошентип-мындан": ИЮЛ-да журналдарды каттоо деңгээли 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 logging

Узак убакыт бою жыгач кесүүдө тармактык стандарт жок болгондуктан жана көптөгөн адамдар өздөрүнүн жеке логгерди түзгөн мезгor болгондугуна байланыштуу, алар JCLди чыгарууну чечишти - башкаларга колдонула турган жалпы орогуч. Неге? Долбоорго кээ бир көз карандылыктар кошулганда, алар долбоордогу логгерге караганда башка логгерди колдонушу мүмкүн. Ушундан улам, алар проектке өтмө түрдө кошулуп, бардыгын бириктирүүгө аракет кылып жатканда реалдуу көйгөйлөрдү жаратты. Тилекке каршы, орогуч функционалдык жактан абдан начар болгон жана эч кандай кошумчаларды киргизген эмес. Эгер ар бир адам өз ишин жасоо үчүн JCL колдонсо, балким ыңгайлуу болмок. Бирок чындыгында андай болгон жок, андыктан JCL колдонуу азыркы учурда жакшы идея эмес.

Кирүү

Ачык булактын жолу кандай гана тикенектүү... Logback бир эле иштеп чыгуучу тарабынан log4j менен жазылган, анын уландысын түзүү үчүн. Идея log4j сыяктуу эле. Айырмачылыктар каттоо эсебинде болгон:

• жакшыртылган аткаруу;
• slf4j үчүн кошумча жергorктүү колдоо;
• Чыпкалоо опциясы кеңейтилди.

Демейки боюнча, кайра каттоо эч кандай орнотууларды талап кылbyte жана 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 үчүн Simple Logging Facade - log4j, JUL, Common-loggins жана logback айланасында орогуч түздү. Көрүнүп тургандай, прогресс алар оромонун үстүнө орогуч жараткан чекитке жетти... Анын үстүнө, ал эки бөлүккө бөлүнөт: тиркемеде колдонулган API жана катары кошулган ишке ашыруу. журналдын ар бир түрү үчүн өзүнчө көз карандылык. Мисалы, slf4j-log4j12.jar, slf4j-jdk14.jar. Бул туура ишке ашырууну туташтыруу үчүн жетиштүү болуп саналат жана бул: бүт долбоор аны менен иштейт. Slf4j журналды жазуу үчүн сап форматтоо сыяктуу бардык жаңы функцияларды колдойт. Буга чейин мындай көйгөй болгон. Келгиле, журнал жазуусу бар дейли:

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

Объектте сапты бириктирүүдөн улам userжашыруун конversion бар user.toString()жана бул системаны жайлатуучу убакытты талап кылат. Эгерде биз тиркемени оңдосок, баары жакшы болот. Бул класс үчүн журнал жазуу деңгээли INFO жана андан жогору болсо, көйгөйлөр башталат. Башкача айтканда, бул журналды жазууга болбойт жана саптарды бириктирүү да аткарылбашы керек. Теориялык жактан алганда, муну журнал китепканасынын өзү чечиши керек болчу. Андан тышкары, бул log4j биринчи versionсынын эң чоң көйгөйү болуп чыкты. Алар кадимки чечимди беришкен жок, бирок муну мындай кылууну сунушташты:

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

Башкача айтканда, бир каротаждык саптын ордуна 3(!) деп жазууну сунушташты. Каттоо codeго өзгөртүүлөрдү азайтуу керек жана үч сап жалпы мамилеге так карама-каршы келет. slf4jде JDK жана API менен шайкештик көйгөйлөрү болгон эмес, ошондуктан дароо эле кооз чечим пайда болду:

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

бул жерде {}методдо өткөрүлүүчү аргументтерди киргизүүнү белгилейт. Башкача айтканда, биринчи {}туура келет user, экинчи {}- request.getRemoteAddr(). Ушундан улам, журналга жазуу деңгээли журналга жол берсе гана, бул кабарды бир билдирүүгө бириктирүүгө болот. Андан кийин, SJF4J тез популярдуулукка ээ болуп, азыркы учурда эң жакшы чечим болуп саналат. Ошондуктан, биз пакеттин мисалын колдонуп журнал жазууну карап чыгабыз slf4j-log4j12.

Эмнени жазуу керек

Албетте, баарын каттабашыңар керек. Кээде бул керексиз, атүгүл коркунучтуу. Мисалы, кимдир бирөөнүн жеке маалыматтарын күрөөгө коюп, ал кандайдыр бир жол менен ачыкка чыкса, өзгөчө Батышка багытталган долбоорлордо реалдуу көйгөйлөр жаралат. Бирок, ошондой эле милдеттүү түрдө бир нерсе бар :

1. Колдонмонун башталышы/аягы. Колдонмо чындыгында биз күткөндөй ишке кирип, күтүлгөндөй аяктаганын бorшибиз керек.
2. Коопсуздук суроолору. Бул жерде сырсөздү болжолдоо аракеттерин, маанилүү колдонуучулардын логиндерин ж.б. киргизүү жакшы болмок.
3. Кээ бир арыз мамлекеттер . Мисалы, бизнес процессинде бир абалдан экинчи абалга өтүү.
4. Мүчүлүштүктөрдү оңдоо үчүн кээ бир маалымат , журналдын тийиштүү деңгээли менен.
5. Кээ бир SQL скрипттери. Бул зарыл болгон реалдуу учурлар бар. Дагы бир жолу, денгээлдерди билгичтик менен тууралоо менен эң сонун натыйжаларга жетишүүгө болот.
6. Аткарылган жиптер (Thread) туура иштеши текшерилген учурларда катталышы мүмкүн.

Популярдуу каттоо каталары

Көптөгөн нюанстар бар, бирок бул жерде бир нече жалпы каталар бар:

1. Ашыкча жазуу. Теориялык жактан маанилүү болушу мүмкүн болгон ар бир кадамды каттабаңыз. Эреже бар: журналдар аткарууну 10% дан ашык эмес жүктөй алат. Болбосо, аткаруу көйгөйлөрү пайда болот.
2. Бардык маалыматтарды бир файлга киргизүү. Бул белгилүү бир учурда аны окуу/жазууну абдан кыйындатат, белгилүү бир системаларда файлдын өлчөмү боюнча чектөөлөр бар.
3. Туура эмес каттоо деңгээлин колдонуу. Ар бир каротаждын деңгээли так чектерге ээ жана аларды урматтоо керек. Эгерде чек так эмес болсо, кайсы деңгээлди колдонуу керектиги боюнча макулдаша аласыз.

Каттоо деңгээли

Каттоо деңгээли кандай? журналдарды кандайдыр бир даражада үчүн, ал белгилүү бир белгилерди жана айырмачылыктарды берүү үчүн зарыл болгон. Ушул максатта жыгач даярдоонун децгээли киргизилген. Деңгээл колдонмодо белгиленген. Эгерде жазуу белгиленгенден төмөн деңгээлге таандык болсо, анда ал журналга киргизилбейт. Мисалы, бизде тиркемени оңдоо үчүн колдонулган журналдар бар. Кадимки өндүрүш ишинде (тиркеме өз максатына ылайык колдонулганда) мындай журналдар керек эмес. Демек, журналды жазуу деңгээли мүчүлүштүктөрдү оңдоого караганда жогору болот. Мисал катары log4j аркылуу деңгээлдерди карап көрөлү. JULдан башка чечимдер ошол эле деңгээлдерди колдонушат. Бул жерде алар төмөндөө иретинде:

• ӨЧҮРҮҮ: эч кандай журналдар жазылbyte, бардыгы эске алынbyte;
• ӨЛҮМЧҮ: ката, андан кийин колдонмо иштебей калат жана токтойт, мисалы, JVM эстутумда катасы;
• КАТА: Чечorши керек болгон көйгөйлөр бар кездеги ката ылдамдыгы. Ката бүтүндөй колдонмону токтотпойт. Башка суроолор туура иштеши мүмкүн;
• ЭСКЕРТҮҮ: эскертүү камтыган журналдарды көрсөтөт. Күтүлбөгөн иш-аракет болду, ага карабастан система каршылык көрсөтүп, өтүнүчтү аткарды;
• INFO: тиркемедеги маанилүү аракеттерди жазган журнал. Бул каталар эмес, бул эскертүүлөр эмес, бул системанын күтүлгөн аракеттери;
• DEBUG: тиркемени оңдоо үчүн керек болгон журналдар. Система андан күтүлгөн нерсени так аткарышын камсыз кылуу үчүн же системанын иш-аракетин сүрөттөө үчүн: "метод1 иштей баштады";
• TRACE: мүчүлүштүктөрдү оңдоо үчүн төмөнкү артыкчылыктуу журналдар, эң төмөнкү каттоо деңгээли менен;
• БАРДЫК: системанын бардык журналдары жазыла турган деңгээл.

Көрсө, INFO журналын жазуу деңгээли тиркеменин кайсы бир жеринде иштетилсе, INFOдон баштап, ӨЛҮМЧҮ чейин бардык деңгээлдер катталат. Каттоо деңгээли ӨЛҮМЧҮ болсо, бул деңгээли бар журналдар гана жазылат.

Каттоо жана жөнөтүү журналдары: Appender

Биз бул процессти мисал катары 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 колдонуп жатам, бирок ал жерде көптөгөн чечимдер бар. Алар бул макалада ачыкка чыгарылbyte. 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ди колдонуу боюнча бorмиңиз болсо, биз аны колдонобуз; эгерде жок болсо, анда бул жерде китепкананы кантип туташтыруу керектиги сүрөттөлгөн макалага шилтеме .

Жыйынтыктап көрөлү

1. Биз Javaда кандай чечимдер бар экендиги жөнүндө сүйлөштүк.
2. Дээрлик бардык белгилүү жыгач китепканалары бир адамдын көзөмөлү астында жазылган: D
3. Эмнени каттоо керек экенин жана эмнени жаздырбоо керектигин билдик.
4. Биз журналдын деңгээлин аныктадык.
5. Биз каротаждык түйүндөр менен тааныштык.
6. Апенди эмне экенин жана ал эмне үчүн экенин карап чыктык.
7. Биз log4j.proterties файлын этап-этабы менен конфигурацияладык.

Кошумча материалдар

1. JavaRush: Каттоо. Стектрастандын шарын бошотуңуз
2. JavaRush: Logger лекциясы
3. Habr: Java журналы. Салам дүйнө
4. Habr: Java журналы: түндүн окуясы
5. Youtube: Головач курстары. Каттоо. 1-бөлүк , 2-бөлүк , 3-бөлүк , 4-бөлүк
6. Log4j: тиркеме
7. Log4j: макет

Менин башка макалаларымды да караңыз:

• Кантип интервью тести ачык булак китепканасына айланган
• Авиа билеттерине баа мониторинг системасын түзүү: кадам-кадам колдонмо [1-бөлүк]
• Skyscanner API үчүн кардар түзүү жана аны jCenter жана Maven Centralда жарыялоо боюнча колдонмо [1-бөлүк]
• Intellij IDEAдагы мүчүлүштүктөрдү оңдоо: үйрөнчүктөр үчүн колдонмо