لاگنگ: کیا، کیسے، کہاں، اور کس کے ساتھ؟

CodeGym کمیونٹی میں سب کو ہیلو! آج لاگنگ کے بارے میں بات کرتے ہیں:

1. یہ کیا ہے، یہ کیوں موجود ہے، آپ کو اسے کب استعمال کرنا چاہیے، کب آپ کو اس سے بچنا چاہیے۔
2. جاوا میں لاگنگ کے کون سے نفاذ دستیاب ہیں، اور آپ کو لاگنگ کے ان تمام اختیارات کے ساتھ کیا کرنا چاہیے۔
اور لاگ لیولز۔ ہم بات کریں گے کہ ضمیمہ کیا ہے اور اسے صحیح طریقے سے ترتیب دینے کا طریقہ۔
3. لاگنگ نوڈس اور انہیں صحیح طریقے سے کنفیگر کرنے کا طریقہ تاکہ ہر چیز ہماری مرضی کے مطابق کام کرے۔

یہ مواد وسیع سامعین کے لیے ہے۔ یہ کسی کے لیے بھی واضح ہو جائے گا کہ صرف جاوا کو جاننا ہے، اور ساتھ ہی وہ لوگ جو پہلے سے کام کر رہے ہیں لیکن صرف دریافت کر چکے ہیں logger.info("log something"); چلو!

آپ کو لاگنگ کی ضرورت کیوں ہے؟

آئیے کچھ حقیقی معاملات کو دیکھتے ہیں جہاں لاگنگ ایک مسئلہ حل کر سکتی ہے۔ یہاں میرے کام سے ایک مثال ہے۔ ایسے نکات ہیں جہاں ایک درخواست دوسری خدمات کے ساتھ مربوط ہوتی ہے۔ میں ایک قسم کی "alibi" قائم کرنے کے لیے ان پوائنٹس پر لاگنگ کا استعمال کرتا ہوں: اگر انضمام کام نہیں کر رہا ہے، تو یہ معلوم کرنا آسان ہو جاتا ہے کہ کس طرف مسئلہ ہے۔ ڈیٹا بیس میں محفوظ اہم معلومات کو لاگ کرنا بھی ضروری ہے۔ مثال کے طور پر، ایک منتظم صارف کی تخلیق. یہ بالکل ایسی چیز ہے جو لاگ ان کرنا اچھا ہوگا۔

جاوا میں لاگ ان کرنے کے اوزار

جاوا میں لاگنگ کے معروف حلوں میں سے، ہم درج ذیل کو نمایاں کر سکتے ہیں:

• Log4j
• JUL — java.util.logging
• JCL - جکارتہ کامنز لاگنگ
• لاگ بیک
• SLF4J - جاوا کے لیے سادہ لاگنگ اگواڑا

System.err.println

شروع میں، System.err.println (کنسول پر لاگ اندراجات ڈسپلے کرنا) تھا۔ آج بھی، اس تکنیک کو ڈیبگ کرتے وقت تیزی سے لاگ کرنے کے لیے استعمال کیا جاتا ہے۔ یقیناً، یہاں بات کرنے کے لیے کوئی سیٹنگز نہیں ہیں، اس لیے بس یہ طریقہ یاد رکھیں اور ہم آگے بڑھیں گے۔

Log4j

یہ ایک مکمل حل ہے جسے ڈویلپرز نے ضرورت سے تیار کیا ہے۔ نتیجہ واقعی ایک دلچسپ ٹول ہے جسے آپ استعمال کرسکتے ہیں۔ مختلف حالات کی وجہ سے، یہ حل 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 میں لاگ کی سطح لاگ بیک، 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 - جکارتہ کامنز لاگنگ

چونکہ ایک طویل عرصے سے لاگنگ کے حوالے سے کوئی صنعتی معیار نہیں تھا اور بہت سے لوگوں نے اپنی مرضی کے مطابق لاگرز بنائے تھے، اس لیے JCL کو جاری کرنے کا فیصلہ کیا گیا، ایک عام ریپر جو دوسروں کے اوپر استعمال کیا جا سکتا تھا۔ کیوں؟ بعض اوقات پراجیکٹ میں شامل ہونے والے انحصار میں پروجیکٹ میں سے ایک مختلف لاگر استعمال ہوتا ہے۔ اس کی وجہ سے، انہیں پراجیکٹ میں عبوری انحصار کے طور پر شامل کیا گیا، اور یہ سب کچھ ایک ساتھ رکھنے کی کوشش کرتے وقت حقیقی مسائل پیدا ہوئے۔ بدقسمتی سے، ریپر زیادہ فعال نہیں تھا اور اس میں کچھ بھی شامل نہیں تھا۔ یہ شاید آسان ہو گا اگر ہر کوئی JCL استعمال کرے۔ لیکن ایسا نہیں ہوا، اس لیے JCL کا استعمال اس وقت بہترین خیال نہیں ہے۔

لاگ بیک

اوپن سورس کا راستہ کانٹے دار ہے... وہی ڈویلپر جس نے Log4j لکھا تھا اس نے Logback کو ایک جانشین لاگنگ فریم ورک کے طور پر بھی لکھا تھا۔ یہ اسی خیال پر مبنی تھا جیسے 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 - جاوا کے لیے سادہ لاگنگ اگواڑا

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، اور دوسرا {}اس کے مساوی ہے request.getRemoteAddr()۔ اسے اس طرح کرنے سے، ہم سٹرنگ کنکٹنیشن صرف اس صورت میں انجام دیں گے جب لاگ لیول ہم سے لاگ انٹری لکھنے کا تقاضا کرے۔ اس کے بعد، Sjf4j تیزی سے مقبولیت میں بڑھنے لگا۔ فی الحال، یہ بہترین حل ہے. اس کے مطابق، آئیے بائنڈنگ کا استعمال کرتے ہوئے لاگنگ پر ایک نظر ڈالتے ہیں slf4j-log4j12۔

کیا لاگ ان کرنے کی ضرورت ہے

یقینا، آپ کو ہر چیز کو لاگ ان نہیں کرنا چاہئے۔ یہ اکثر ضروری نہیں ہوتا اور بعض اوقات خطرناک بھی ہوتا ہے۔ مثال کے طور پر، اگر آپ کسی کے ذاتی ڈیٹا کو لاگ کرتے ہیں اور یہ کسی طرح سے لیک ہو جاتا ہے، تو وہاں حقیقی مسائل ہوں گے، خاص طور پر مغربی مارکیٹوں پر مرکوز منصوبوں میں۔ لیکن ایسی چیزیں بھی ہیں جو آپ کو یقینی طور پر لاگ ان کرنا چاہئے :

1. درخواست کا آغاز/اختتام۔ ہمیں یہ جاننے کی ضرورت ہے کہ آیا درخواست واقعی توقع کے مطابق شروع ہوئی اور ختم ہوئی۔
2. سیکورٹی کے مسائل. یہاں کسی کے پاس ورڈ کا اندازہ لگانے کی کوششوں کو لاگ ان کرنا اچھا ہو گا، ایسے واقعات جب ایڈمنز سائن ان ہوں وغیرہ۔
3. درخواست کی کچھ شرائط ۔ مثال کے طور پر، کاروباری عمل میں ایک ریاست سے دوسری ریاست میں منتقلی۔
4. متعلقہ لاگ لیول کے ساتھ کچھ ڈیبگ معلومات ۔
5. کچھ ایس کیو ایل اسکرپٹس۔ حقیقی دنیا کے معاملات ایسے ہوتے ہیں جب یہ ضروری ہوتا ہے۔ لیکن ایک بار پھر، لاگ لیولز کو مہارت سے ایڈجسٹ کرکے، آپ بہترین نتائج حاصل کر سکتے ہیں۔
6. رننگ تھریڈز کو لاگ ان کیا جا سکتا ہے جب اس بات کی تصدیق ہو کہ چیزیں صحیح طریقے سے کام کر رہی ہیں۔

لاگنگ میں مشہور غلطیاں

یہاں بہت سی باریکیاں ہیں، لیکن ہم چند عام غلطیوں کا خاص ذکر کریں گے:

1. ضرورت سے زیادہ لاگنگ۔ آپ کو ہر اس قدم کو لاگ نہیں کرنا چاہئے جو نظریاتی طور پر اہم ہو سکتا ہے۔ یہاں انگوٹھے کا ایک اچھا اصول ہے: لاگز کو بوجھ کے 10٪ سے زیادہ نہیں ہونا چاہئے۔ دوسری صورت میں، کارکردگی کے مسائل ہوں گے.
2. تمام ڈیٹا کو ایک فائل میں لاگ کرنا۔ کسی وقت، اس سے لاگ کو پڑھنا/لکھنا بہت مشکل ہو جائے گا، اس حقیقت کا ذکر نہ کرنا کہ بعض سسٹمز میں فائل کے سائز کی حد ہوتی ہے۔
3. غلط لاگ لیولز کا استعمال۔ ہر لاگ سطح کی واضح حدود ہوتی ہیں، اور ان کا احترام کیا جانا چاہیے۔ اگر کوئی حد واضح نہیں ہے، تو آپ اس بات پر اتفاق کر سکتے ہیں کہ کس سطح کو استعمال کرنا ہے۔

لاگ لیولز

لاگ لیولز کیا ہیں؟ کسی نہ کسی طرح لاگ اندراجات کا درجہ بندی بنانے کے لیے، کچھ کنونشنز اور حد بندی ضروری ہے۔ یہی وجہ ہے کہ لاگ لیولز متعارف کرائے گئے تھے۔ درخواست میں سطح مقرر کی گئی ہے۔ اگر کوئی اندراج ایک مخصوص سطح سے نیچے ہے، تو اسے لاگ نہیں کیا جاتا ہے۔ مثال کے طور پر، ہمارے پاس لاگز ہیں جو ہم ایپلیکیشن کو ڈیبگ کرتے وقت استعمال کرتے ہیں۔ عام آپریشن کے دوران (جب ایپلیکیشن اپنے مطلوبہ مقصد کے لیے استعمال کی جاتی ہے)، ایسے لاگز کی ضرورت نہیں ہوتی ہے۔ لہذا، لاگ لیول ڈیبگنگ کے مقابلے میں زیادہ ہے۔ آئیے Log4j کا استعمال کرتے ہوئے لاگ لیولز کو دیکھتے ہیں۔ JUL کے علاوہ، دیگر حل ایک ہی لاگ لیولز کا استعمال کرتے ہیں۔ یہاں وہ گھٹتی ہوئی ترتیب میں ہیں:

• بند: کوئی لاگ اندراجات درج نہیں ہیں؛ سب کچھ نظر انداز کیا جاتا ہے.
• مہلک: ایک خرابی جو ایپلیکیشن کو چلنے سے روکتی ہے۔ مثال کے طور پر، "JVM آؤٹ آف میموری ایرر"۔
• خرابی: اس سطح پر خرابیاں ان مسائل کی نشاندہی کرتی ہیں جنہیں حل کرنے کی ضرورت ہے۔ خرابی مجموعی طور پر درخواست کو نہیں روکتی ہے۔ دوسری درخواستیں صحیح طریقے سے کام کر سکتی ہیں۔
• انتباہ: لاگ اندراجات جو انتباہ کی نمائندگی کرتی ہیں۔ کچھ غیر متوقع طور پر ہوا، لیکن سسٹم نے اس سے نمٹنے کے قابل تھا اور درخواست کو پورا کیا۔
• INFO: لاگ اندراجات جو درخواست میں اہم کارروائیوں کی نشاندہی کرتی ہیں۔ یہ غلطیاں یا انتباہات نہیں ہیں۔ وہ متوقع نظام کے واقعات ہیں۔
• ڈیبگ: لاگ انٹریز کو ایپلیکیشن کو ڈیبگ کرنے کی ضرورت ہے۔ اس بات کو یقینی بنانے کے لیے کہ ایپلیکیشن بالکل وہی کرتی ہے جس کی توقع کی جاتی ہے، یا ایپلیکیشن کے ذریعے کیے گئے اقدامات کو بیان کرنے کے لیے، یعنی "Entered method1"۔
• TRACE: ڈیبگنگ کے لیے کم ترجیحی لاگ اندراجات۔ سب سے کم لاگ لیول۔
• ALL: درخواست کی تمام لاگ اندراجات لکھنے کے لیے لاگ لیول۔

INFO لاگ لیول ایپلی کیشن میں کہیں فعال ہے، پھر INFO سے FATAL تک ہر سطح کے اندراجات لاگ ان ہوں گے۔ اگر FATAL لاگ لیول سیٹ ہے، تو صرف اس لیول کے ساتھ لاگ اندراجات لکھی جائیں گی۔

لاگنگ اور لاگ بھیجنا: اپینڈر

آئیے غور کریں کہ جب ہم Log4j استعمال کرتے ہیں تو یہ سب کیسے کام کرتا ہے، جو لاگز لکھنے/ بھیجنے کے کافی مواقع فراہم کرتا ہے:

• فائل میں لکھنا -DailyRollingFileAppender
• کنسول پر معلومات لکھنے کے لیے -ConsoleAppender
• ڈیٹا بیس میں لاگ لکھنے کے لیے -JDBCAppender
• TCP/IP پر لاگ بھیجنے کا انتظام کرنے کے لیے —TelnetAppender
• اس بات کو یقینی بنانے کے لیے کہ لاگنگ کارکردگی پر منفی اثر نہیں ڈالتی ہے۔AsyncAppender

کچھ اور نفاذات ہیں: ایک مکمل فہرست یہاں دستیاب ہے ۔ ویسے، اگر آپ کو مطلوبہ ضمیمہ موجود نہیں ہے، تو کوئی مسئلہ نہیں ہے۔ اپینڈر انٹرفیس کو لاگو کرکے آپ اپنا اپینڈر لکھ سکتے ہیں ، جس کی Log4j سپورٹ کرتا ہے۔

لاگنگ نوڈس

مظاہرے کے مقاصد کے لیے، ہم 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 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

یہ لائن کہتی ہے کہ ہم CONSOLE اپینڈر کو رجسٹر کر رہے ہیں، جو org.apache.log4j.ConsoleAppender نفاذ کا استعمال کرتا ہے۔ یہ ضمیمہ کنسول کو معلومات لکھتا ہے۔ اگلا، ہم ایک اور ضمیمہ رجسٹر کرتے ہیں۔ یہ ایک فائل میں لکھے گا:

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

یہ نوٹ کرنا ضروری ہے کہ اپینڈرز کو ابھی بھی ترتیب دینے کی ضرورت ہے۔ ایک بار جب ہم اپنے ضمیمہ کو رجسٹر کر لیتے ہیں، تو ہم اس بات کا تعین کر سکتے ہیں کہ کون سے لاگ لیولز اور کون سے ضمیمہ نوڈس پر استعمال کیے جائیں گے۔

log4j.rootLogger=DEBUG، CONSOLE، فائل

• 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 پر سیٹ کیا جاتا ہے، تو اسے لاگ انٹری موصول ہوتی ہے لیکن اس کے ساتھ کچھ نہیں کرتا ہے۔ اگلا، ہمیں یہ فیصلہ کرنے کی ضرورت ہے کہ پیغام کون سا لے آؤٹ استعمال کرے گا۔ میں مثال میں پیٹرن لی آؤٹ کا استعمال کرتا ہوں، لیکن بہت سے دوسرے اختیارات ہیں۔ ہم اس مضمون میں ان کا احاطہ نہیں کریں گے۔ فائل اپینڈر کو ترتیب دینے کی مثال:

# 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 پر عوامی ذخیرے میں جا سکتے ہیں۔

ہم نے جو بات چیت کی ہے اسے تقویت دیں۔

ہم نے جو کچھ بیان کیا ہے اسے خود کرنے کی کوشش کریں:

• اوپر کی مثال کی طرح اپنا پروجیکٹ بنائیں۔
• اگر آپ Maven کو استعمال کرنا جانتے ہیں تو اسے استعمال کریں۔ اگر نہیں، تو اس ٹیوٹوریل کو پڑھیں، جس میں بتایا گیا ہے کہ لائبریری کو کیسے جوڑنا ہے۔

خلاصہ

1. ہم نے لاگنگ کے حل کے بارے میں بات کی جو جاوا میں موجود ہیں۔
2. تقریباً تمام معروف لاگنگ لائبریریاں ایک شخص نے لکھی تھیں۔
3. ہم نے سیکھا کہ کیا لاگ ان ہونا چاہیے اور کیا نہیں ہونا چاہیے۔
4. ہم نے لاگ سطحوں کا پتہ لگایا۔
5. ہمیں لاگنگ نوڈس سے متعارف کرایا گیا تھا۔
6. ہم نے دیکھا کہ ضمیمہ کیا ہے اور یہ کس کے لیے ہے۔
7. ہم نے مرحلہ وار log4j.proterties فائل بنائی۔

اضافی مواد

1. CodeGym: Logger سبق
2. ہفتہ وار گیکلی: جاوا لاگنگ۔ ہیلو دنیا
3. کوڈنگ ہارر: لاگنگ کا مسئلہ
4. یوٹیوب: جاوا لاگنگ ہیل کو سمجھنا - بنیادی باتیں۔ جاوا لاگنگ ہیل اور اس سے کیسے بچنا ہے۔
5. Log4j: اپینڈر
6. Log4j: لے آؤٹ

میرا دوسرا مضمون بھی دیکھیں:

• IntelliJ IDEA میں ڈیبگنگ: ایک ابتدائی رہنما