2. ILogger

স্বাগতম! আজকে আমরা শিখতে যাচ্ছি Logging-এর একটি অত্যন্ত গুরুত্বপূর্ণ এবং কোর কনসেপ্ট—Log Levels।

আপনার Outline অনুযায়ী, আমরা এখন Section 20: Logging-এর দ্বিতীয় ধাপে আছি (সম্ভবত “267. ILogger”)। আগের লেকচারে আমরা Logging-এর বেসিক এবং এর প্রয়োজনীয়তা জেনেছি। আজকে আমরা শিখব কোন পরিস্থিতিতে ঠিক কোন ধরণের Log ব্যবহার করতে হয় এবং Program.cs ফাইল থেকে কীভাবে লগ জেনারেট করতে হয়।

চলুন শুরু করা যাক!

📝 Short Summary for Quick Revision

Log Levels-এর ধরন: প্রধানত ৬টি Log level রয়েছে— Trace, Debug, Information, Warning, Error, এবং Critical।
Trace-এর ব্যবহার: রিয়েল-ওয়ার্ল্ড প্রজেক্টে Trace খুব একটা ব্যবহৃত হয় না।
Information: Application-এর সাধারণ ফ্লো (যেমন: Controller action method-এ রিকোয়েস্ট আসা) ট্র্যাক করতে ব্যবহৃত হয়।
Debug: ভ্যারিয়েবলের কারেন্ট ভ্যালু বা লুপের অবস্থা চেক করার মতো ডিবাগিং কাজে ব্যবহৃত হয়।
Warning: Application-এ কোনো অপ্রত্যাশিত আচরণ ঘটলে (Unexpected behavior) এটি ব্যবহার করা হয়।
Error & Critical: যেকোনো Exception-এর ক্ষেত্রে Error এবং Application ক্র্যাশ করার মতো মারাত্মক ত্রুটির ক্ষেত্রে Critical ব্যবহৃত হয়।
Default Settings: ASP.NET Core-এ ডিফল্ট Log Level হলো ‘Information’। এ কারণে Debug এবং Trace লগগুলো কনসোলে বাই ডিফল্ট প্রিন্ট হয় না।

🧠 Comprehensive Breakdown

এখানে আমরা লেকচারের প্রতিটি বিষয় বিস্তারিতভাবে আলোচনা করব এবং সাথে Code Implementation দেখব।

১. Log Levels কী এবং কেন এটি প্রয়োজন? (Priority: 10/10)

Logging করার সময় সব ইনফরমেশনের গুরুত্ব (Severity) সমান থাকে না। কোনোটি সাধারণ তথ্য, আবার কোনোটি মারাত্মক ক্র্যাশ রিপোর্ট। আপনার Log message-এর গুরুত্ব অনুযায়ী সেটিকে ক্যাটাগরাইজ করার উপায়ই হলো Log Levels।

প্রধান Log Level-গুলো হলো (কম গুরুত্ব থেকে বেশি গুরুত্ব ক্রমানুসারে):

Trace: খুব ডিটেইলড মেসেজ, সাধারণত প্রোডাকশনে একদমই লাগে না।
Debug: ডেভেলপমেন্টের সময় ভ্যারিয়েবলের ভ্যালু চেক করতে।
Information: সাধারণ ফ্লো বা ইভেন্ট ট্র্যাক করতে।
Warning: অ্যাপ্লিকেশন ক্র্যাশ করেনি, কিন্তু কিছু একটা অস্বাভাবিক ঘটেছে।
Error: নির্দিষ্ট কোনো অপারেশনে Exception খেলে।
Critical: পুরো অ্যাপ্লিকেশন বা সার্ভার ক্র্যাশ করার মতো অবস্থা হলে।

Why we need it: যখন আপনি প্রোডাকশনে আপনার Application-এর লগ চেক করবেন, তখন লাখ লাখ লগের মধ্যে শুধু ‘Error’ বা ‘Critical’ লেভেল ফিল্টার করে আপনি খুব সহজেই মূল সমস্যাগুলো বের করে ফেলতে পারবেন।

২. কখন কোন Log Level ব্যবহার করবেন? (Real-world Examples) (Priority: 9/10)

লেকচারে ট্রেইনার খুব সুন্দর কিছু উদাহরণ দিয়েছেন:

Debug: ধরুন আপনার একটি for লুপ আছে যা ১০ বার ঘুরবে (i = 0 থেকে i < 10)। প্রতিবার লুপ ঘোরার সময় i-এর বর্তমান ভ্যালু কী, তা জানার জন্য আপনি LogDebug ব্যবহার করবেন।
Information: Execution যখন কোনো নির্দিষ্ট Controller action method-এ পৌঁছায়, তখন “Request received” বোঝাতে LogInformation ব্যবহার করা হয়।
Warning: ধরুন আপনি ডেটাবেসে একটি Update Query পাঠিয়েছেন। কোনো Exception হয়নি, কিন্তু Number of rows updated হলো 0। এটি একটি অপ্রত্যাশিত ঘটনা। এক্ষেত্রে LogWarning ব্যবহার করতে হবে যাতে ডেভেলপার বুঝতে পারে যে আইডিতে বা কন্ডিশনে কোনো সমস্যা ছিল। আরেকটি উদাহরণ হলো, isDeleted ফ্ল্যাগটি true হওয়ার কথা ছিল, কিন্তু কোনো কারণে সেটি false রিটার্ন করেছে।
Error: File বা Database-এর সাথে কানেক্ট করার সময় কোনো Exception ঘটলে LogError ব্যবহার করে সেই Exception-এর ডিটেইলস সেভ করা হয়।
Critical: এমন কোনো Exception যার কারণে End user চরমভাবে ক্ষতিগ্রস্ত হচ্ছে বা সার্ভার ডাউন হয়ে যাচ্ছে, সেখানে LogCritical ব্যবহার করতে হবে।

৩. Code Implementation: Program.cs-এ Logging (Priority: 10/10)

ASP.NET Core-এর Program.cs ফাইলে app.Logger প্রোপার্টি ব্যবহার করে খুব সহজেই লগের কাজ করা যায়।

Code Implementation:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
 
// Application রান করার সময় বিভিন্ন লেভেলের লগ জেনারেট করা
app.Logger.LogDebug("This is a DEBUG message. i = 5");
app.Logger.LogInformation("This is an INFORMATION message. Execution reached here.");
app.Logger.LogWarning("This is a WARNING message. Row updated count is 0.");
app.Logger.LogError("This is an ERROR message. Database connection failed.");
app.Logger.LogCritical("This is a CRITICAL message. Server is out of memory!");
 
app.Run();

৪. Kestrel Console এবং Default Log Level (Priority: 9/10)

আপনি যখন উপরের কোডটি রান করে Kestrel command prompt window (টার্মিনাল বা কনসোল) খুলবেন, তখন দেখবেন সেখানে Information, Warning, Error (fail) এবং Critical (crit) মেসেজগুলো সুন্দর কালার কোডসহ দেখা যাচ্ছে।

কিন্তু Debug মেসেজটি কোথায়? এর কারণ হলো, ASP.NET Core-এ ডিফল্ট Log Level সেট করা থাকে Information-এ। এর মানে হলো Information এবং তার উপরের লেভেলের (Warning, Error, Critical) লগগুলোই শুধু প্রিন্ট হবে। এর নিচের লেভেল (Debug, Trace) ইগনোর করা হবে। আগামী লেকচারে আপনারা শিখবেন কীভাবে appsettings.json ফাইল ব্যবহার করে এই কনফিগারেশন পরিবর্তন করতে হয়।

🚀 Best Practices & .NET Modern Updates

Best Practices for Logging:

কখনোই প্লেইন স্ট্রিং ব্যবহার করবেন না: লগিংয়ের ক্ষেত্রে সবসময় Structured Logging (বা Semantic Logging) ব্যবহার করবেন।
ভুল পদ্ধতি: app.Logger.LogInformation("User " + userId + " logged in.");
সঠিক পদ্ধতি: app.Logger.LogInformation("User {UserId} logged in.", userId); (এখানে {UserId} ভ্যারিয়েবলটি লগে প্রপার্টি হিসেবে সেভ হবে, যা পরে সার্চ করা সহজ)।
Exception Logging: LogError-এর ক্ষেত্রে সবসময় Exception অবজেক্টটি পাস করবেন, শুধু মেসেজ নয়।
সঠিক পদ্ধতি: app.Logger.LogError(ex, "Failed to connect to DB");

Modern .NET Updates (.NET 8 / .NET 10): যেহেতু এখানে Minimal API (Program.cs) স্টাইলে কাজ হচ্ছে, তাই জেনে রাখা ভালো যে আধুনিক .NET ভার্সনে লগিং পারফরম্যান্স অনেক ইমপ্রুভ করা হয়েছে। .NET-এ এখন Source-Generated Logging বা LoggerMessage পপ্যুলার হলেও, সাধারণ ইনলাইন কোডের জন্য .NET 10-এ নতুন Log মেথডগুলো অনেক বেশি মেমরি এফিশিয়েন্ট।

Minimal API বা Web API-তে Dependency Injection-এর মাধ্যমে Controller বা Service-এ লগিং করাটাই স্ট্যান্ডার্ড। যেমন:

app.MapGet("/api/users/{id}", (int id, ILogger<Program> logger) => 
{
    // Structured Logging in Minimal API (.NET 10 approach remains similar but optimized under the hood)
    logger.LogInformation("Fetching user with ID: {UserId}", id);
    
    if(id <= 0) 
    {
        logger.LogWarning("Invalid User ID: {UserId} provided.", id);
        return Results.BadRequest();
    }
    
    return Results.Ok($"User {id} found.");
});

আশা করি কনসেপ্টগুলো আপনার কাছে একদম ক্লিয়ার! সামনের কনফিগারেশন লেকচারটি আরও মজাদার হবে।

Quartz 5

Explorer