RFC-0035：自动流跟踪

RFC-0035：自动流跟踪
状态已拒绝
领域
  • FIDL
说明

通过向我们的 FIDL 绑定添加跟踪事件，可实现跨 Fuchsia 流程的端到端流程，而无需手动处理自定义 ID。
作者
提交日期（年-月-日）2019-02-28
审核日期（年-月-日）2019-02-28

修改此 RFC

修改 RFC 元数据

遭拒原因

未收到响应（无论是活动事件还是“即发即弃”的通话）的消息会带有 交易 ID 设置为 0，因此无法使用 建议的方案

有些使用 zx_channel_call()，它会将 事务 ID，并等待回复。 （此模式允许并发调用方依赖于内核同步， 避免在分配事务 ID 时锁定用户空间。） 同样，建议的方案也无法区分这两种环境。

内核跟踪支持应该会提供 Google Cloud 审核，并且优先考虑改进该机制， 而不是在 FIDL 绑定中推送。

最后，按照 SDK 依赖项取舍顺序，使用 FIDL 和 FIDL 由于在 Fuchsia 上广泛使用 FIDL，因此绑定都非常接近顶部。 因此，在绑定中添加遥测和指标会导致 这对我们来说并不安全。 一些构建和选择启用方面的欺骗行为是可以想象的， 未来提案的一部分

摘要

向我们的 FIDL 绑定添加跟踪事件可实现 在 Fuchsia 上处理流程，而无需手动操作自定义 ID。

设计初衷

有很多种可跨流程实现流程事件的技巧 紫红色的边界。 我们能够以一种不会使 API 复杂化的方式实现其中的大多数自动化操作 并且需要的手动工作更少。

设计

Fuchsia FIDL 函数的标准属性，添加了流开始/结束 事件映射到各自生成的绑定

该属性设置跟踪的类别，并使用协议 函数。 目前，在 Fuchsia 上跟踪仅支持一个类别，因此虽然 属性可能包含 N 个类别，但我们预计只能选择一个类别 并将使用列表中的第一个。

protocol Example {
    [Trace = "CATEGORY"]
    ExampleFn(bool test) -> (bool status);
};

唯一的跨进程 ID 是序数 ID、交易 ID（包含 和传输机制 ID（对于 Zircon） channels：发送进程信道句柄的 koid，以及相关的 （接收进程句柄的 koid）与 非加密哈希

通过 zx 通道使用 FIDL 的稳定跟踪记录 ID 示例

我们建议结合使用以下标识符：

这三种标识符应当如何组合，尽量减少 跟踪记录 ID 冲突，优先级如下：

  1. 两个不同消息之间，顺序相同， 同一个客户端和服务器；
  2. 两个不同邮件（具有不同的序数）以及 同一个客户端和服务器；
  3. 两个不同邮件（具有不同的序数）以及 不同的客户端和服务器。

目前，Koid 分配大多是依序进行的。 因此，最低位数的熵将高于 最高位。 同样，交易 ID 也按顺序分配，因此可提供 也就是最低位的熵。 无论最高位如何，方法序数都会经过加密哈希处理 留待系统使用，那么可以放心地假设所有位都 相同的熵。

因此，在当前条件下，合理的算法为 OR：

  • koid & OxFFFF << 48
  • ordinal & 0xFFFFFFFF << 16
  • transaction ID & 0xFF << 0

轨迹时长也会在 FIDL 绑定的接收端开始。 对于 C++/Rust 等语言，这使用 RAII 限定作用域，并允许 事件与另一个用户流事件进行拼接

工效学设计

这让我们的跟踪系统更易于使用，对我们来说 以及基础架构

文档和示例

应更新文档，以说明如何添加跟踪记录（如概述 ）。

向后兼容性

此变更与 API 和 ABI 兼容。

性能

停用跟踪类别时开销较小， 每个 dje@google.com 测试（在 NUC 上）所需的时间超过 5 纳秒。 我们还可以从 IR 中删除跟踪注释，假设 。

安全

无安全方面的影响。

缺点、替代方案和未知问题

替代方案

内核跟踪记录机制

在通道读取和通道写入时利用现有的 ktrace 流事件。

如果没有此功能，则可以尝试 只需使用底层服务器上现有的 ktrace 流事件 通道读取和写入。 不过，这是不希望的，因为这些信道对所有 FIDL 都是通用的， 接口，这意味着只能指定一个类别。 也就是说，用户必须启用 通道读取和通道写入类别，这意味着所有通道读取 以及写入事件（而不仅仅是用于 FIDL 的事件） 接口）。 这会导致跟踪记录查看器输出更难读取，产生不必要的 ktrace 缓冲区使用情况，并且还依赖于 FIDL 实现细节。