Expand description
What logs, traces and metrics have in common on the write path.
Very little, as it turns out, and that is the point of this being a small trait rather than a framework. The three signals share no columns and no tables; what they share is the lifecycle — accumulate rows across many export requests, answer “would the next request overflow a dictionary”, answer “how big are you”, and seal into a set of named Arrow tables plus a time range.
That lifecycle is the flusher’s state machine in mira::pipeline, which is
about a hundred lines of genuinely subtle code: deferred jobs carried into
the next block, a deadline that starts at the first row rather than the last
flush, ordering preserved across a mid-batch seal, a builder replaced rather
than reused after a failed finish. Three hand-copied versions of that would
be three places for the next bug in it to be fixed once and missed twice.
One trait and one generic flusher is the cheaper of the two.
Deliberately not in here: anything about columns, attributes or schemas. Every signal’s layout is its own, because OTLP’s are.
Structs§
- Open
- A snapshot of the open, unsealed block: rows that have been acknowledged but not yet published, in the same Arrow shape the read path already knows.
- Sealed
- A block’s worth of rows, sealed and ready for
crate::block::publish.
Enums§
- Sidecars
- Whether a seal derives the pruning sidecars, or skips them.
Traits§
- Signal
Builder - One signal’s accumulator, from the flusher’s point of view.