Log4j:ملف سجل واحد لكل طلب

Question

لدينا تطبيق دفعة weblogic الذي يعالج طلبات متعددة من المستهلكين في نفس الوقت.نحن نستخدم log4j لتسجيل الدخول.نقوم الآن بتسجيل الدخول إلى ملف سجل واحد لطلبات متعددة.يصبح من الصعب تصحيح مشكلة لطلب معين، حيث أنه بالنسبة لجميع الطلبات تكون السجلات في ملف واحد.

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

لا يمكننا تشغيل خادم الإنتاج وإيقافه في كل مرة، لذا يتم استبعاد الهدف من استخدام مُلحق ملف تم تجاوزه مع طابع التاريخ والوقت أو معرف الطلب.وهذا ما تم توضيحه في المقال أدناه:http://veerasundar.com/blog/2009/08/how-to-create-a-new-log-file-for-each-time-the-application-runs/

لقد حاولت أيضًا اللعب بهذه البدائل:

http://cognitivecache.blogspot.com/2008/08/log4j-writing-to-dynamic-log-file-for.html

http://www.mail-archive.com/log4j-user@logging.apache.org/msg05099.html

يعطي هذا الأسلوب النتائج المرجوة ولكنه لا يعمل بشكل صحيح إذا تم إرسال طلبات متعددة في نفس الوقت.بسبب بعض مشكلات التزامن، تنتقل السجلات هنا وهناك.

أتوقع بعض المساعدة منكم أيها الناس.شكرا لك مقدما....

Answer 1

وهذا سؤالي في نفس الموضوع:إنشاء وتدمير مُلحقات التسجيل ديناميكيًا

أتابع هذا في موضوع أناقش فيه القيام بشيء مثل هذا تمامًا، في القائمة البريدية لـ Log4J:http://www.qos.ch/pipermail/logback-user/2009-August/001220.html

لم يعتقد Ceci Gulcu (مخترع log4j) أنها فكرة جيدة...اقترح استخدام Logback بدلاً من ذلك.

لقد تقدمنا ​​وقمنا بذلك على أي حال، باستخدام مُلحق ملف مخصص.راجع مناقشاتي أعلاه لمزيد من التفاصيل.

Answer 2

ينظر الى SittingAppender الشحن مع تسجيل الدخول (الخلف لـ log4j)، وهو مصمم للتعامل مع إنشاء المُلحقات وفقًا لمعايير وقت التشغيل.

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

Answer 3

يتم التعامل مع هذه المشكلة بشكل جيد للغاية تسجيل الدخول مرة أخرى. أقترح اختيار ذلك إذا كان لديك الحرية.

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

لتقسيم ملفاتك على requestId, ، يمكنك أن تفعل شيئًا كهذا:

logback.xml

<configuration>

  <appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender">
    <discriminator>
      <key>requestId</key>
      <defaultValue>unknown</defaultValue>
    </discriminator>
    <sift>
      <appender name="FILE-${requestId}" class="ch.qos.logback.core.FileAppender">
        <file>${requestId}.log</file>
        <append>false</append>
        <layout class="ch.qos.logback.classic.PatternLayout">
          <pattern>%d [%thread] %level %mdc %logger{35} - %msg%n</pattern>
        </layout>
      </appender>
    </sift>
  </appender>

  <root level="DEBUG">
    <appender-ref ref="SIFT" />
  </root>

</configuration>

كما ترون (من الداخل discriminator العنصر) ، سوف تميز الملفات المستخدمة لكتابة سجلات requestId. هذا يعني أن كل طلب سيذهب إلى ملف يحتوي على مطابقة requestId. وبالتالي ، إذا كان لديك طلبان حيث requestId=1 وطلب واحد أين requestId=2, ، سيكون لديك ملفان سجلان: 1.log (2 إدخالات) و 2.log (1 دخول).

في هذه المرحلة ، قد تتساءل عن كيفية ضبط key. يتم ذلك عن طريق وضع أزواج القيمة الرئيسية في MDC (لاحظ أن المفتاح يتطابق مع المحدد في logback.xml ملف):

requestProcessor.java

public class RequestProcessor {

    private static final Logger log = LoggerFactory.getLogger(RequestProcessor.java);

    public void process(Request request) {
        MDC.put("requestId", request.getId());
        log.debug("Request received: {}", request);
    }
}

وهذا هو أساسا لحالة الاستخدام البسيطة. الآن في كل مرة يأتي فيها طلب مع معرف مختلف (لم يتم مواجهته بعد) ، سيتم إنشاء ملف جديد له.