診斷

Fuchsia 採用多種觀測系統，方便您執行診斷 例如：

記錄

記錄是 Fuchsia 程式發出的診斷資料串流，並按時間排序。通常以低頻率的人導向文字字串形式呈現 說明子系統中的狀態變更。

目錄

記錄包含多個中繼資料片段，這些片段大多是由產生特定記錄的每個元件自行回報。記錄訊息至少會包含 時間戳記和字串內容

此外，如果記錄訊息是使用LogSink 其中包含嚴重程度、PID、TID、 捨棄的記錄檔和字串標記清單並非所有中繼資料都需要，但支援的程式庫會確保在透過 LogSink 取得的通訊端上寫入記錄時，每個欄位都有值。

Archivist 會在元件寫入套接字的資料中插入其他中繼資料。如要進一步瞭解 Archivist 提供 Fuchsia 裝置記錄，詳情請參閱 記錄記錄。

儲存空間

目前，所有記錄儲存空間都會以先進先出 (FIFO) 的方式輪替，較新的訊息會覆寫較舊的訊息。任何元件傳送的訊息，都可以推送其他元件傳送的訊息。

Fuchsia 中的記錄可儲存在下列類型的記憶體中：

易變

Fuchsia 裝置上有兩個記錄記憶體內儲存庫：

使用記錄時，請務必瞭解 Fuchsia 如何寫入記錄，以便您更容易找出記錄可能儲存的位置，因為這會說明哪些緩衝區是訊息的傳輸目的地。

持續

意見回饋資料元件會維護系統上次開機時的訊息的 persistent_disk_store。

當您指定 Fuchsia 裝置為目標時， ffx target snapshot。

使用記錄檔

如要開始使用記錄功能，建議您：

檢查

檢查功能可讓元件在執行階段揭露其狀態的結構化階層資訊。元件會使用檢查格式主控已對應的虛擬記憶體物件 (VMO)，以公開包含此內部狀態的檢查階層。注意：如要進一步瞭解檢查 VMO 檔案格式，請參閱「檢查 VMO 檔案格式」。

使用檢查功能

如要開始使用檢查工具，建議您：

檔案管理員

Archivist 會擷取 Inspect 和 Fuchsia 記錄中的資料，並透過 fuchsia.diagnostics/ArchiveAccessor 通訊協定提供這些資料。

Archivist 會透過 fuchsia.component.EventStream 擷取元件架構中的生命週期事件：

  • 要求的功能：Archivist 會接收 Capability requested 事件，以便連線至 fuchsia.logger.LogSink 和 fuchsia.inspect.InspectSink，進而歸因於檢查和記錄。

CapabilityRequested 事件

CapabilityRequested 事件是提供記錄和檢查的機制 加上路徑名稱和元件網址等歸因中繼資料

《Archivist-manifest》expose：fuchsia.logger.LogSink 和其他方式一樣 開發通訊協定能力，也能use擷取架構中的事件 新增至其命名空間中的通訊協定

如要進一步瞭解這項功能的運作方式，請查看 Archivist 的 CML 檔案：

// Copyright 2022 The Fuchsia Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
// This shard is meant to contain stuff that is meant to be shared across all flavors of the
// archivist.
{
    include: [ "//src/diagnostics/archivist/meta/config.shard.cml" ],
    program: {
        runner: "elf",
        lifecycle: { stop_event: "notify" },
    },
    capabilities: [
        {
            protocol: [
                "fuchsia.diagnostics.ArchiveAccessor",
                "fuchsia.diagnostics.host.ArchiveAccessor",
                "fuchsia.diagnostics.LogSettings",
                "fuchsia.inspect.InspectSink",
                "fuchsia.logger.Log",
                "fuchsia.logger.LogSink",
            ],
        },
    ],
    use: [
        {
            event_stream: [ "capability_requested" ],
            from: "parent",
            path: "/events/log_sink_requested_event_stream",
            filter: { name: "fuchsia.logger.LogSink" },
        },
        {
            event_stream: [ "capability_requested" ],
            from: "parent",
            path: "/events/inspect_sink_requested_event_stream",
            filter: { name: "fuchsia.inspect.InspectSink" },
        },
        {
            protocol: [ "fuchsia.tracing.provider.Registry" ],
            availability: "optional",
        },
        {
            protocol: [ "fuchsia.inspect.InspectSink" ],
            from: "self",
        },
    ],
    expose: [
        {
            protocol: [
                "fuchsia.diagnostics.ArchiveAccessor",
                "fuchsia.diagnostics.host.ArchiveAccessor",
                "fuchsia.diagnostics.LogSettings",
                "fuchsia.inspect.InspectSink",
                "fuchsia.logger.Log",
                "fuchsia.logger.LogSink",
            ],
            from: "self",
        },
    ],
}

這會導致元件管理工具將傳入的要求從預設 fuchsia.io 命名空間通訊協定重新導向至 fuchsia.component.EventStream 通訊協定。Archivist 會接收這個通訊協定的事件，從 Component Manager 傳送的 EventHeader 和 LogSink 管道的句柄一併擷取歸因中繼資料。一探究竟 系統會透過事件標頭建構描述元的其他部分。

為 LogSink 設定 capability_requested 事件不會影響能力路由本身，只會影響將頻道以事件而非 Open() 的形式傳送至 Archivist。也就是說，傳遞已指派 LogSink 的 CML 會與其他元件拓樸相同。詳情請參閱「通訊協定開啟的生命週期」和事件說明文件。

將 LogSink 連線歸因

當 Fuchsia 元件想要寫入記錄時，必須連線至 fuchsia.logger.LogSink，位於其傳入目錄中 通常是由阿奇維斯的實例提供

一般的 Fuchsia 服務連線是匿名的，因此伺服器和 則用戶端不會有彼此的識別資訊。用戶端只會看到其命名空間中的服務 (例如 /svc/fuchsia.logger.LogSink)，而伺服器會看到傳入命名空間的匿名 Open() 要求。

歸因記錄可提供可靠的歸因中繼資料，讓您更有效地監控、儲存、查詢及呈現記錄。歸因 metadata 欄位會識別傳入 LogSink 連線的來源， 才會透過 CapabilityRequested 事件完成。