Rámec protokolování Java - Java logging framework

A Rámec protokolování Java je počítačový záznam dat balíček pro Java platforma. Tento článek se týká rámců pro obecné protokolování.

Protokolování odkazuje na záznam aktivity aplikací a je běžným problémem vývojových týmů. Rámečky protokolování usnadňují a standardizují proces protokolování pro platformu Java. Zejména poskytují flexibilitu tím, že se vyhýbají explicitnímu výstupu do konzoly (viz Appender níže). Kde se protokoly zapisují, se stává nezávislým na kódu a lze je přizpůsobit za běhu.

Bohužel JDK do svého původního vydání nezahrnoval protokolování, takže v době, kdy bylo přidáno rozhraní Java Logging API, se široce používalo několik dalších rámců protokolování - zejména Protokolování Apache Commons (známé také jako Java Commons Logging nebo JCL) a log4j. To vedlo k problémům při integraci různých knihoven třetích stran (JAR), z nichž každá používá různé rámce protokolování. K vyřešení tohoto problému byly vyvinuty zásuvné rámce (obaly).

Přehled funkcí

Protokolování se obvykle dělí na tři hlavní části: Logger, Formatter a Appender (nebo Handler).

  • Logger je zodpovědný za zachycení zprávy, která má být protokolována, spolu s určitými metadaty a předání do rámce protokolování.
  • Po přijetí zprávy volá framework Formatter se zprávou, která jej naformátuje pro výstup.
  • Rámec poté předá naformátovanou zprávu příslušnému Appender / Handler k dispozici. To může zahrnovat výstup na displej konzoly, zápis na disk, připojení k databázi nebo vygenerování e-mailu.

Jednodušší protokolovací rámce, jako Rámec protokolování Object Guy, zkombinujte logger a appender. To zjednodušuje výchozí operaci, ale je méně konfigurovatelné, zvláště pokud je projekt přesunut napříč prostředími.

Logger

Logger je objekt, který umožňuje aplikaci protokolovat bez ohledu na to, kam je výstup odeslán / uložen. Aplikace zaznamená zprávu předáním objektu nebo objektu a výjimka s volitelnou úrovní závažnosti pro objekt loggeru pod daným jménem / identifikátorem.

název

Logger má jméno. Název je obvykle strukturován hierarchicky, přičemž úrovně oddělují tečky (.). Běžným schématem je použití názvu třídy nebo balíčku, který provádí protokolování. Oba log4j a protokolování Java API podpora definování obslužných programů výše v hierarchii.

Například záznamník může mít název „com.sun.some.UsefulClass". Obslužnou rutinu lze definovat pro kteroukoli z následujících možností:

  • com
  • com. slunce
  • com.sun.some
  • com.sun.some.UsefulClass

Pokud je někde v tomto zásobníku definován obslužný program, může dojít k protokolování. Například zpráva přihlášená k com.sun.some.UsefulClass Logger, může být napsán com. slunce psovod. Obvykle existuje globální obslužný program, který přijímá a zpracovává zprávy generované jakýmkoli záznamníkem.

Úroveň závažnosti

Zpráva je zaznamenána na určité úrovni. Zkopírovány jsou názvy běžné úrovně Protokolování Apache Commons (ačkoli rozhraní Java Logging API definuje různé názvy úrovní):

Společné úrovně
ÚroveňPopis
FATÁLNÍZávažné chyby, které způsobují předčasné ukončení. Očekávejte, že budou okamžitě viditelné na stavové konzole.
CHYBADalší runtime chyby nebo neočekávané podmínky. Očekávejte, že budou okamžitě viditelné na stavové konzole.
VAROVÁNÍPoužívání zastaralých API, špatné používání API, „téměř“ chyby, další běhové situace, které jsou nežádoucí nebo neočekávané, ale ne nutně „špatné“. Očekávejte, že budou okamžitě viditelné na stavové konzole.
INFOZajímavé runtime události (spuštění / vypnutí). Očekávejte, že budou okamžitě viditelné na konzole, proto buďte konzervativní a udržujte je na minimu.
LADITpodrobné informace o průtoku systémem. Očekávejte, že se budou zapisovat pouze do protokolů.
STOPApodrobnější informace. Očekávejte, že se budou zapisovat pouze do protokolů.

Rámec protokolování udržuje aktuální úroveň protokolování pro každý protokolovač. Úroveň protokolování lze nastavit víceméně omezující. Například pokud je úroveň protokolování nastavena na „VAROVÁNÍ“, budou protokolovány všechny zprávy této úrovně nebo vyšší: CHYBA a FATÁLNÍ.

Úrovně závažnosti lze přiřadit protokolovačům i připojovacím jednotkám. Aby mohl být výstup generován, musí být pro danou úroveň závažnosti povoleny obě možnosti. Takže protokolovač povolený pro výstup ladění nebude generovat výstup, pokud obslužný program, který dostane zprávu, není také povolen pro ladění.

Filtry

Filtry způsobí, že událost protokolu bude ignorována nebo zaznamenána. Nejběžněji používaným filtrem je úroveň protokolování popsaná v předchozí části. Protokolovací rámce, jako jsou Log4j 2 a SLF4J, také poskytují značky, které po připojení k události protokolu lze také použít k filtrování. Filtry lze také použít k přijetí nebo odepření událostí protokolu na základě vyvolávaných výjimek, dat v rámci zprávy protokolu, dat v ThreadLocal, která jsou vystavena prostřednictvím rozhraní API pro protokolování, nebo různých dalších metod.

Formátoři, rozvržení nebo renderery

Formatter je objekt, který formátuje daný objekt. Většinou to spočívá v převzetí binárního objektu a jeho převodu na řetězcovou reprezentaci. Každý rámec definuje výchozí výstupní formát, který lze v případě potřeby přepsat.

Dodatky nebo manipulátory

Appenders poslouchat zprávy na nebo nad stanovenou minimální úrovní závažnosti. Appender vezme zprávu, která je předána, a odpovídajícím způsobem ji zveřejní. Dispozice zpráv zahrnují:

  • na konzole
  • zapisovat do souboru nebo syslogu
  • připojit k databázové tabulce
  • distribuovat prostřednictvím Java Messaging Services
  • poslat e-mailem
  • zapisovat do zásuvky
  • zahodit do „bit-bucket“ (/ dev / null)

Porovnání funkcí

Tabulka 1 - Vlastnosti
RámecTypPodporované úrovně protokoluStandardní dodatkyKomentářeCena / licence
Log4JRámec protokolováníFATÁLNÍ CHYBA VAROVÁNÍ INFORMACE ODSTRANIT TRACEPříliš mnoho na seznam: Viz Dokumentace přihlašovateleŠiroce se používá v mnoha projektech a platformách. Log4j 1 byl v roce 2015 prohlášen za „End of Life“ a byl nahrazen Log4j 2, který poskytuje API, které lze použít s jinými implementacemi protokolování i implementací tohoto API.
Licence Apache, verze 2.0
Java Logování APIRámec protokolováníZÁVAŽNÉ VAROVÁNÍ INFO KONFIGUJTE FINE FINER FINESTVýchozí Java Virtual Machine (JVM) od společnosti Sun má následující: ConsoleHandler, FileHandler, SocketHandler, MemoryHandlerDodává se s JRE
TinylogRámec protokolováníCHYBA VAROVÁNÍ INFO ODSTRANIT TRASUConsoleWriter, FileWriter, LogcatWriter, JdbcWriter, RollingFileWriter, SharedFileWriter a nula (zahodí všechny položky protokolu) [1]Licence Apache, verze 2.0
LogbackRámec protokolováníCHYBA VAROVÁNÍ INFO ODSTRANIT TRACEPříliš mnoho na seznam: viz Appender JavaDocVyvinuto jako náhrada za log4j s mnoha vylepšeními. Používá se mnoha projekty, obvykle například za slf4j Akka, Apache Camel, Apache Cocoon, Umělé, Gradle, Lift Framework, Hrajte Framework, Scalatra, SonarQube, Jarní bota, ...LGPL, Verze 2.1
Protokolování Apache CommonsProtahovací obálkaFATÁLNÍ CHYBA VAROVÁNÍ INFORMACE ODSTRANIT TRACEZávisí na základním rámciŠiroce používaný, často ve spojení s log4jLicence Apache, verze 2.0
SLF4JProtahovací obálkaCHYBA VAROVÁNÍ INFO ODSTRAŇOVÁNÍ KÓDŮZávisí na základní architektuře, kterou lze připojit. Poskytuje API kompatibilní podložky pro protokolovací balíčky JCL, JDK a log4j. Může také použít kterýkoli z nich ke generování výstupu. Výchozí nastavení použití Logback pro výstup, pokud je k dispozici.Široce se používá v mnoha projektech a platformách, často s implementací Logback.Licence MIT

Úvahy

JCL a Log4j jsou velmi běžné jednoduše proto, že jsou tu tak dlouho a jsou jedinou volbou na dlouhou dobu. Flexibilita slf4j (pomocí Logback vespod) z něj učinila oblíbenou volbu.

SLF4J je sada obálek (nebo překrytí) protokolování, které mu umožňují napodobit jakýkoli z ostatních rámců. Do aplikace tak lze začlenit více knihoven třetích stran, bez ohledu na to, jaký rámec protokolování si každý zvolil. Veškerý výstup protokolování se však generuje standardním způsobem, obvykle pomocí protokolu Logback.

Log4j 2 poskytuje jak API, tak implementaci. API lze směrovat na jiné implementace protokolování ekvivalentní tomu, jak funguje SLF4J. Na rozdíl od SLF4J protokol Log4j 2 API protokoluje zprávu[2] objekty místo řetězců pro větší flexibilitu a podporuje také výrazy Java Lambda.[3]

JCL není ve skutečnosti protokolovací rámec, ale obal pro jeden. Jako takový vyžaduje rámec protokolování pod ním, i když může výchozí použití jeho vlastní SimpleLog záznamník.

JCL, SLF4J a API Log4j 2 jsou užitečné při vývoji opakovaně použitelných knihoven, které potřebují zapisovat na jakýkoli podkladový systém protokolování, který aplikace používá. To také poskytuje flexibilitu v heterogenních prostředích, kde je pravděpodobné, že se změní rámec protokolování, i když ve většině případů, jakmile byl zvolen rámec protokolování, není potřeba jej po dobu životnosti projektu měnit. SLF4J a Log4j 2 těží z toho, že jsou novější, a vycházejí z poznatků získaných ze starších rámců. Kromě toho má JCL známé problémy s zavaděči tříd při určování toho, jakou knihovnu protokolování má zabalit [4] který nyní nahradil JCL.[5]

Rozhraní Java Logging API je dodáváno s prostředím Java. Ačkoli je API technicky oddělené od výchozí implementace poskytované v Javě, může být jeho nahrazení alternativní implementací náročné, takže mnoho vývojářů zaměňuje tuto implementaci s Java Logging API. Konfigurace se provádí pouze pomocí externích souborů, které se za chodu snadno nemění (ostatní rámce podporují programovou konfiguraci). Výchozí implementace poskytuje pouze několik manipulátorů a formátovačů, což znamená, že většina uživatelů bude muset napsat vlastní.[6]

Viz také

Reference

  1. ^ "Uživatelský manuál tinylog".
  2. ^ Zprávy API Log4j2
  3. ^ Podpora Java 8 Lambda pro líné protokolování
  4. ^ Vyhněte se Commons Logování
  5. ^ Přehled protokolování jara
  6. ^ Přehled java.util.logging

externí odkazy