Structured Logging در مقابل Plain Text Logging
Structured Logging لاگها را بهصورت دادههای ساختیافته (معمولاً JSON) با فیلدهای مجزا ثبت میکند که بهراحتی قابل جستجو و تحلیل در ابزارهایی مثل Seq یا ELK هستند؛ Plain Text Logging پیامها را بهصورت رشته متنی ساده مینویسد که خواندن سریع آن برای انسان راحت است اما جستجو و تحلیل برنامهای آن دشوار و شکننده است.
| ویژگی | Structured Logging | Plain Text Logging |
|---|---|---|
| قابلیت Query/فیلتر | بالا (بر اساس فیلد) | پایین (نیاز به regex/grep) |
| فرمت ذخیرهسازی | JSON یا ساختیافته | رشته متنی خام |
| یکپارچگی با ابزار تحلیل | عالی (Seq، ELK، Application Insights) | ضعیف |
| مناسب برای | سیستمهای production | اسکریپتهای کوچک/دیباگ محلی |
کِی از Structured Logging استفاده کنیم؟
در هر سیستم production واقعی، بهخصوص با حجم بالای لاگ یا نیاز به dashboard/alerting، از Structured Logging (با ILogger و placeholderهای نامدار) استفاده کنید تا بتوانید بر اساس فیلدها query بزنید.
کِی از Plain Text Logging استفاده کنیم؟
برای اسکریپتهای کوچک، دیباگ موقت محلی یا ابزارهای CLI ساده که هیچکس قرار نیست لاگ آنها را برنامهنویسی تحلیل کند، Plain Text کافی و سریعتر برای نوشتن است.
مثال Structured Logging
_logger.LogInformation("Order {OrderId} created for {CustomerId} at {Amount}",
order.Id, order.CustomerId, order.Amount);
// Stored as structured fields, queryable: OrderId=8841 AND Amount > 1000
مثال Plain Text Logging
Console.WriteLine($"Order {order.Id} created for {order.CustomerId} at {order.Amount}");
// Just a string - searching requires regex/grep over raw text
اشتباه رایج
استفاده از string interpolation در LogInformation (مثل $"Order {order.Id}...") بهجای placeholder های نامدار — این کار مزیت اصلی Structured Logging (قابلیت query روی فیلدها) را از بین میبرد و آن را به یک لاگ متنی ساده تبدیل میکند، حتی اگر از ILogger استفاده شده باشد.
جمعبندی
در production همیشه Structured Logging با placeholder های نامدار استفاده کنید، هرگز از string interpolation در متد لاگ استفاده نکنید.