కోడ్జిమ్ సంఘంలోని ప్రతి ఒక్కరికీ హలో!
ఈ రోజు లాగింగ్ గురించి మాట్లాడుకుందాం:
- అది ఏమిటి, అది ఎందుకు ఉంది, మీరు ఎప్పుడు ఉపయోగించాలి, ఎప్పుడు నివారించాలి.
- జావాలో ఏ లాగింగ్ అమలులు అందుబాటులో ఉన్నాయి మరియు ఈ అన్ని లాగింగ్ ఎంపికలతో మీరు ఏమి చేయాలి.
మరియు లాగ్ స్థాయిలు. అనుబంధం అంటే ఏమిటి మరియు దానిని సరిగ్గా కాన్ఫిగర్ చేయడం గురించి మేము చర్చిస్తాము.
- లాగింగ్ నోడ్లు మరియు వాటిని ఎలా సరిగ్గా కాన్ఫిగర్ చేయాలి, తద్వారా ప్రతిదీ మనకు కావలసిన విధంగా పని చేస్తుంది.
ఈ పదార్థం విస్తృత ప్రేక్షకుల కోసం ఉద్దేశించబడింది. జావా గురించి తెలుసుకోవడం ఎవరికైనా స్పష్టంగా ఉంటుంది, అలాగే ఇప్పటికే పని చేస్తున్న వ్యక్తులకు మాత్రమే
logger.info("log something");
లెట్స్ గో!
మీకు లాగింగ్ ఎందుకు అవసరం?
లాగింగ్ సమస్యను పరిష్కరించగల కొన్ని వాస్తవ కేసులను చూద్దాం. నా పని నుండి ఇక్కడ ఒక ఉదాహరణ. అప్లికేషన్ ఇతర సేవలతో అనుసంధానించే పాయింట్లు ఉన్నాయి. నేను ఒక రకమైన
"అలిబి"ని స్థాపించడానికి ఈ పాయింట్ల వద్ద లాగింగ్ని ఉపయోగిస్తాను : ఇంటిగ్రేషన్ పని చేయకపోతే, ఏ వైపు సమస్య ఉందో గుర్తించడం సులభం అవుతుంది. డేటాబేస్లో నిల్వ చేయబడిన ముఖ్యమైన సమాచారాన్ని లాగిన్ చేయడం కూడా మంచిది. ఉదాహరణకు, నిర్వాహక వినియోగదారుని సృష్టించడం. ఇది ఖచ్చితంగా లాగ్ చేయడం మంచిది.
జావాలో లాగిన్ చేయడానికి సాధనాలు
జావాలో బాగా తెలిసిన లాగింగ్ సొల్యూషన్స్లో, మేము ఈ క్రింది వాటిని హైలైట్ చేయవచ్చు:
- లాగ్4j
- JUL — java.util.logging
- JCL — జకార్తా కామన్స్ లాగింగ్
- లాగ్బ్యాక్
- SLF4J — జావా కోసం సాధారణ లాగింగ్ ముఖభాగం
మేము వాటిలో ప్రతిదాని యొక్క అవలోకనాన్ని అందిస్తాము. అప్పుడు మేము ఆచరణాత్మక చర్చకు ఆధారంగా slf4j - log4j బైండింగ్ని తీసుకుంటాము . ఇది ఇప్పుడు వింతగా అనిపించవచ్చు, కానీ చింతించకండి: వ్యాసం ముగిసే సమయానికి, ప్రతిదీ స్పష్టంగా ఉంటుంది. |
System.err.println
ప్రారంభంలో,
System.err.println (కన్సోల్లో లాగ్ ఎంట్రీలను ప్రదర్శిస్తోంది) ఉంది. నేటికీ, డీబగ్గింగ్ చేసేటప్పుడు త్వరగా లాగ్ చేయడానికి ఈ సాంకేతికత ఉపయోగించబడుతుంది. వాస్తవానికి, ఇక్కడ చర్చించడానికి సెట్టింగ్లు ఏవీ లేవు, కాబట్టి ఈ పద్ధతిని గుర్తుంచుకోండి మరియు మేము ముందుకు వెళ్తాము.
లాగ్4j
ఇది డెవలపర్లు అవసరం లేకుండా సృష్టించిన పూర్తి పరిష్కారం. ఫలితం మీరు ఉపయోగించగల నిజంగా ఆసక్తికరమైన సాధనం. వివిధ పరిస్థితుల కారణంగా, ఈ పరిష్కారం JDKలో ముగియలేదు, ఇది మొత్తం సమాజాన్ని కలవరపెట్టింది. Log4j కాన్ఫిగరేషన్ ఎంపికలను కలిగి ఉంది, ఇది మీరు ప్యాకేజీలో లాగింగ్ని ప్రారంభించి
com.example.type
, ఉపప్యాకేజీలో దాన్ని ఆఫ్ చేయండి
com.example.type.generic
. ఇది లాగిన్ చేయవలసిన అవసరం లేని కోడ్ను త్వరగా మినహాయించడాన్ని సాధ్యం చేస్తుంది. Log4j యొక్క రెండు వెర్షన్లు ఉన్నాయని ఇక్కడ గమనించడం ముఖ్యం
: 1.2.x మరియు 2.xx, మరియు అవి ఒకదానికొకటి అనుకూలంగా లేవు .
Log4j అనుబంధం యొక్క భావనలను జోడించింది
(లాగ్లను వ్రాయడానికి ఉపయోగించే సాధనం) మరియు లేఅవుట్ (లాగ్ ఫార్మాటింగ్). ఇది మీకు అవసరమైన వాటిని మాత్రమే లాగిన్ చేయడానికి మరియు మీకు అవసరమైన విధంగా లాగిన్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. మేము అనుబంధం గురించి కొంచెం తరువాత మాట్లాడుతాము.
JUL — java.util.logging
ఈ పరిష్కారం యొక్క ముఖ్య ప్రయోజనాల్లో ఒకటి JUL JDK (జావా డెవలప్మెంట్ కిట్)లో చేర్చబడింది. దురదృష్టవశాత్తు, ఇది అభివృద్ధి చేయబడినప్పుడు, దాని సృష్టికర్తలు దీనిని ప్రముఖ Log4j యుటిలిటీపై ఆధారపడలేదు, కానీ IBM నుండి ఒక పరిష్కారం. ఆ నిర్ణయం వల్ల పరిణామాలు చోటు చేసుకున్నాయి. వాస్తవం ఏమిటంటే ఇప్పుడు ఎవరూ JULని ఉపయోగించరు. JULలోని లాగ్ స్థాయిలు Logback, Log4j మరియు Slf4j కలిగి ఉన్న వాటికి భిన్నంగా ఉంటాయి. ఇది ఒకరినొకరు అర్థం చేసుకోవడం కష్టతరం చేస్తుంది. లాగర్ని సృష్టించడం అనేది ఎక్కువ లేదా తక్కువ సారూప్యంగా ఉంటుంది. దీన్ని చేయడానికి, మీరు దిగుమతి చేయాలి:
java.util.logging.Logger log = java.util.logging.Logger.getLogger(LoggingJul.class.getName());
తరగతి పేరు ఆమోదించబడింది, కాబట్టి మా లాగింగ్ ఎక్కడ నుండి వస్తుందో మాకు తెలుసు. జావా 8తో ప్రారంభించి, మీరు పాస్ చేయవచ్చు
Supplier<String>
. ఇది గతంలో మాదిరిగానే ప్రతిసారీ కాకుండా, మనకు నిజంగా అవసరమైనప్పుడు మాత్రమే లైన్ను చదవడానికి మరియు సృష్టించడానికి మాకు సహాయపడుతుంది. జావా 8 విడుదలతో మాత్రమే డెవలపర్లు చివరకు ముఖ్యమైన సమస్యలను పరిష్కరించారు మరియు JULని నిజంగా ఉపయోగించగలిగేలా చేసారు.
Supplier<String> msgSupplier
అవి, క్రింద చూపిన విధంగా పరామితితో పద్ధతులు :
public void info(Supplier<String> msgSupplier) {
log(Level.INFO, msgSupplier);
}
JCL — జకార్తా కామన్స్ లాగింగ్
చాలా కాలంగా లాగింగ్కు సంబంధించి పరిశ్రమ ప్రమాణాలు లేనందున మరియు చాలా మంది వ్యక్తులు తమ స్వంత కస్టమ్ లాగర్లను సృష్టించినందున, ఇతరులపై ఉపయోగించగల సాధారణ రేపర్ అయిన JCLని విడుదల చేయడానికి నిర్ణయం తీసుకోబడింది. ఎందుకు? కొన్నిసార్లు ప్రాజెక్ట్కు జోడించబడిన డిపెండెన్సీలు ప్రాజెక్ట్లో ఉన్నదాని కంటే భిన్నమైన లాగర్ను ఉపయోగిస్తాయి. దీని కారణంగా, అవి ట్రాన్సిటివ్ డిపెండెన్సీలుగా ప్రాజెక్ట్కి జోడించబడ్డాయి మరియు అన్నింటినీ కలిపి ఉంచడానికి ప్రయత్నిస్తున్నప్పుడు ఇది నిజమైన సమస్యలను సృష్టించింది. దురదృష్టవశాత్తు, రేపర్ చాలా ఫంక్షనల్ కాదు మరియు దేనినీ జోడించలేదు. ప్రతి ఒక్కరూ JCLని ఉపయోగిస్తే చాలా సౌకర్యవంతంగా ఉంటుంది. కానీ అది జరిగింది కాదు, కాబట్టి JCLని ఉపయోగించడం ప్రస్తుతానికి ఉత్తమమైన ఆలోచన కాదు.
లాగ్బ్యాక్
ఓపెన్ సోర్స్ మార్గం ముళ్లతో కూడుకున్నది... Log4jని వ్రాసిన అదే డెవలపర్ లాగ్బ్యాక్ను సక్సెసర్ లాగింగ్ ఫ్రేమ్వర్క్గా కూడా వ్రాసాడు. ఇది Log4j వలె అదే ఆలోచనపై ఆధారపడింది. లాగ్బ్యాక్లో తేడాలు:
- మెరుగైన పనితీరు
- Slf4j కోసం స్థానిక మద్దతు జోడించబడింది
- విస్తరించిన వడపోత ఎంపికలు
డిఫాల్ట్గా, లాగ్బ్యాక్కి ఎలాంటి కాన్ఫిగరేషన్ అవసరం లేదు మరియు డీబగ్ స్థాయి మరియు అంతకంటే ఎక్కువ స్థాయిలో అన్ని ఈవెంట్లను రికార్డ్ చేస్తుంది. మీకు కొంత అనుకూలీకరణ అవసరమైతే, మీరు దానిని 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 — జావా కోసం సాధారణ లాగింగ్ ముఖభాగం
కొంతకాలం 2006లో, Log4j వ్యవస్థాపక పితామహుల్లో ఒకరు ప్రాజెక్ట్ నుండి వైదొలిగారు మరియు Slf4j (జావా కోసం సింపుల్ లాగింగ్ ముఖభాగం), Log4j, JUL, కామన్-లాగింగ్ మరియు లాగ్బ్యాక్ కోసం ఒక రేపర్ని సృష్టించారు. మీరు చూడగలిగినట్లుగా, మేము రేపర్పై రేపర్ను సృష్టించే స్థాయికి చేరుకున్నాము... ఈ సందర్భంలో, ఇది రెండు భాగాలుగా విభజించబడింది: అప్లికేషన్లో ఉపయోగించే ఒక API మరియు విడిగా జోడించబడిన అమలు ప్రతి రకం లాగింగ్ కోసం డిపెండెన్సీలు. ఉదాహరణకు,
slf4j-log4j12.jar
మరియు
slf4j-jdk14.jar
. మీరు సరైన అమలును హుక్ అప్ చేయాలి మరియు అంతే: మీ మొత్తం ప్రాజెక్ట్ దీన్ని ఉపయోగిస్తుంది. లాగింగ్ కోసం స్ట్రింగ్లను ఫార్మాట్ చేయడం వంటి అన్ని తాజా ఫీచర్లకు Slf4j మద్దతు ఇస్తుంది. గతంలో ఇలాంటి సమస్య ఉండేది. మనం ఇలా లాగ్ ఎంట్రీని క్రియేట్ చేశామని చెప్పండి:
log.debug("User " + user + " connected from " + request.getRemoteAddr());
సంగ్రహణ ఆపరేటర్ కారణంగా,
user
ఆబ్జెక్ట్ నిశ్శబ్దంగా స్ట్రింగ్గా మారుతుంది
user.toString()
. ఇది సమయం పడుతుంది మరియు సిస్టమ్ నెమ్మదిస్తుంది. మేము అప్లికేషన్ను డీబగ్ చేస్తున్నట్లయితే అది సరే కావచ్చు. ఈ తరగతికి సంబంధించిన లాగ్ స్థాయి INFO లేదా అంతకంటే ఎక్కువ ఉంటే మేము సమస్యలను ఎదుర్కొంటాము. మరో మాటలో చెప్పాలంటే, మేము ఈ లాగ్ ఎంట్రీని (INFO లేదా అంతకంటే ఎక్కువ) వ్రాయకూడదు మరియు మేము స్ట్రింగ్ సంయోగాన్ని ఉపయోగించకూడదు. సిద్ధాంతపరంగా, లాగింగ్ లైబ్రరీ స్వయంగా దీనిని పరిష్కరించాలి. ఇది జరిగినప్పుడు, ఇది Log4j యొక్క మొదటి సంస్కరణలో అతిపెద్ద సమస్యగా మారింది. ఇది సరైన పరిష్కారాన్ని అందించలేదు, బదులుగా ఇలాంటివి చేయాలని సూచించింది:
if (log.isDebugEnabled()) {
log.debug("User " + user + " connected from " + request.getRemoteAddr());
}
అంటే, లాగింగ్ కోసం ఒక లైన్ కోడ్కు బదులుగా, వారు 3 అని వ్రాయమని సూచించారు! లాగింగ్ కోడ్ మార్పులను తగ్గించాలి మరియు మూడు లైన్లు ఆ సాధారణ విధానాన్ని స్పష్టంగా ఉల్లంఘిస్తాయి. Slf4jకి JDK మరియు APIతో అనుకూలత సమస్యలు లేవు, కాబట్టి వెంటనే ఒక చక్కని పరిష్కారం ఉద్భవించింది:
log.debug("User {} connected from {}", user, request.getRemoteAddr());
ఇక్కడ
{}
పద్ధతికి పంపబడిన వాదనల కోసం ప్లేస్హోల్డర్లను సూచిస్తుంది. అంటే, మొదటిది కు
{}
అనుగుణంగా ఉంటుంది
user
మరియు రెండవది . ఈ విధంగా చేయడం ద్వారా, లాగ్ స్థాయికి మనం లాగ్ ఎంట్రీని వ్రాయవలసి వచ్చినప్పుడు మాత్రమే మేము స్ట్రింగ్ సంయోగాన్ని నిర్వహిస్తాము. ఆ తరువాత, Sjf4j వేగంగా జనాదరణ పొందడం ప్రారంభించింది. ప్రస్తుతం, ఇది ఉత్తమ పరిష్కారం. దీని ప్రకారం, బైండింగ్ని ఉపయోగించి లాగింగ్ని పరిశీలిద్దాం .
{}
request.getRemoteAddr()
slf4j-log4j12
లాగ్ చేయాలి
వాస్తవానికి, మీరు ప్రతిదీ లాగ్ చేయకూడదు. ఇది తరచుగా అవసరం లేదు మరియు కొన్నిసార్లు ప్రమాదకరమైనది కూడా. ఉదాహరణకు, మీరు ఒకరి వ్యక్తిగత డేటాను లాగిన్ చేసి, అది ఏదో ఒకవిధంగా లీక్ అయినట్లయితే, ప్రత్యేకించి పాశ్చాత్య మార్కెట్లపై దృష్టి సారించిన ప్రాజెక్ట్లలో నిజమైన సమస్యలు ఉంటాయి.
కానీ మీరు ఖచ్చితంగా లాగిన్ చేయవలసిన అంశాలు కూడా ఉన్నాయి :
- అప్లికేషన్ ప్రారంభం/ముగింపు. అప్లికేషన్ నిజంగా ప్రారంభమై, అనుకున్నట్లుగానే ముగిసిందో లేదో తెలుసుకోవాలి.
- భద్రతా సమస్యలు. ఇక్కడ ఒకరి పాస్వర్డ్ను ఊహించడం, నిర్వాహకులు సైన్ ఇన్ చేసిన సందర్భాలు మొదలైనవాటిని లాగ్ చేయడం మంచిది.
- నిర్దిష్ట అప్లికేషన్ స్టేట్స్ . ఉదాహరణకు, వ్యాపార ప్రక్రియలో ఒక రాష్ట్రం నుండి మరొక రాష్ట్రానికి మారడం.
- సంబంధిత లాగ్ స్థాయితో పాటు నిర్దిష్ట డీబగ్ సమాచారం .
- నిర్దిష్ట SQL స్క్రిప్ట్లు. ఇది అవసరమైనప్పుడు వాస్తవ ప్రపంచ కేసులు ఉన్నాయి. కానీ మళ్ళీ, లాగ్ స్థాయిలను నైపుణ్యంగా సర్దుబాటు చేయడం ద్వారా, మీరు అద్భుతమైన ఫలితాలను సాధించవచ్చు.
- విషయాలు సరిగ్గా పని చేస్తున్నాయని ధృవీకరించినప్పుడు రన్నింగ్ థ్రెడ్లు లాగ్ చేయబడతాయి.
లాగింగ్లో జనాదరణ పొందిన లోపాలు
ఇక్కడ చాలా సూక్ష్మ నైపుణ్యాలు ఉన్నాయి, కానీ మేము కొన్ని సాధారణ తప్పుల గురించి ప్రత్యేకంగా ప్రస్తావిస్తాము:
- విపరీతమైన లాగింగ్. మీరు సిద్ధాంతపరంగా ముఖ్యమైన ప్రతి అడుగును లాగిన్ చేయకూడదు. ఇక్కడ ఒక మంచి నియమం: లాగ్లు లోడ్లో 10% మించకూడదు. లేకపోతే, పనితీరు సమస్యలు ఉంటాయి.
- మొత్తం డేటాను ఒకే ఫైల్లోకి లాగిన్ చేస్తోంది. ఏదో ఒక సమయంలో, ఇది లాగ్ను చదవడం/వ్రాయడం చాలా కష్టతరం చేస్తుంది, కొన్ని సిస్టమ్లు ఫైల్ పరిమాణంపై పరిమితులను కలిగి ఉన్నాయనే వాస్తవం చెప్పనవసరం లేదు.
- తప్పు లాగ్ స్థాయిలను ఉపయోగించడం. ప్రతి లాగ్ స్థాయికి స్పష్టమైన సరిహద్దులు ఉన్నాయి మరియు వాటిని గౌరవించాలి. సరిహద్దు అస్పష్టంగా ఉంటే, ఏ స్థాయిని ఉపయోగించాలనే దానిపై మీరు ఒక ఒప్పందానికి రావచ్చు.
లాగ్ స్థాయిలు
|
|
|
x: కనిపిస్తుంది |
|
|
|
|
ప్రాణాంతకం |
లోపం |
హెచ్చరించు |
సమాచారం |
డీబగ్ |
జాడ కనుగొను |
అన్ని |
ఆఫ్ |
|
|
|
|
|
|
|
ప్రాణాంతకం |
x |
|
|
|
|
|
|
లోపం |
x |
x |
|
|
|
|
|
హెచ్చరించు |
x |
x |
x |
|
|
|
|
సమాచారం |
x |
x |
x |
x |
|
|
|
డీబగ్ |
x |
x |
x |
x |
x |
|
|
జాడ కనుగొను |
x |
x |
x |
x |
x |
x |
|
అన్ని |
x |
x |
x |
x |
x |
x |
x |
లాగ్ స్థాయిలు ఏమిటి? లాగ్ ఎంట్రీల యొక్క సోపానక్రమాన్ని ఎలాగైనా సృష్టించడానికి, కొన్ని సంప్రదాయాలు మరియు డీలిమిటేషన్లు అవసరం. అందుకే లాగ్ స్థాయిలు ప్రవేశపెట్టబడ్డాయి. అప్లికేషన్లో స్థాయి సెట్ చేయబడింది. ఒక ఎంట్రీ పేర్కొన్న స్థాయి కంటే తక్కువగా ఉంటే, అది లాగ్ చేయబడలేదు. ఉదాహరణకు, అప్లికేషన్ను డీబగ్ చేసేటప్పుడు ఉపయోగించే లాగ్లు మా వద్ద ఉన్నాయి. సాధారణ ఆపరేషన్ సమయంలో (అప్లికేషన్ దాని ఉద్దేశించిన ప్రయోజనం కోసం ఉపయోగించినప్పుడు), అటువంటి లాగ్లు అవసరం లేదు. అందువల్ల, డీబగ్గింగ్ కంటే లాగ్ స్థాయి ఎక్కువగా ఉంటుంది. Log4jని ఉపయోగించి లాగ్ స్థాయిలను చూద్దాం. JUL కాకుండా, ఇతర పరిష్కారాలు అదే లాగ్ స్థాయిలను ఉపయోగిస్తాయి. ఇక్కడ అవి తగ్గుతున్న క్రమంలో ఉన్నాయి:
- ఆఫ్: లాగ్ ఎంట్రీలు రికార్డ్ చేయబడలేదు; ప్రతిదీ విస్మరించబడింది.
- ప్రాణాంతకం: అప్లికేషన్ అమలులో కొనసాగకుండా నిరోధించే లోపం. ఉదాహరణకు, "JVM మెమరీ లోపం నుండి బయటపడింది".
- లోపం: ఈ స్థాయిలో లోపాలు పరిష్కరించాల్సిన సమస్యలను సూచిస్తాయి. లోపం మొత్తం అప్లికేషన్ను ఆపదు. ఇతర అభ్యర్థనలు సరిగ్గా పని చేయవచ్చు.
- హెచ్చరిక: హెచ్చరికను సూచించే లాగ్ ఎంట్రీలు. ఊహించనిది ఏదో జరిగింది, కానీ సిస్టమ్ తట్టుకోగలిగింది మరియు అభ్యర్థనను నెరవేర్చింది
- సమాచారం: అప్లికేషన్లోని ముఖ్యమైన చర్యలను సూచించే లాగ్ ఎంట్రీలు. ఇవి లోపాలు లేదా హెచ్చరికలు కాదు. అవి ఊహించిన సిస్టమ్ ఈవెంట్లు.
- డీబగ్: లాగ్ల ఎంట్రీలు అప్లికేషన్ను డీబగ్ చేయాలి. అప్లికేషన్ ఆశించిన దానినే సరిగ్గా చేస్తుందని నిర్ధారించుకోవడం కోసం లేదా అప్లికేషన్ ద్వారా తీసుకున్న చర్యలను వివరించడం కోసం, అంటే "ఎంటర్డ్ మెథడ్1".
- ట్రేస్: డీబగ్గింగ్ కోసం తక్కువ-ప్రాధాన్యత లాగ్ ఎంట్రీలు. అత్యల్ప లాగ్ స్థాయి.
- అన్నీ: అప్లికేషన్ యొక్క అన్ని లాగ్ ఎంట్రీలను వ్రాయడానికి లాగ్ స్థాయి.
INFO లాగ్ స్థాయి అప్లికేషన్లో ఎక్కడో ఎనేబుల్ చేయబడింది, ఆపై ప్రతి స్థాయికి సంబంధించిన ఎంట్రీలు INFO నుండి FATAL వరకు లాగ్ చేయబడతాయి. FATAL లాగ్ స్థాయిని సెట్ చేస్తే, ఆ స్థాయి ఉన్న లాగ్ ఎంట్రీలు మాత్రమే వ్రాయబడతాయి.
లాగ్లను లాగింగ్ మరియు పంపడం: అనుబంధం
లాగ్లను వ్రాయడానికి/పంపడానికి పుష్కలమైన అవకాశాలను అందించే Log4jని ఉపయోగించినప్పుడు ఇవన్నీ ఎలా పనిచేస్తాయో చూద్దాం:
- ఫైల్కి వ్రాయడానికి -
DailyRollingFileAppender
- కన్సోల్కు సమాచారాన్ని వ్రాయడానికి -
ConsoleAppender
- ఒక డేటాబేస్కు లాగ్లను వ్రాయడానికి -
JDBCAppender
- TCP/IP ద్వారా లాగ్లను పంపడాన్ని నిర్వహించడానికి —
TelnetAppender
- లాగింగ్ పనితీరును ప్రతికూలంగా ప్రభావితం చేయదని నిర్ధారించుకోవడం కోసం -
AsyncAppender
మరికొన్ని అమలులు ఉన్నాయి: పూర్తి జాబితా
ఇక్కడ అందుబాటులో ఉంది . మార్గం ద్వారా, మీకు అవసరమైన అనుబంధం లేనట్లయితే, అది సమస్య కాదు. Log4j మద్దతిచ్చే
Appender ఇంటర్ఫేస్ని అమలు చేయడం ద్వారా మీరు మీ స్వంత appenderని వ్రాయవచ్చు .
లాగింగ్ నోడ్స్
ప్రదర్శన ప్రయోజనాల కోసం, మేము Log4j నుండి అమలుతో Slf4j ఇంటర్ఫేస్ని ఉపయోగిస్తాము. లాగర్ని సృష్టించడం చాలా సులభం: పేరు గల క్లాస్లో
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 the log4j.properties file. Please fix this.");
logger.error("Connection refused to host = {}", host);
మేము తరగతిలో ఉత్తీర్ణులవుతున్నప్పటికీ, చివరి పేరు ప్యాకేజీలతో సహా తరగతి పూర్తి పేరు. ఇది తరువాత మీరు లాగింగ్ను నోడ్లుగా విభజించి, ప్రతి నోడ్కు లాగింగ్ స్థాయి మరియు అనుబంధాన్ని కాన్ఫిగర్ చేయవచ్చు. ఉదాహరణకు, లాగర్ తరగతిలో సృష్టించబడింది
com.github.romankh3.logginglecture.MainDemo
. లాగింగ్ నోడ్ల సోపానక్రమాన్ని సృష్టించడానికి పేరు ఆధారాన్ని అందిస్తుంది. ప్రధాన నోడ్ టాప్-లెవల్
రూట్లాగర్ . ఇది మొత్తం అప్లికేషన్ కోసం అన్ని లాగ్ ఎంట్రీలను స్వీకరించే నోడ్. దిగువ చూపిన విధంగా మిగిలిన నోడ్లను చిత్రీకరించవచ్చు:
నిర్దిష్ట లాగింగ్ నోడ్ల కోసం అనుబంధాలు కాన్ఫిగర్ చేయబడ్డాయి.
ఇప్పుడు మనం 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=డీబగ్, కన్సోల్, ఫైల్
- log4j.rootLogger అంటే మనం రూట్ నోడ్ని కాన్ఫిగర్ చేస్తున్నాము, ఇందులో అన్ని లాగ్ ఎంట్రీలు ఉంటాయి
- సమాన గుర్తు తర్వాత మొదటి పదం వ్రాయవలసిన కనీస లాగ్ స్థాయిని సూచిస్తుంది (మా విషయంలో, ఇది డీబగ్)
- కామాను అనుసరించి, ఉపయోగించాల్సిన అన్ని అనుబంధాలను మేము సూచిస్తాము.
మరింత నిర్దిష్ట లాగింగ్ నోడ్ను కాన్ఫిగర్ చేయడానికి, మీరు ఇలాంటి ఎంట్రీని ఉపయోగిస్తారు:
log4j.logger.com.github.romankh3.logginglecture=TRACE, OWN, CONSOLE
నిర్దిష్ట నోడ్ను సూచించడానికి ఎక్కడ
log4j.logger.
ఉపయోగించబడుతుంది. మన విషయంలో,
com.github.romankh3.logginglecture.
ఇప్పుడు కన్సోల్ అనుబంధాన్ని కాన్ఫిగర్ చేయడం గురించి మాట్లాడుదాం:
# CONSOLE appender customization
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
అనుబంధం పని చేయడం ప్రారంభించే నిర్దిష్ట స్థాయిని సెట్ చేయడం సాధ్యమవుతుందని ఇక్కడ మనం చూస్తాము. వాస్తవానికి ఏమి జరుగుతుందో ఇక్కడ ఒక ఉదాహరణ ఉంది: INFO స్థాయితో సందేశం లాగింగ్ నోడ్ ద్వారా స్వీకరించబడింది మరియు దానికి కేటాయించిన అనుబంధానికి పంపబడింది. అనుబంధం యొక్క థ్రెషోల్డ్ WARNకి సెట్ చేయబడితే, అది లాగ్ ఎంట్రీని అందుకుంటుంది కానీ దానితో ఏమీ చేయదు. తర్వాత, సందేశం ఏ లేఅవుట్ని ఉపయోగిస్తుందో మనం నిర్ణయించుకోవాలి. నేను ఉదాహరణలో PatternLayoutని ఉపయోగిస్తాను, కానీ అనేక ఇతర ఎంపికలు ఉన్నాయి. మేము వాటిని ఈ వ్యాసంలో కవర్ చేయము. FILE అనుబంధాన్ని కాన్ఫిగర్ చేయడానికి ఉదాహరణ:
# File appender customization
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
. ఫైల్ పరిమాణంతో సమస్యలను నివారించడానికి, మీరు గరిష్టంగా కాన్ఫిగర్ చేయవచ్చు, ఈ సందర్భంలో 1MB.
MaxBackupIndex
అటువంటి లాగ్ ఫైల్స్ ఎన్ని ఉంటాయో సూచిస్తుంది. మనం ఇంతకంటే ఎక్కువ ఫైళ్లను క్రియేట్ చేయవలసి వస్తే, మొదటి ఫైల్ తొలగించబడుతుంది. లాగింగ్ కాన్ఫిగర్ చేయబడిన నిజమైన ఉదాహరణను చూడటానికి, మీరు GitHubలోని
పబ్లిక్ రిపోజిటరీకి వెళ్లవచ్చు .
మేము చర్చించిన వాటిని బలోపేతం చేయండి
మేము వివరించిన ప్రతిదాన్ని చేయడానికి మీ స్వంతంగా ప్రయత్నించండి:
- పైన ఉన్న మా ఉదాహరణ మాదిరిగానే మీ స్వంత ప్రాజెక్ట్ను సృష్టించండి.
- మావెన్ ఎలా ఉపయోగించాలో మీకు తెలిస్తే, దాన్ని ఉపయోగించండి. కాకపోతే, లైబ్రరీని ఎలా కనెక్ట్ చేయాలో వివరించే ఈ ట్యుటోరియల్ని చదవండి.
క్లుప్తంగా
- మేము జావాలో ఉన్న లాగింగ్ పరిష్కారాల గురించి మాట్లాడాము.
- దాదాపు అన్ని ప్రసిద్ధ లాగింగ్ లైబ్రరీలు ఒక వ్యక్తి వ్రాసినవి :D
- ఏది లాగిన్ చేయాలి మరియు ఏది చేయకూడదో మేము నేర్చుకున్నాము.
- మేము లాగ్ స్థాయిలను గుర్తించాము.
- మేము లాగింగ్ నోడ్లను పరిచయం చేసాము.
- అనుబంధం అంటే ఏమిటి మరియు అది దేని కోసం అని మేము చూశాము.
- మేము దశలవారీగా log4j.proterties ఫైల్ని సృష్టించాము.
అదనపు పదార్థాలు
- కోడ్జిమ్: లాగర్ పాఠం
- వీక్లీ గీక్లీ: జావా లాగింగ్. హలో వరల్డ్
- కోడింగ్ హర్రర్: లాగింగ్తో సమస్య
- YouTube: జావా లాగింగ్ హెల్ను అర్థం చేసుకోవడం - ప్రాథమిక అంశాలు. జావా లాగింగ్ హెల్ & దాని నుండి ఎలా బయటపడాలి
- Log4j: అనుబంధం
- Log4j: లేఅవుట్
నా ఇతర కథనాన్ని కూడా చూడండి: