“event” ping¶

此 ping 传输遥测事件记录。

客户端 ID 和配置文件组 ID 会与该 ping 一起提交。该遥测环境会在该 ping 中提交。

{
  "type": "event",
  ... common ping data
  "clientId": <UUID>,
  "profileGroupId": <UUID>,
  "environment": { ... },
  "payload": {
    "reason": {periodic, max, shutdown}, // Why the ping was submitted
    "processStartTimestamp": <UNIX Timestamp>, // Minute precision, for calculating absolute time across pings
    "sessionId": <UUID>, // For linking to "main" pings
    "subsessionId": <UUID>, // For linking to "main" pings
    "lostEventsCount": <number>, // How many events we had to drop. Valid only for reasons "max" and "shutdown"
    "events": {
      "parent": [ // process name, one of the keys from Processes.yaml
        [timestamp, category, method, object, value, extra],
        ... // At most 1000
      ]
    }
  }
}

发送行为¶

此 ping 最多每十分钟提交一次，并且在记录事件的每个小时至少提交一次。达到 1000 个事件时，会立即发送 ping，除非在之前的 ping 发送后十分钟内，在这种情况下，可能会丢失一些事件记录。为了避免丢失收集到的数据，ping 中包含了这些丢失记录的数量。

在关闭时，在 profile-before-change 期间，会发送最终 ping，其中包含任何剩余的事件记录，无论频率如何，但需遵守事件记录限制。

1000 条记录的限制以及一小时和十分钟的频率由偏好设置控制。

字段详细信息¶

reason¶

该 reason 字段包含有关提交“event” ping 的原因的信息

periodic：提交 event ping 是因为过去一小时内至少发生了一个事件。
max：提交 event ping 是因为达到了 1000 条记录的限制。
shutdown：提交 event ping 是因为 Firefox 正在关闭，并且一些事件尚未提交。

processStartTimestamp¶

用户 Firefox 主进程创建的那一分钟。事件记录时间戳相对于 Firefox 的主进程启动时间记录。这为按顺序重建用户的完整事件会话提供了依据，并提供了一种对事件 ping 进行分组的机制。

sessionId¶

发送 ping 时当前会话的 ID。

subsessionId¶

发送 ping 时当前子会话的 ID。

注意

如果在此期间发生了会话拆分，则这可能不是事件发生的同一个子会话。

lostEventsCount¶

由于我们在能够发送 ping 之前达到了每 ping 1000 条的限制，我们不得不丢弃的事件数量。仅当“event” ping 的 reason 设置为“max”或“shutdown”时，才应具有非零值。哪些事件丢失应可以通过客户端的“main” ping 使用事件摘要计算。

events¶

一个从进程名称到已序列化的事件记录数组的映射。

版本历史¶

Firefox 62：开始发送“event” ping (bug 1460595)。