+1 Best, Hang
Lari Hotari <[email protected]> 于2026年4月20日周一 23:12写道： > > +1 > > -Lari > > On 2026/04/17 17:48:08 Matteo Merli wrote: > > 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]> > >
