Adakah kelas utiliti log Java anda melaporkan dirinya sebagai sumber log anda? Ketahui cara membetulkannya!

Dalam persekitaran pantas pembangunan perisian moden, pengelogan yang berkesan adalah penting untuk penyahpepijatan yang cekap dan pemantauan sistem. Walau bagaimanapun, nombor talian yang tidak konsisten atau tidak tepat dalam output log boleh menjadikan penyelesaian masalah memakan masa. Baru-baru ini, saya mengenal pasti bahawa utiliti pembalakan dalaman kami melaporkan dirinya sebagai sumber log. Ini perlu ditangani untuk meningkatkan ketepatan log.

Masalahnya

Apabila menggunakan kelas utiliti tersuai untuk mengendalikan log, ia akan mula melaporkan dirinya sebagai sumber log, kerana kelas utiliti ialah kelas yang akhirnya memanggil rangka kerja log sebenar (dalam kes saya, ia adalah SLF4J , dengan Log4J2 sebagai hujung belakang).

Jadi, jika kelas utiliti dipanggil InternalLogger, log akan kelihatan seperti:

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

Di sini, fail sumber dan nombor talian yang dilaporkan menghala ke lokasi dalam utiliti pengelogan itu sendiri, bukannya tempat panggilan log sebenarnya dibuat dalam kod aplikasi. Tingkah laku ini mengurangkan keberkesanan log dalam penyahpepijatan dan menentukan isu dengan cepat.

Penyelesaian

Mula-mula saya terfikir untuk menyusuri jejak tindanan secara manual dan menapis beberapa elemen sebelum melaporkan nombor baris. Pendekatan ini memerlukan kos yang tinggi dan saya tidak mahu memperlahankan proses pembalakan kami.

Nasib baik, saya dapati dalam jawapan StackOverflow ini bahawa SLF4J menyediakan antara muka yang dipanggil LocationAwareLogger, yang disokong oleh Log4J2, jadi, kami boleh menapis kelas utiliti dengan hanya melepasi FQCN Kelas Utiliti Log (Nama Kelas Berkelayakan Penuh).

Kelas utiliti asal saya kelihatan seperti ini:

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);

Untuk penyelesaian ini, saya mengisytiharkan kelas Logger FQCN dan menambah fungsi pembantu peribadi untuk log dengan 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);
  }

Dan menukar kod lama saya untuk memanggilnya jika disokong:

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);
    }
//...

Malangnya, SLF4J tidak menyediakan cara untuk menyediakan tahap sebagai hujah (iaitu LOG.log(level, mesej)). Jika ia berlaku, kod itu akan menjadi kurang bertele-tele.

Selepas melaksanakan perubahan ini, log kini melaporkan nombor talian pemanggil dengan tepat, meningkatkan kebolehkesanan dengan ketara:

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

Perhatikan perbezaannya: InternalLogger.java:34 berbanding ActualLogic.java:1059, yang menunjukkan lokasi asal log yang lebih tepat dalam kod aplikasi.

Kesimpulan

Dengan menggabungkan LocationAwareLogger SLF4J, saya telah mengubah sistem pengelogan kami daripada sumber kekeliruan kepada alat diagnostik yang tepat. Perubahan ini membolehkan pelaporan tepat nombor talian pemanggil dan bukannya utiliti pengelogan, meningkatkan keupayaan kami untuk mendiagnosis isu dengan pantas dan tepat.

Peningkatan ini bukan sahaja memperkemas penyahpepijatan tetapi juga mengurangkan masa tindak balas apabila menangani isu perisian.

Pemaju yang menghadapi cabaran yang sama harus mempertimbangkan pendekatan ini untuk meningkatkan keberkesanan sistem pembalakan mereka. Dengan log yang lebih jelas dan tepat, mereka boleh menukar data yang dahulunya samar-samar menjadi cerapan yang boleh diambil tindakan, meningkatkan kecekapan operasi dan kebolehpercayaan perisian. Pembalakan yang dioptimumkan adalah penting untuk menghadapi cabaran landskap pembangunan pantas hari ini dan memastikan hasil perisian yang berkualiti tinggi.

Atas ialah kandungan terperinci Adakah kelas utiliti log Java anda melaporkan dirinya sebagai sumber log anda? Ketahui cara membetulkannya!. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!