docs/development/logs/concepts.md - fuchsia - Git at Google

 # Logs

 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.

 ## Contents

 [Log records][LogMessage] 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.

 ## Storage

 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.

 ### Volatile

 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.

 ### Persistent

 The [feedback data] component maintains a [persistent disk store] of messages from the previous
 boot. These messages appear when running [`fx bugreport`].

 [LogMessage]: https://fuchsia.dev/reference/fidl/fuchsia.logger#LogMessage
 [`LogSink`]: https://fuchsia.dev/reference/fidl/fuchsia.logger#LogSink
 [SourceIdentity]: https://fuchsia.dev/reference/fidl/fuchsia.sys.internal#SourceIdentity
 [debuglog]: /docs/reference/kernel_objects/debuglog.md
 [128kb buffer in the kernel]: /zircon/kernel/lib/debuglog/debuglog.cc
 [4MB buffer in the archivist]: /src/diagnostics/archivist/src/logs.rs
 [Recording]: /docs/development/logs/recording.md
 [Viewing]: /docs/development/logs/viewing.md
 [feedback data]: /src/developer/forensics/feedback_data
 [persistent disk store]: /src/developer/forensics/feedback_data/system_log_recorder/system_log_recorder.h
 [`fx bugreport`]: /src/developer/forensics/bugreport/README.md
	# Logs

	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.

	## Contents

	[Log records][LogMessage] 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.

	## Storage

	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.

	### Volatile

	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.

	### Persistent

	The [feedback data] component maintains a [persistent disk store] of messages from the previous
	boot. These messages appear when running [`fx bugreport`].

	[LogMessage]: https://fuchsia.dev/reference/fidl/fuchsia.logger#LogMessage
	[`LogSink`]: https://fuchsia.dev/reference/fidl/fuchsia.logger#LogSink
	[SourceIdentity]: https://fuchsia.dev/reference/fidl/fuchsia.sys.internal#SourceIdentity
	[debuglog]: /docs/reference/kernel_objects/debuglog.md
	[128kb buffer in the kernel]: /zircon/kernel/lib/debuglog/debuglog.cc
	[4MB buffer in the archivist]: /src/diagnostics/archivist/src/logs.rs
	[Recording]: /docs/development/logs/recording.md
	[Viewing]: /docs/development/logs/viewing.md
	[feedback data]: /src/developer/forensics/feedback_data
	[persistent disk store]: /src/developer/forensics/feedback_data/system_log_recorder/system_log_recorder.h
	[`fx bugreport`]: /src/developer/forensics/bugreport/README.md