DEV.co
Open-Source Observability · MengRao

fmtlog

fmtlog is a high-performance, asynchronous C++ logging library that uses fmt-style formatting with nanosecond-level latency. It supports both single-threaded synchronous and multi-threaded asynchronous modes, with customizable output to files or callbacks.

Source: GitHub — github.com/MengRao/fmtlog
1k
GitHub stars
155
Forks
C++
Primary language
MIT
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
RepositoryMengRao/fmtlog
OwnerMengRao
Primary languageC++
LicenseMIT — OSI-approved
Stars1k
Forks155
Open issues37
Latest releasev2.3.0 (2025-02-13)
Last updated2025-02-13
Sourcehttps://github.com/MengRao/fmtlog

What fmtlog is

fmtlog is a header-only or compiled C++17 library providing asynchronous multi-threaded logging with fmt-compatible formatting, in-order message delivery, pointer argument support (including shared_ptr/unique_ptr), runtime log-level filtering, and configurable flush policies (buffer size, delay, or log level). Dependencies: fmtlib.

Quickstart

Get the fmtlog source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/MengRao/fmtlog.gitcd fmtlog# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Low-latency financial or trading systems

Nanosecond logging latency and asynchronous design minimize impact on time-critical business logic; asynchronous polling allows batched writes without blocking trade execution.

High-throughput backend services

Multi-threaded in-order logging with configurable flush policies suits services handling thousands of requests/sec; custom callback support enables real-time alerting for warnings/errors.

Performance-sensitive embedded or systems programming

Header-only option and pointer-argument support (with lifetime control) reduce allocations and copying; fine-grained compile-time and runtime level control suits resource-constrained deployments.

Implementation considerations

  • Requires explicit fmtlog::poll() calls or startPollingThread(interval); design application polling/flushing strategy upfront to avoid silent log loss.
  • Pointer arguments (raw, shared_ptr, unique_ptr) require careful lifetime management; dangling pointers in async context are undefined behavior.
  • Single polling thread enforced; use external synchronization if multiple threads need to drive log flushing.
  • Default flush delay is 3 seconds; tune setFlushDelay() and setFlushBufSize() for acceptable log staleness in production.
  • Header-only and compiled library versions available; choose based on build system and linking preferences.

When to avoid it — and what to weigh

  • Requires immediate log visibility — Asynchronous design means logs are queued; explicit poll() calls or background thread required. Not suitable if logs must be flushed immediately after every statement.
  • Multi-consumer polling scenario — Library enforces single-threaded polling; if your architecture requires multiple threads calling poll(), you must serialize externally or use an alternative.
  • Color/ANSI terminal output needed — README explicitly states color output is not supported (note: fmtlib supports it, but fmtlog does not).
  • Non-C++17 legacy codebase — Requires C++17 minimum; integration into older C++ projects will require language upgrade.

License & commercial use

MIT License permits commercial and proprietary use with attribution. No copyleft obligations.

MIT is a permissive OSI-approved license. Commercial use, modification, and distribution allowed provided original license and copyright notice are retained. No patent grant or warranty implied; review your own risk tolerance and obtain legal review if required.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationAdequate
License clarityClear
Deployment complexityLow
DEV.co fitGood
Assessment confidenceHigh
Security considerations

No security audit data provided. Asynchronous queue-based design mitigates some DoS vectors from blocking I/O. Pointer argument feature introduces use-after-free risk if caller is careless with object lifetimes; review code using pointer args carefully. Callback mechanism allows external handlers; validate callback implementations. No encryption, authentication, or access control features; treat logs as plaintext.

Alternatives to consider

spdlog

Mature, widely-adopted C++ logging library with similar async support, more color/format options, and extensive ecosystem integrations; fmtlog claims higher throughput in benchmarks (not independently verified).

NanoLog

Focus on ultra-low latency via compile-time format string encoding; fmtlog claims lower latency than NanoLog in benchmarks (not independently verified); less actively maintained.

Boost.Log

Mature, battle-tested C++ logging framework with rich filtering, sinks, and attributes; heavier dependency and more complex API; higher adoption in legacy enterprise codebases.

Software development agency

Build on fmtlog with DEV.co software developers

fmtlog's nanosecond-level latency and asynchronous design make it ideal for performance-critical systems. Review the technical considerations above and test in your environment. Contact Devco for guidance on integration or to assess alternatives suited to your architecture.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

fmtlog FAQ

Does fmtlog block the calling thread?
No; logging call pushes message to a queue (asynchronous) and returns immediately. Formatting and I/O happen in the polling context (background thread or explicit poll() call).
Can I use fmtlog in multiple threads simultaneously?
Yes; multiple threads can log concurrently. However, only one thread must call poll() (or only one startPollingThread can run). Use thread-safe queues; fmtlog guarantees in-order delivery.
What happens if I don't call poll()?
Messages remain queued in memory and are never flushed to file or callbacks. They are lost on shutdown. Use startPollingThread(interval) to automate polling, or call poll() manually in your event loop.
Is fmtlog suitable for embedded systems?
Possibly, if memory for asynchronous queue is acceptable and you control polling timing. Header-only, no dynamic allocation by default, and low-latency design are favorable; test on your target platform.

Custom software development services

From first prototype to production, DEV.co delivers software development services around tools like fmtlog. Our software development agency staffs experienced software developers and web developers for custom software development, web development, integrations, and ongoing support across open-source observability and beyond.

Evaluate fmtlog for Your Low-Latency Logging Needs

fmtlog's nanosecond-level latency and asynchronous design make it ideal for performance-critical systems. Review the technical considerations above and test in your environment. Contact Devco for guidance on integration or to assess alternatives suited to your architecture.