When a Fuchsia component wishes to write logs, it must obtain a connection to a fuchsia.logger.LogSink
in its environment, typically provided by an instance of the Archivist.
Typical Fuchsia service connections are anonymous such that the server and client have no identifying information about each other. The client only sees the service in their namespace, e.g. /svc/fuchsia.logger.LogSink
, and the server sees an anonymous Open()
request to their incoming namespace.
At the same time, it's important to know from where logs come, as trustworthy provenance metadata enables better monitoring, storage, querying, and presentation of logs. The system solves this with a feature called “attributed logging” which identifies the source of an incoming LogSink
connection.
Archivist serves the fuchsia.sys.internal/LogConnectionListener
to receive LogSink
connections along with fuchsia.sys.internal/SourceIdentity
metadata.
LogConnectionListener
for a realmArchivist connects to fuchsia.sys.internal/LogConnector
, which is provided by appmgr. Archivist then calls TakeLogConnectionListener()
to retrieve the server end of a channel implementing fuchsia.sys.internal/LogConnectionListener
for the realm where the connection was made. This behavior can be disabled by running Archivist with the --disable-log-connector
flag.
In production, Archivist runs “above” appmgr and connects via the sys
realm, taking the LogConnectionListener
for appmgr's root realm and capturing all LogSink
connections.
appmgr does not provide an attributed LogSink
to realms where the caller has explicitly provided its own entry for fuchsia.logger.LogSink
, allowing test environments to intercept and read their own logs.
When appmgr launches a component, it instantiates a ServiceProviderDirImpl, populating it with services entries for the component‘s namespace. Each directory is created by taking the services of the parent/enclosing environment and filtering them down to entries listed in the component’s .cmx
file under sandbox.services
.
If a component lists fuchsia.logger.LogSink
in its manifest, its environment does not provide an implementation, and appmgr has a LogConnectionListener
initialized for the realm, an “attributed LogSink
” is provided in the component‘s namespace. From the component’s perspective, it behaves just as a normal LogSink
instance. When a connection is made to it, the sent channel is forwarded to the corresponding LogConnectionListener
along with the SourceIdentity
.
Archivist's manifest expose
s fuchsia.logger.LogSink
just like other service capabilities, but it also use
s an event from the framework, binding it to a service in its namespace:
{ event: "capability_requested", from: "framework", filter: { name: "fuchsia.logger.LogSink" }, }, { event_stream: [ "capability_requested" ], path: "/svc/fuchsia.sys2.EventStream", },
This causes Component Manager to redirect incoming requests from the default fuchsia.io
namespace protocol to the fuchsia.sys2.EventStream
protocol. Archivist receives Events on this protocol similarly to LogConnectionListener
, retrieving attribution metadata from the ComponentDescriptor sent by Component Manager along with the LogSink
channel's handle. The moniker included in the descriptor is constructed during capability routing.
Configuring a capability_requested
event for LogSink
does not affect capability routing itself, only the delivery of the channel to the Archivist as an Event instead of as an Open(). This means that the CML for passing the attributed LogSink
remains the same for the rest of the component topology.
For more information, see Life of a protocol open and the events documentation.