Using the Log service¶
The Log service captures Kanzi Engine log messages into an in-memory ring buffer. You can view the captured log entries through the console, display them on-screen using the BasicUI overlay, access them programmatically through the API, or export them as part of a profiling trace.
Platform support¶
The Log service builds from sources on all known Kanzi target platforms.
How the Log service works¶
The Log service hooks into the Kanzi logging system by registering a custom logger in the Kanzi logger chain. Once registered, the logger automatically receives all Kanzi log messages without any additional application code.
Each log entry is formatted as a string containing:
Timestamp – Date and time with millisecond precision (for example,
2025-02-10 14:32:45.123)Level – The log level (for example, Info, Warning, Error)
Category – The logging category (for example, Generic, Rendering)
Source location – File name and line number (included only for Error level)
Message – The log message text
Example log entry:
2025-02-10 14:32:45.123 Info:Generic> Application initialized
The log buffer operates as a ring buffer with a configurable maximum size (default: 100 entries). When the buffer is full, the oldest entry is removed to make room for new entries.
Viewing log entries¶
Use the
loginfocommand from the local or remote console to view the buffer contents.Use the
basicuicommand to switch to the Log screen for on-screen display of log entries.Log entries are also included in the trace output as instant events. See Using the Profiling Trace service.
Trace integration¶
The Log service registers a parallel profiling logger that captures the same log messages with nanosecond-precision timestamps.
These samples are exported to the trace file as instant events on a dedicated KanziLog thread, allowing log messages to be correlated with other profiling data in the Perfetto trace viewer.
The Log service defines its own profiling category (PROFILING_LOGGING) which is always enabled at compile time, independent of the build configuration of the Kanzi Engine.
This means log entries are included in the trace in all build configurations (Debug, Release, and Profiling).
Accessing the log buffer from code¶
You can access the log buffer programmatically through the Log service API:
KanziMonitorModule* module = getKanziMonitorModule(domain);
LogService* logService = module->getLogService();
KanziMonitorLogger* logger = logService->getLogger();
// Access the log entries.
std::list<std::string>& entries = logger->getLog();
// Query or change the buffer size.
size_t maxEntries = logger->getMaxEntries();
logger->setMaxEntries(200);
// Clear the buffer.
logger->clearLog();
Using diagnostics¶
The logdiag command provides diagnostic information about the KanziLog trace pipeline. This is useful for troubleshooting when log entries are missing from the trace output.
logdiag
Example output:
=== KanziLog Trace Diagnostics ===
PROFILING_LOGGING compile-time enabled: yes
PROFILING_LOGGING runtime enabled: yes
ProfilingLogger alive: yes
ProfilingLogger write count: 42
LoggerProfiler sample count: 42
General collection tasks: 2
[0] registry_default_profiling
[1] registry_logging_profiling
Logging storage registered: yes
The diagnostics report:
Whether the
PROFILING_LOGGINGprofiling category is enabled at compile time and runtime.Whether the ProfilingLogger is alive and how many log messages it captured.
The number of profiling samples collected by the LoggerProfiler.
The registered general collection tasks and whether the logging storage is present.
On some platforms (for example, Android application framework), the ProfilingLogger created during static initialization can be destroyed before the plugin initializes at runtime. The Log service detects this condition and automatically re-creates the ProfilingLogger during initialization, so that runtime log messages are captured in the trace.
Available commands¶
Command |
Description |
|---|---|
|
Shows recent log information. |
|
Shows KanziLog trace pipeline diagnostics. |
Available UI screens¶
The Log service registers a BasicUI screen with the UI service:
Log screen – Displays the contents of the log buffer as an on-screen text overlay. Use the
basicuicommand to switch to this screen.