歸因 LogSink 連線

當 Fuchsia 元件想要寫入記錄時，必須取得自身環境中的 fuchsia.logger.LogSink 連線，通常由封存的執行個體提供。

典型的 Fuchsia 服務連線是匿名的，因此伺服器和用戶端沒有彼此相關的識別資訊。用戶端只會在其命名空間中看見服務 (例如 /svc/fuchsia.logger.LogSink)，而伺服器會向傳入的命名空間顯示匿名的 Open() 要求。

同時，記錄的來源也很重要，因為值得信賴的來源中繼資料能更有效地監控、儲存、查詢及呈現記錄。系統會利用名為「歸因記錄」的功能來解決這個問題，該功能可識別傳入 LogSink 連線的來源。

元件管理服務：CapabilityRequested 事件

Archivist 的資訊清單 expose fuchsia.logger.LogSink 與其他服務功能相同，但它也是 use 架構中的事件，並繫結至其命名空間中的服務：

{
    event: "capability_requested",
    from: "framework",
    filter: { name: "fuchsia.logger.LogSink" },
},
{
    event_stream: "EventStream",
    subscriptions: [
        {
            event: "capability_requested",
            mode: "async",
        }
    ],
},

這會導致元件管理服務將傳入要求從預設的 fuchsia.io 命名空間通訊協定重新導向至 fuchsia.sys2.EventStream 通訊協定。Archivist 在此通訊協定上接收事件 (與 LogConnectionListener 類似)，會從元件管理服務傳送的 ComponentDescriptor 擷取歸因中繼資料，以及 LogSink 管道的控制代碼。描述元中包含的圖例會在功能轉送期間建構。

為 LogSink 設定 capability_requested 事件不會影響能力轉送功能，只會影響將管道以事件的形式傳送至 Archivist，而不會以 Open() 形式傳遞。也就是說，傳遞已歸因的 LogSink 的 CML 在其他元件拓撲中保持不變。

詳情請參閱「通訊協定開放生命週期」和「事件說明文件」。