Logs are time-ordered streams of diagnostic data emitted by Fuchsia programs. They most commonly take the form of human-oriented text strings describing changes to state in a subsystem.
See Recording for information about how Fuchsia software writes logs.
See Viewing for information about how to view the recorded logs.
Log records have a few pieces of metadata, mostly self-reported by the programs that generate the logs. At minimum, messages have a timestamp and string contents.
If a message is written to the
LogSink protocol it also has a severity, a PID, a TID, a count of
prior dropped logs, and a list of string tags.
Unless a component's parent realm provides its own
LogSink, diagnostics also includes trusted
SourceIdentity metadata for incoming log connections. This information is not yet exposed to
clients of the logs but resolves limitations of using writer-reported PIDs, TIDs, and tags to make
policy decisions within the diagnostics platform itself.
Currently all log stores are rotated on a first-in-first-out (FIFO) basis, with newer messages overwriting older ones. Messages from any component can roll out messages from any other component. There is currently very limited tracking of when messages are rolled out of their buffers.
There are two in-memory stores for logs on a Fuchsia device:
- The "klog" or debuglog which is a 128kb buffer in the kernel.
- The "syslog" which is a 4MB buffer in the Archivist that runs as a singleton in