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

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

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

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

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

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

جاوا لاگنگ ٹولز

جاوا میں لاگ ان کرنے کے معروف حل میں شامل ہیں:

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

System.err.println

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

Log4j

یہ پہلے سے ہی ایک مکمل حل تھا، جو ڈویلپرز کی ضروریات سے بنایا گیا تھا۔ یہ استعمال کرنے کے لئے واقعی ایک دلچسپ ٹول نکلا۔ مختلف حالات کی وجہ سے، یہ حل کبھی بھی JDK میں شامل نہیں ہوا، جس نے پوری کمیونٹی کو بہت پریشان کیا۔ log4j میں کنفیگریشن کے اختیارات تھے تاکہ لاگنگ کو ایک پیکج میں آن کیا جا سکے com.example.typeاور سب پیکج میں بند کیا جا سکے com.example.type.generic۔ اس سے لاگ ان کرنے کی ضرورت کو تیزی سے الگ کرنا ممکن ہو گیا جس کی ضرورت نہیں تھی۔ یہاں یہ نوٹ کرنا ضروری ہے کہ log4j کے دو ورژن ہیں: 1.2.x اور 2.x.x، جو ایک دوسرے سے مطابقت نہیں رکھتے ۔ log4j نے ایک ایسا تصور شامل کیا جیسے appender ، یعنی ایک ٹول جس کے ساتھ لاگز ریکارڈ کیے جاتے ہیں اور لے آؤٹ - لاگ فارمیٹنگ۔ یہ آپ کو صرف وہی ریکارڈ کرنے کی اجازت دیتا ہے جس کی آپ کو ضرورت ہے اور آپ کو اس کی ضرورت کیسے ہے۔ ہم تھوڑی دیر بعد ضمیمہ کے بارے میں مزید بات کریں گے۔

JUL - java.util.logging

اہم فوائد میں سے ایک حل ہے - JUL JDK (جاوا ڈویلپمنٹ کٹ) میں شامل ہے۔ بدقسمتی سے، اس کی ترقی کے دوران، یہ مقبول log4j نہیں تھا جسے بنیاد کے طور پر لیا گیا تھا، بلکہ IBM کا ایک حل تھا، جس نے اس کی ترقی کو متاثر کیا۔ درحقیقت، اس وقت JUL ہے، لیکن اسے کوئی استعمال نہیں کرتا۔ "so-so" سے: JUL میں لاگنگ کی سطح لاگ بیک، Log4j، Slf4j سے مختلف ہوتی ہے، اور اس سے ان کے درمیان مفاہمت خراب ہو جاتی ہے۔ لاگر بنانا کم و بیش اسی طرح کا ہے۔ ایسا کرنے کے لیے آپ کو درآمد کرنے کی ضرورت ہے:

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

کلاس کا نام خاص طور پر یہ جاننے کے لیے دیا جاتا ہے کہ لاگنگ کہاں سے آ رہی ہے۔ جاوا 8 کے بعد سے، پاس کرنا ممکن ہے Supplier<String>۔ اس سے سٹرنگ کو صرف اس وقت گننے اور بنانے میں مدد ملتی ہے جب اس کی واقعی ضرورت ہو، اور ہر بار نہیں، جیسا کہ پہلے تھا۔ صرف Java 8 کی ریلیز کے ساتھ ہی ڈویلپرز نے اہم مسائل حل کیے، جس کے بعد JUL صحیح معنوں میں قابل استعمال بن گیا۔ یعنی دلیل کے ساتھ طریقے Supplier<String> msgSupplierجیسا کہ ذیل میں دکھایا گیا ہے:

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

جے سی ایل - جکارتہ کامنز لاگنگ

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

لاگ بیک

اوپن سورس کا راستہ کتنا کانٹا ہے... لاگ بیک اسی ڈویلپر نے 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 - جاوا کے لیے سادہ لاگنگ اگواڑا

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 اور اس سے زیادہ ہو تو مسائل شروع ہوتے ہیں۔ یعنی، اس لاگ کو نہیں لکھا جانا چاہیے، اور سٹرنگ کنکٹیشن بھی نہیں کیا جانا چاہیے۔ نظریہ طور پر، اس کا فیصلہ لاگنگ لائبریری کو خود کرنا چاہیے تھا۔ مزید یہ کہ یہ 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 کے علاوہ دیگر حل ایک ہی سطح کا استعمال کرتے ہیں۔ یہاں وہ گھٹتی ہوئی ترتیب میں ہیں:

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

اس سے پتہ چلتا ہے کہ اگر ایپلی کیشن میں کسی جگہ INFO لاگنگ لیول کو فعال کیا جاتا ہے، تو INFO سے شروع ہو کر FATAL تک تمام لیولز لاگ ان ہو جائیں گی۔ اگر لاگنگ لیول مہلک ہے، تو صرف اس لیول والے لاگز ہی ریکارڈ کیے جائیں گے۔

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

ہم مثال کے طور پر log4j کا استعمال کرتے ہوئے اس عمل پر غور کریں گے: یہ لاگز کو ریکارڈ کرنے/ بھیجنے کے لیے کافی مواقع فراہم کرتا ہے:

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

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

لاگنگ نوڈس

مظاہرے کے لیے ہم slf4j انٹرفیس، اور لاگ 4j سے نفاذ کا استعمال کریں گے۔ لاگر بنانا بہت آسان ہے: آپ کو کلاس میں درج ذیل کو لکھنا ہوگا 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- اس میں ایک لاگر بنایا گیا تھا۔ اور اس طرح اسے لاگنگ نوڈس میں تقسیم کیا جا سکتا ہے۔ مرکزی نوڈ null RootLogger ہے ۔ یہ وہ نوڈ ہے جو پوری ایپلی کیشن کے تمام لاگ وصول کرتا ہے۔ باقی کو ذیل میں دکھایا گیا ہے جیسا کہ دکھایا جا سکتا ہے: ضمیمہ کرنے والے اپنے کام کو خاص طور پر لاگنگ نوڈس پر ترتیب دیتے ہیں۔ اب، مثال کے طور پر 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 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

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

# 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۔ فائل کے سائز کے ساتھ مسائل سے بچنے کے لیے، آپ زیادہ سے زیادہ سیٹ کر سکتے ہیں: اس صورت میں، 1MB۔ MaxBackupIndex - بتاتا ہے کہ ایسی کتنی فائلیں ہوں گی۔ اگر اس سے زیادہ تعداد بنتی ہے تو پہلی فائل کو حذف کر دیا جائے گا۔ ایک حقیقی مثال کو دیکھنے کے لیے جہاں لاگنگ کو کنفیگر کیا گیا ہے، آپ GitHub پر اوپن ریپوزٹری میں جا سکتے ہیں۔

آئیے نتیجہ کو مضبوط کریں۔

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

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

آئیے اس کا خلاصہ کرتے ہیں۔

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

اضافی مواد

1. JavaRush: لاگنگ۔ اسٹیکٹریس کی ایک گیند کو کھولیں۔
2. جاوا رش: لاگر لیکچر
3. ہیبر: جاوا لاگنگ۔ ہیلو دنیا
4. حبر: جاوا لاگنگ: ایک ڈراؤنے خواب کی کہانی
5. یوٹیوب: گولووچ کورسز۔ لاگنگ حصہ 1 ، حصہ 2 ، حصہ 3 ، حصہ 4
6. Log4j: ضمیمہ
7. Log4j: لے آؤٹ

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

• انٹرویو کا ٹیسٹ اوپن سورس لائبریری میں کیسے تبدیل ہوا۔
• ہوائی ٹکٹ کی قیمت کی نگرانی کا نظام بنانا: مرحلہ وار گائیڈ [حصہ 1]
• Skyscanner API کے لیے کلائنٹ بنانے اور اسے jCenter اور Maven Central میں شائع کرنے کے لیے گائیڈ [حصہ 1]
• Intellij IDEA میں ڈیبگ: ابتدائیوں کے لیے ایک گائیڈ