Hi all,

I'd like to open discussion on BP-69: Adopt slog for structured logging.

 * Proposal (PR): https://github.com/apache/bookkeeper/pull/4751
 * Tracking issue: https://github.com/apache/bookkeeper/issues/4750

BookKeeper currently uses SLF4J with unstructured {} format strings.
Every log site restates identity context inline (ledgerId, bookieId,
entryId, ...), there's no consistent attribute naming, and hot paths
are sprinkled with isDebugEnabled() guards to avoid
String.format/toString cost. This is painful to query in modern log
backends (Loki, Elastic, Splunk, CloudWatch, etc.) and makes
cross-project correlation with Pulsar essentially impossible.

The proposal is to adopt the slog library
(https://github.com/merlimat/slog) for structured logging across the
codebase, mirroring the decision Apache Pulsar made in PIP-467
(https://github.com/apache/pulsar/blob/master/pip/pip-467.md), whose
migration is complete. SLF4J stays on the classpath as the rendering
backend; no log-config change is required to upgrade. Migration is
phased one module per commit, each independently mergeable.

Two additional items in scope:

 1. Cross-boundary logger context through the client API. Adds
withLoggerContext(Map<String, Object>) to CreateBuilder / OpenBuilder
/ DeleteBuilder. When set, the caller's attributes (e.g. Pulsar's
managedLedger=<topic>) are bound to the resulting
WriteHandle/ReadHandle's logger, so every BookKeeper client log line
on behalf of that handle automatically carries them — without
BookKeeper knowing about Pulsar concepts. The parameter is a plain
Map, so clients are not forced to take a slog dependency.

 2. Retire bookkeeper-slogger. The existing module is @Unstable, used
by only 5 files in bookkeeper-server, and missing features (no
debug/trace levels, no zero-overhead disabled levels, no composable
context). Nothing else inside or outside the project depends on it.

Not in scope: wire protocol, binary formats, metadata formats,
metrics, and CLI are untouched. SLF4J is not being deprecated.

Looking forward to feedback — particularly on the client API shape
(withLoggerContext on the three builders) and on retiring
bookkeeper-slogger.

Thanks,
Matteo

--
Matteo Merli
<[email protected]>

Reply via email to