Zasady i porady dotyczące logowania?

W mojej organizacji opracowaliśmy kilka zasad / linii gildii dotyczących logowania, które chciałbym wiedzieć, czy możesz dodawać lub komentować.

Używamy Javy, ale możesz ogólnie komentować zasady logowania - zasady i porady

1. Użyj prawidłowego poziomu rejestrowania

   • BŁĄD: Coś poszło nie tak i trzeba natychmiast naprawić
   • OSTRZEŻENIE: Proces można kontynuować bez naprawy. Aplikacja powinna tolerować ten poziom, ale ostrzeżenie powinno zawsze zostać zbadane.
   • INFORMACJE: Informacja o zakończeniu ważnego procesu
   • ODPLUSKWIĆ. Jest używany tylko podczas programowania

2. Upewnij się, że wiesz, co logujesz.

3. Unikaj, aby rejestrowanie miało wpływ na zachowanie aplikacji

Funkcja rejestrowania powinna polegać na zapisywaniu komunikatów w dzienniku.

1. Wiadomości z dziennika powinny być opisowe, jasne, krótkie i zwięzłe.

Podczas rozwiązywania problemów nie ma większego zastosowania bzdury.

1. Umieść odpowiednie właściwości w log4j

Wstaw odpowiednią metodę i klasę, która jest zapisywana automatycznie.

Przykład:

Datedfile -web

log4j.rootLogger=ERROR, DATEDFILE
log4j.logger.org.springframework=INFO
log4j.logger.waffle=ERROR
log4j.logger.se.prv=INFO
log4j.logger.se.prv.common.mvc=INFO
log4j.logger.se.prv.omklassning=DEBUG

log4j.appender.DATEDFILE=biz.minaret.log4j.DatedFileAppender
log4j.appender.DATEDFILE.layout=org.apache.log4j.PatternLayout
log4j.appender.DATEDFILE.layout.ConversionPattern=%d{HH:mm:ss,SSS} %-5p [%C{1}.%M] - %m%n

log4j.appender.DATEDFILE.Prefix=omklassning.
log4j.appender.DATEDFILE.Suffix=.log
log4j.appender.DATEDFILE.Directory=//localhost/WebSphereLog/omklassning/

1. Zaloguj wartość

Zaloguj wartości z aplikacji.

1. Przedrostek dziennika.

Podaj, z której części aplikacji pochodzi logowanie, najlepiej z prefiksem projektu np PANDORA_DB

1. Ilość tekstu.

Uważaj, aby nie było za dużo tekstu logowania. Może to wpływać na wydajność aplikacji.

1. Format rejestrowania:

- Istnieje kilka wariantów i metod do użycia z log4j, ale chcielibyśmy jednolitego użycia następującego formatu, gdy logujemy się w wyjątkach:

logger.error("PANDORA_DB2: Fel vid hämtning av frist i TP210_RAPPORTFRIST", e);

W powyższym przykładzie założono, że ustawiliśmy właściwości log4j, aby automatycznie zapisywał klasę i metodę.

Zawsze używaj rejestratora, a nie:

System.out.println(), System.err.println(), e.printStackTrace()

Jeśli aplikacja internetowa korzysta z naszej struktury, możesz uzyskać bardzo szczegółowe informacje o błędach od EJB, jeśli używasz try-catch w module obsługi i logujesz się zgodnie z powyższym modelem:

W naszym projekcie wykorzystujemy ten wzorzec konwersji, dzięki któremu nazwy metod i klas są zapisywane automatycznie. Tutaj używamy dwóch różnych patentów dla konsoli i dla datowanego pliku apletu:

log4j.appender.CONSOLE.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n

log4j.appender.DATEDFILE.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

W obu powyższych przykładach metoda i klasa zostaną zapisane. W wierszu konsoli będzie również zapisany numer naszego.

1. toString()

Proszę mieć toString()dla każdego obiektu. DAWNY:

@Override
public String toString() {
  StringBuilder sb = new StringBuilder();
  sb.append(" DwfInformation [ ");
  sb.append("cc: ").append(cc);
  sb.append("pn: ").append(pn);
  sb.append("kc: ").append(kc);
  sb.append("numberOfPages: ").append(numberOfPages);
  sb.append("publicationDate: ").append(publicationDate);
  sb.append("version: ").append(version);
  sb.append(" ]");
  return sb.toString();
}

zamiast specjalnej metody, która tworzy te wyniki

public void printAll()
{
    logger.info("inbet: " + getInbetInput());
    logger.info("betdat: " + betdat);
    logger.info("betid: " + betid);
    logger.info("send: " + send);
    logger.info("appr: " + appr);
    logger.info("rereg: " + rereg);   
    logger.info("NY: " + ny);   
    logger.info("CNT: " + cnt);   
}

Czy jest coś, co można dodać, skomentować lub uznać za wątpliwe przy użyciu tych sposobów korzystania z rejestrowania? Nie krępuj się odpowiadać lub komentować, nawet jeśli nie jest to związane z Javą, Javą, a log4j to tylko implementacja uzasadnienia.

Jako rozszerzenie reguły rejestrowania, z której aplikacji pochodzi instrukcja dziennika, warto dodać flagi rejestrowania na poziomie modułu. Zamiast rejestrować wszystko przez cały czas, pozwala to zamiast tego selektywnie celować w sekcje aplikacji. Jest to narzut i musisz stworzyć funkcję, która pozwoli ci włączyć / wyłączyć rejestrowanie. Idealnie byłoby, gdybyś mógł włączyć / wyłączyć w trakcie pracy aplikacji.

Przyzwyczaiłem się widzieć warstwę poniżej debugowania, którą nazywam „Trace”, ale niekoniecznie jest to termin uniwersalny. Rejestrowanie na poziomie „Śledzenia” śledzi tyle, ile możesz, w tym wejście / wyjście modułu, znaczniki czasu z wejściem / wyjściem i punkty bonusowe za przechwytywanie przekazanych wartości. Oczywiście generuje to DUŻO danych i nie jest to coś, co włączasz chcąc nie chcąc. Ma jednak zalety w odniesieniu do debugowania, gdy nie można dołączyć do procesu lub nie ma zrzutu podstawowego błędnej aplikacji.

Lubię widzieć odwołania do plików / modułów i znaczniki czasu z informacjami z mojego dziennika. Może to być przydatne, gdy próbujesz wyśledzić warunki wyścigu między wątkami, a także koordynować działania wielu obszarów aplikacji. Szczerze mówiąc, znam ludzi, którzy uważają, że te szczegóły zaśmiecają plik dziennika. Dodanie znacznika czasu jest czymś do przedyskutowania z zespołem. (Przepraszamy, jeśli log4j już to robi).

Jeśli rejestrowanie nie jest obsługiwane przez własny wątek / proces, jest to również kwestia do rozważenia. Zamiast zmuszać wątek aplikacji do oczekiwania na przetworzenie rejestrowania, komunikat dziennika jest przekazywany do modułu obsługi dziennika, a wątek aplikacji idzie w wesoły sposób. Alternatywnie, stworzenie pewnego rodzaju mechanizmu buforowego do obsługi komunikatów dziennika jest innym sposobem na przyspieszenie reakcji aplikacji.

Kontrolowanie rozmiaru i historii plików dziennika to kolejna funkcja, którą należy rozważyć. Nie chcesz, aby aplikacja wysadzała całe miejsce na dysku w systemie hosta, ani niekoniecznie chcesz przechowywać wszystkie pliki dziennika na całą wieczność.

Jedną z rzeczy, o których należy pamiętać, jest sprawdzenie poziomu rejestrowania przed wykonaniem jakichkolwiek operacji łańcuchowych w celu rejestrowania. Oznacza to, że nie wykonuj wszystkich prac związanych z konfigurowaniem formatera daty lub łączeniem wiązki ciągów w celu utworzenia komunikatu dziennika, jeśli tak naprawdę nie zamierzasz go zalogować. To tylko zmarnowana praca, która spowalnia działanie aplikacji.

Do Twojej wiadomości, projekt Apache Commons ma ToStringBuilder klasę, która upraszcza tworzenie twoich toString()metod.

Nie znalazłem nic wątpliwego w tym, co tu dodałeś Nick. Tak to robię od jakiegoś czasu. Przekazany przez Ciebie post jest bardzo szczegółowy i prawdopodobnie można go wykorzystać jako rodzaj samouczka do logowania. Chciałbym jednak dodać tutaj jedną rzecz: w wielu miejscach widziałem facetów korzystających z rejestrowania warunkowego, na przykład:

     if(env_local)
     {
     write_to_local();
     }    
     else if(env_IT)
     {
     write_to_IT();
     } 
     else if(env_PROD)
     {
     write_to_prod();
     } 
     else
     dosomething();

Myślę, że tego rodzaju warunkowe śledzenie lub debugowanie nie jest najlepszym sposobem.

Oprócz rejestrowania klasy / metody, która zgłosiła błąd, przydatne byłoby również zarejestrowanie parametrów przekazanych do tej metody. Wiedza, gdzie został zgłoszony błąd, nie jest zbyt przydatna, jeśli zdarza się to tylko 1 raz na 1000; musisz także wiedzieć, jakie dane spowodowały wystąpienie błędu.

Uznałem również, że warto mieć zmienną, która określa domyślny poziom rejestrowania aplikacji. W ten sposób możesz mieć kod DEBUG i INFO wraz z kodem OSTRZEŻENIE i BŁĄD. Podczas pracy w trybie produkcyjnym domyślnie nie wyświetla on informacji DEBUG, ale gdy pojawia się błąd, możesz zaktualizować flagę i rozpocząć zapisywanie komunikatów DEBUG w dzienniku.

Rejestrowanie jest w większości przypadków zagadnieniem przekrojowym. Sama Java nie jest wystarczająco ekspresyjna, aby umożliwić oddzielenie rejestrowania od rzeczywistej logiki biznesowej. Oznacza to, że nie możesz na przykład po prostu zastosować jednej metody i umieścić jej w innym projekcie, ale musisz usunąć i dostosować wszystkie swoje rejestrowanie. I to tylko wierzchołek góry lodowej.

Aby zapobiec temu i innym problemom podczas łączenia rejestrowania i „prawdziwej” logiki biznesowej, powinieneś rozważyć zastosowanie programowania aspektowego. W przypadku Javy najczęściej używaną strukturą będzie AspectJ. Jest ten film z youtube z rozmów technicznych Google, który wyjaśnia AspectJ i jego zastosowania poza całkiem dobrym logowaniem. Znajdziesz tu również wiele przykładów logowania się tutaj na stackexchange .

Jedną rzeczą, którą zasugerowałbym, jest to, że masz możliwość posiadania wielu kontekstów rejestrowania powiązanych z dowolnym konkretnym plikiem dziennika i ustaw tak, aby wszystko, co zapisano w dowolnym kontekście rejestrowania, zostanie zarejestrowane, chyba że kod wyraźnie poprosi kontekst rejestrowania o usunięcie jego zawartości. Taki projekt pozwoli uchwycić dość szczegółowe dzienniki podczas operacji i odrzucić je, jeśli operacja się powiedzie, ale mieć je dostępne, jeśli operacja się nie powiedzie. Brak takiej funkcji rejestrowania, posiadanie dobrych dzienników dostępnych, gdy coś się nie powiedzie, może wymagać od aplikacji marnowania dużo czasu na rejestrowanie bezużytecznych danych w 99,99% przypadków, gdy wszystko działa.