生命周期事件
归档器archivist(Archivist)根据生命周期(lifecycle)事件来获取诊断数据。另外,它还提供了一个读取这些生命周期事件的接口,用于诊断目的。本文档解释了这些事件的内容,以及通过哪个界面才能将其用于诊断。
{#archivist-consumption} <!—
Archivist consumption of lifecycle events
—>
归档器对于生命周期事件的获取
归档器获取来自 v1 和 v2 组件框架的事件。其中主要的不同在于它获取事件时所使用的协议。
下面的图表展示了归档器所关注的三种生命周期事件(已启动(started),功能就绪(capability_ready)和已停止(stopped))的高度概览:
{Components v1}
归档器通过 fuchsia.sys.internal.ComponentEventProvider
获取如下 components v1 中的生命周期事件:
- 已启动(Started):由 appmgr 在组件启动时发送,[启动器][runner](runner)可能仍需启动该组件。该事件在归档器开始侦听事件时,针对当时所有的组件进行合成。
- 已停止(Stopped):由 appmgr 在组件停止时发送。启动器可能仍需拆除(tear down)该组件,但是从框架角度来说,组件已经消失。
- 诊断就绪(Diagnostics ready):由 appmgr 在组件为其
out/diagnostics
目录服务时发送。
{Components v2}
归档器通过 fuchsia.sys2.EventSource
获取如下 components v2 中的生命周期事件:
- 已启动(Started):由组件管理器(component manager)在组件启动时发送,[启动器][runner]可能仍需启动该组件,但是从框架角度来看,组件已经启动。
- 已停止(Stopped):由组件管理器在组件停止时发送。启动器可能仍需拆除该组件,但是从框架角度来看,组件已经消失。
- 已存在(Existing):由组件管理器在归档器开始侦听事件时针对所有正在运行的组件发送。即合成的已启动事件。
- 功能就绪(Capability ready):归档器侦听
out/diagnostics
目录的功能就绪。当组件开始服务该目录时,组件管理器向归档器发送该事件。
读取生命周期事件
生命周期事件能够通过档案访问器(ArchiveAccessor)读取。只有 snapshot
模式受支持。
结果以 vector<FormattedContent>
形式返回,每个条目的变体与请求的 Format
匹配,尽管 JSON 是唯一受支持的格式。
JSON 对象内容
数组中的每个 JSON 对象都是一个事件条目。同档案访问器的其他数据类型一样,每个对象由几个字段(field)组成,尽管元数据和装载的内容与其他源不同。下面是一个 JSON 对象条目的示例:
{
"version": 1,
"moniker": "netstack.cmx",
"data_source": "LifecycleEvent",
"metadata": {
"timestamp": 1234567890,
"lifecycle_event_type": "Started",
"component_url": "fuchsia-pkg://fuchsia.com/netstack#meta/netstack.cmx",
“errors”: []
},
"payload": null,
}
昵称
昵称(moniker)标明与触发事件相关联的组件。
正如在归档器对于生命周期事件的获取中解释的那样,有两个系统都能向归档器提供事件,它们是 appmgr 和组件管理器。昵称反映了这一点。一个简单的区分方法是,如果昵称拥有一个 .cmx
扩展名,那么它是 v1 组件,否则是 v2 组件。
时间戳
时间通过使用内核的单调时钟(纳秒)记录,并且不加修改地以无符号整型传送。在该时间,事件由组件管理器和 appmgr 创建,它们也提供该时间。
生命周期事件类型
下列是生命周期事件的有效类型:
- 诊断就绪
- 已启动
- 已停止
- 运行中
组件 URL
用于启动与该事件相关组件的 URL。
错误
平台在处理该事件时遇到的可选错误(error)向量。通常,生命周期事件不会出现错误,因此大多数情况下它是空的。
装载
生命周期事件的装载(payload)总是空的。其他类型的数据源,诸如日志(log)和审视(inspect),包含装载。要获取更多信息,请参阅[档案访问器文档][archive_accessor]。