-
Notifications
You must be signed in to change notification settings - Fork 3
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.
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.
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.
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.
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 rotation, retention, and directory-size limits. Console output supports colored text and coordinated asynchronous output.
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.
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.
-
logmectlcontrols logging in a running process. -
logmefmtconverts logme text output to JSON/XML. -
logmeobfhelps protect sensitive data in collected logs.
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.
Use logme when you need logging that is fast when quiet, configurable while running, flexible in output, and suitable for real-world diagnostic workflows.
logme — flexible runtime logging system
Home · Getting Started · Architecture · Output · Backends · Configuration
GitHub: https://github.com/efmsoft/logme
- Home
- Getting Started
- Why logme?
- Core Concepts
- Logging Macros
- Fatal Handling
- Crash Logging
- glog Compatibility
- C API
- Choosing Logging Macros
- Function tracing
- Trace Points
- Override Scopes
- Advanced Features
- Collapse Logging
- Feature Map
- Overview
- Console Backend
- Debugger Backend
- File Backend
- File Rotation & Retention
- Buffer Backend
- Ring Buffer Backend
- SharedFile Backend
- Callback Backend
- Windows Event Log Backend
- Custom Backends
- Runtime Control
- Configuration
- Configuration JSON
- Control Server
- Environment Control
- Control Policies
- Trace Points
- Message Filtering