> Which companies use it? I developed Logforth for my cloud database company, ScopeDB [1]. Also, other project like databend [2] use Logforth but it's a fork from an early version.
[1] https://github.com/scopedb/ [2] https://github.com/databendlabs/databend > What are the deployment contexts? Logger of a service? Yes. We use it to capture ScopeDB logs for self-observability. An analogy of Log4j to ES is precise. For local development, we use the stderr appender, and for the online deployment, we're currently adopting the otel appender. Other users have reported usage of the file appender. We also use Logforth with Fastrace [3] to provide full request traces. [3] https://github.com/fast/fastrace > Which appenders/layouts are used most? For local dev and simple deployment, the stderr appender. In the ScopeDB deployment, as described above, the OpenTelemetry appender. I know some users who adopt the file appender. When the stderr appender is used, mainly the text layout [4] is used. When it comes to file appender, both text layout and json layout [5] are common choices. For the otel appender, typically no layout are necessary. But we have a MakeBody trait [6] that can be used in combination with a layout. [4] https://docs.rs/logforth/latest/logforth/layout/struct.TextLayout.html [5] https://docs.rs/logforth/latest/logforth/layout/struct.JsonLayout.html [6] https://docs.rs/logforth-append-opentelemetry/0.3.1/logforth_append_opentelemetry/trait.MakeBody.html The main extension points of Logforth are: * Filters: as the well-known purpose * Appenders: as the well-known purpose * Layout: as the well-known purpose, but Logforth makes layout a possible config of appenders where dedicated appenders would decide whether or not to accept a layout. Because a layout for FastraceEvent or Async appender is non-sense. * Diagnostic: similar to MDC but in a less global-state way. * Trap: Handle errors that should never go to user's call stack. Also, only some appenders would opt in to this feature. Best, tison. Daan Hoogland <[email protected]> 于2025年11月24日周一 14:22写道： > > Hi, Rust is for me just a hobby, though I would like to incorporate it more > into my daily. If this is any barrier for entry add me as reviewer. > > I would love to incorporate a log4rust framework in my toy project > https://github.com/DaanHoogland/mailscrape. > > greeting, > -- > > From: Volkan Yazıcı <[email protected]> > Date: Sunday, 23 November 2025 at 22:33 > To: [email protected] <[email protected]> > Subject: Re: Request for comment: A Rust logging library that is inspired by > Log4j and Logback > > Hey Zili! > > It is good to see you at Logging Services! > > [See my comments inline.] > > On Sat, Nov 22, 2025 at 5:32 PM tison <[email protected]> wrote: > > > It borrows many concepts from log4j and logback, and it is used in > > production handling millions/s of logs, so IMO it's relatively solid. > > > > Would you mind providing a little bit more context about its usage, please? > [I know it is very hard to probe this for F/OSS, but I'd appreciate any > information you can provide on this.] Which companies use it? What are the > deployment contexts? Logger of a service? (Consider an Elasticsearch > cluster logging using Log4j.) Logger of client/server application? > (Consider a custom Spring Boot application.) Which appenders/layouts are > used most? > > "millions/s" of logs? Can you quantify this more in detail, please? > > > > I'm considering moving it to the ASF, but I'd first ask for some > > logging devs review on the APIs if anyone here has some spare time. > > > > I think Logging Services is certainly the right place to collect feedback > on logging system APIs. The community, including maintainers, possesses a > wealth of experience on the subject. IMHO, we can indeed support you there. > > > I'm considering moving it to the ASF > > Would you mind sharing your motivation and expectation for this move, > please? > > Personally, I'd be very happy to see Logging Services supporting the Rust > ecosystem. That being said, AFAICT, 1) we're pretty much understaffed > (Log4j PRs are almost always reviewed by only two people, and > Log4net/Log4cxx need Java maintainers' +1s to cut releases due to > insufficient number of PMC members with .NET/C++ expertise), and 2) none of > the maintainers have serious work experience with Rust. Given the current > status quo, I am concerned about slowing down the Logforth development (due > to ASF release policies taking days to cut a release) and not being able to > contribute to the project meaningfully (due to lack of Rust expertise). I > am curious to hear your thoughts. > > Cheers! > > > Daan Hoogland > Community Lead > s: +44 20 3603 0540 | m: +31 61400 4545 > e: [email protected] | w: www.shapeblue.com | t: @shapeblue > a: 3 London Bridge Street, 3rd floor, News Building, London SE1 9SG UK > > > Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue is a > registered trademark. This email and any attachments to it may be > confidential and are intended solely for the use of the individual to whom it > is addressed. Any views or opinions expressed are solely those of the author > and do not necessarily represent those of Shape Blue Ltd or related > companies. If you are not the intended recipient of this email, you must > neither take any action based upon its contents, nor copy or show it to > anyone. Please contact the sender if you believe you have received this email > in error. > > Find out more about ShapeBlue and our range of CloudStack related services: > > IaaS Cloud Design Build | CloudStack Consulting | CloudStack Software > Engineering > CloudStack Infrastructure Support | CloudStack Bootcamp Training Courses
