2.6 Synthetic Events

4 min read

Synthetic events are records eventd generates about itself. They are written straight to a shard database and never touch KMES.

They carry no KMES header: no identity stamps, no sequence number, no origin class. What they have is a timestamp and one of exactly five event types, all under eventd's own platform root eventd (PGSS §6.A), and the type is what distinguishes them in the events table — no separate record-type column exists (§3.1). The timestamp is eventd's clock when it generated the record, except for a gap record, whose timestamp is that of the event that revealed the gap (§2.5).

2.6.1 When they are generated #

Payload schemas for all five are in §3.2.

All five are tier essential (PGSS §6.8). eventd is their emitter as well as their store, and the emission policy never switches an essential type off (PGSS §6.9), so eventd writes each whenever its condition occurs and consults no policy for them. Their fields are those of eventd's catalogue fragment, installed as /usr/share/evman/eventd.evman (PGSS §6.10).

Note what is absent: there is no synthetic event for malformed ingestion input. Authentication does not make admitted input trustworthy, and emitting a durable record per bad datagram would hand a producer an amplification primitive (PSPU §3.4). These five are conditions eventd observed about itself, not reactions to what it was sent.

2.6.2 Which shard #

CPU-specific synthetic events — gap records — go to the shard assigned to the CPU that generated them, handed to that writer thread alongside that CPU's ordinary events. A gap record travels with the events it describes.

Daemon-wide ones — start, stop, configuration changes, quarantines — go to shard 0 when shard 0 is writable, and otherwise to the lowest-numbered writable active shard. If no shard is writable at all the event is skipped, with the failure logged to standard error.

A quarantine is the case that needs the fallback. It describes a failure on one particular shard but is itself a daemon-wide notification, so it is not written to the failing shard unless that shard has since been replaced and is writable again (§9.2) — writing the record of a shard's failure into that shard would lose it exactly when it matters.

These events are infrequent enough that concentrating them on shard 0 costs nothing measurable in balance.

2.6.3 Storage and ordering #

Synthetic events live in the same shard databases as KMES events and participate in the same batching, the same retention and the same queries. Access control treats their types like any other (§7.2), so a descriptor at Machine\System\eventd\Security\Events\eventd governs all five, and one at …\Events\eventd.daemon only the start and stop records.

They are ordered by their timestamp and take no part in per-CPU sequence numbering.

For the four daemon-wide types that timestamp is when eventd noticed, not when the condition occurred. A gap record is different: its timestamp is the revealing event's (§2.5), so it sorts beside that event, and with loss.preceding-time it bounds when the lost events were written. eventd may detect a gap long after the events were overwritten — after a restart, the first thing it writes in a boot can be the record of events lost before — and the record's time says when they were lost, not when eventd found out.

2.6.4 The reserved types #

A KMES event whose type is one of the five is not stored: eventd counts it and drops it, and still receipts its sequence (§3.1). Exactly those five names are reserved, not the eventd root or any prefix of it, so eventd remains free to emit other eventd.* types through KMES.

Edit this page