في بيئة تطوير البرامج الحديثة سريعة الخطى، يعد التسجيل الفعال أمرًا بالغ الأهمية لتصحيح الأخطاء ومراقبة النظام بكفاءة. ومع ذلك، فإن أرقام الأسطر غير المتسقة أو غير الدقيقة في مخرجات السجل يمكن أن تجعل عملية استكشاف الأخطاء وإصلاحها تستغرق وقتًا طويلاً. لقد حددت مؤخرًا أن أداة التسجيل الداخلية لدينا كانت تعلن عن نفسها كمصدر للسجلات. يجب معالجة هذا الأمر لتحسين دقة السجل.

المشكلة

عند استخدام فئة أداة مساعدة مخصصة للتعامل مع السجلات، ستبدأ في الإبلاغ عن نفسها كمصدر للسجل، حيث أن فئة الأداة المساعدة هي التي تستدعي أخيرًا إطار عمل السجل الفعلي (في حالتي، كان SLF4J ، مع Log4J2 كواجهة خلفية).

لذلك، إذا كانت فئة الأداة المساعدة تسمى InternalLogger، فسيبدو السجل كما يلي:

2024-10-11T18:10:57,345 [finagle/netty4-6] (InternalLogger.java:34) INFO ...  

هنا، يشير الملف المصدر ورقم السطر المُبلغ عنهما إلى موقع داخل أداة التسجيل المساعدة نفسها، بدلاً من المكان الذي تم فيه إجراء استدعاء السجل فعليًا في كود التطبيق. يخفف هذا السلوك من فعالية السجلات في تصحيح الأخطاء وتحديد المشكلات بسرعة.

الحل

فكرت أولاً في السير يدويًا عبر تتبع المكدس وتصفية بعض العناصر قبل الإبلاغ عن رقم السطر. سيكون هذا الأسلوب مكلفًا للغاية، ولم أرغب في إبطاء عملية التسجيل لدينا.

لحسن الحظ، وجدت في إجابة StackOverflow أن SLF4J يوفر واجهة تسمى LocationAwareLogger، والتي يدعمها Log4J2، لذلك، يمكننا تصفية فئة الأداة المساعدة ببساطة عن طريق تمرير FQCN لفئة Log Utility (اسم الفئة المؤهلة بالكامل).

بدت فئة المرافق الأصلية الخاصة بي على النحو التالي:

public class InternalLogger {

  private static final Logger LOG = LoggerFactory.getLogger(InternalLogger.class);

  public void log(EventLog eventLog) {
    //... get message and logLevel from eventLog
    switch (logLevel) {
      case DEBUG:
        LOG.debug(message);
        break;
      case WARN:
        LOG.warn(message);

بالنسبة لهذا الحل، أعلنت عن فئة المسجل FQCN وأضفت وظيفة مساعد خاصة للتسجيل باستخدام LocationAwareLogger:

private static final String LOGGER_UTIL_FQCN = InternalLogger.class.getName();

  private void locationAwareLog(int level, String message) {
    ((LocationAwareLogger) LOG).log(null, LOGGER_UTIL_FQCN, level, message, null, null);
  }

وغيرت الكود القديم لاستدعائه إذا كان مدعومًا:

switch (logLevel) {
  case DEBUG:
    if (LOG instanceof LocationAwareLogger) {
      locationAwareLog(LocationAwareLogger.DEBUG_INT, message);
    } else {
      LOG.debug(message);
    }
    break;
  case WARN:
    if (LOG instanceof LocationAwareLogger) {
      locationAwareLog(LocationAwareLogger.WARN_INT, message);
    } else {
      LOG.warn(message);
    }
//...

لسوء الحظ، لا يوفر SLF4J طريقة لتوفير المستوى كوسيطة (أي LOG.log(level, message)). إذا كان الأمر كذلك، فسيكون الكود أقل تفصيلاً.

بعد تنفيذ هذا التغيير، أصبحت السجلات الآن تقدم تقريرًا دقيقًا عن رقم خط المتصل، مما يؤدي إلى تحسين إمكانية التتبع بشكل ملحوظ:

2024-10-11T18:45:26,692 [finagle/netty4-6] (ActualLogic.java:1059) INFO ...

لاحظ الفرق: InternalLogger.java:34 مقابل ActualLogic.java:1059، والذي يشير إلى موقع أكثر دقة لأصل السجل داخل كود التطبيق.

خاتمة

من خلال دمج LocationAwareLogger الخاص بـ SLF4J، قمت بتحويل نظام التسجيل الخاص بنا من مصدر للارتباك إلى أداة تشخيصية دقيقة. يتيح هذا التغيير إعداد تقارير دقيقة عن رقم خط المتصل بدلاً من ذلك الخاص بأداة التسجيل المساعدة، مما يعزز بشكل كبير قدرتنا على تشخيص المشكلات بسرعة ودقة.

لا يعمل هذا التحسين على تبسيط تصحيح الأخطاء فحسب، بل يقلل أيضًا من أوقات الاستجابة عند معالجة مشكلات البرامج.

يجب على المطورين الذين يواجهون تحديات مماثلة أن يأخذوا في الاعتبار هذا النهج لرفع فعالية أنظمة التسجيل الخاصة بهم. ومن خلال سجلات أكثر وضوحًا ودقة، يمكنهم تحويل ما كان في السابق بيانات غامضة إلى رؤى قابلة للتنفيذ، مما يؤدي إلى تحسين الكفاءة التشغيلية وموثوقية البرامج. يعد التسجيل الأمثل أمرًا بالغ الأهمية لمواجهة تحديات مشهد التطوير سريع الخطى اليوم وضمان نتائج برمجية عالية الجودة.