This overview summarises how Chronicle Logger modules collaborate to capture, persist, and inspect log events.
It complements the requirement catalogue (CLG-FN-001 through CLG-NF-O-003) and the decision log, offering a shared picture for maintainers and operators.
The repository is split into focused modules that all depend on
logger-core:
-
logger-coresuppliesChronicleLogWriter,ChronicleLogManager, and configuration helpers (see CLG-FN-001). -
Binding modules (
logger-slf4jfor SLF4J 1.7.x,logger-slf4j-2for SLF4J 2.x ServiceProvider,logger-logback,logger-log4j-1,logger-log4j-2,logger-jcl,logger-jul) translate framework-specific APIs into Chronicle writes (CLG-FN-003). -
logger-toolsexposes reusable readers and CLI utilities (CLG-FN-004). -
benchmarkpackages JMH scenarios that observe the performance envelopes (CLG-FN-005).
Configuration enters through properties or native framework settings:
-
Properties loaded by
ChronicleLogManagervia system propertychronicle.logger.propertiesor default class-path locations. -
Binding-specific configuration resolves logger names to queue paths, levels, and wire types.
-
ChronicleLogManagercaches writers per path; reload recreates queues safely (CLG-NF-O-003).
The design enforces explicit queue paths and fail-fast behaviour when storage is not writable (CLG-NF-O-002, CLG-OPS-002).
-
Framework binding receives a log call and checks the requested level against its cached minimum.
-
For SLF4J 2.x, discovery is via
SLF4JServiceProvider; SLF4J 1.x bindings exposeStaticLoggerBinder. Legacy SLF4J callers can be bridged to Log4j1 viaslf4j-reload4jand to Log4j2 vialog4j-slf4j2-impl, keeping old code paths functional while defaulting new usage tologger-slf4j-2. -
When enabled, the binding forwards the event to
ChronicleLogWriter, supplying timestamp, thread name, logger name, message pattern, optional throwable, and argument array (CLG-FN-001). -
ChronicleLogWriterserialises the data into a Chronicle Queue using the configured wire type, avoiding heap allocation on the hot path (CLG-NF-P-001).
Tailers and readers consume the queue either within the same JVM or from external processes.
ChronicleLogReader provides a stable record schema and zero-garbage consumption (CLG-NF-P-003).
ChroniCat and ChroniTail wrap ChronicleLogReader to offer one-shot and streaming inspection of log queues.
They surface warnings on unreadable paths and reuse the same decoding logic used by automated processors, including optional throwable decoding and argument preservation, ensuring identical semantics across CLI and programmatic use (CLG-FN-004).
Metrics for throughput, latency, and allocation are captured through the benchmark suite (CLG-NF-P-001). Future operational metrics follow the Ops obligation in CLG-DOC-001.
-
Provision directories for each Chronicle Queue path during deployment and ensure permissions allow writer processes, satisfying CLG-NF-O-002.
-
Coordinate configuration reloads with deployment tooling so that in-flight writers are recreated without leaks (CLG-NF-O-003).
-
Use the decision log to track future changes that alter queue layout, message schema, or failover strategy (CLG-DOC-001).