Why logme

Why logme?

logme is designed for applications where logging must remain useful in production, not only during local debugging. The main goal is to keep detailed diagnostics available while avoiding unnecessary cost when logging is disabled, filtered, or routed away.

Runtime diagnostics instead of startup-only configuration

Many logging libraries are configured once at process startup. logme treats logging as a runtime system. Channels, levels, routes, backends, and output formats can be changed while the application is running.

The same control command language can also be used during startup through explicit environment control. This lets an application opt in to diagnostic overrides such as LOGME_CONTROL="level --channel net debug" without making environment variables a hidden global configuration source.

This is useful for long-running services, agents, proxies, daemons, and desktop applications where restarting the process just to collect more diagnostics is inconvenient or impossible.

Low overhead by design

logme tries to avoid doing work that will not produce output. Disabled and filtered messages are rejected early. Formatting and argument evaluation are skipped whenever possible.

When messages are written, logme reuses per-call-site context and keeps the hot path small. This is especially important for code that keeps detailed logging compiled in but normally runs with most diagnostics disabled.

Flexible output model

A log message is not tied to a single destination. Messages are routed through channels and backends, so the same application can write to console, files, debugger output, or custom backends.

File logging supports production-oriented behavior such as daily rotation, max-size handling, part retention, and directory-size limits. Console output supports colored text and coordinated asynchronous output. Memory and callback backends cover diagnostics, tests, recent-history capture, and application-owned delivery paths.

Text logs and structured logs

logme can produce readable text logs for humans and structured JSON/XML output for tools. Existing text logs can also be converted later with logmefmt, including finalized JSON/XML documents suitable for ingestion or archival.

This keeps everyday logs readable while still allowing automated processing when needed.

Built-in diagnostic tools

The library is accompanied by command-line tools for runtime control, format conversion, and log obfuscation. These tools are part of the same diagnostic model rather than separate afterthoughts.

• logmectl controls logging in a running process.
• logmeweb provides a browser UI for channels, trace points, log files, and manual control commands.
• logmefmt converts logme text output to JSON/XML.
• logmeobf helps protect sensitive data in collected logs.

Practical C and C++ usage

logme supports C and C++ code through the same public header. It provides printf-style macros, stream-style output, and format-string support through std::format or fmt when enabled.

This allows using one logging library across mixed C/C++ codebases without forcing a single formatting style everywhere.

In short

Use logme when you need logging that is fast when quiet, configurable while running, flexible in output, and suitable for real-world diagnostic workflows.