+1 (non-binding) Thanks, Zixuan
Matteo Merli <[email protected]> 于2026年4月18日周六 01:48写道： > 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]> >
