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.
See Attributing LogSink connections for information about how Fuchsia identifies the producer of each log message.
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 used to provide a default tag for messages without tags.
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
sys.
Note: If you can't find some logs, see Recording logs to find out which of these buffers is the intended point of transit for your message. See Viewing logs once you know the location.
The feedback data component maintains a persistent disk store of messages
from the previous boot. These messages appear when running fx snapshot.