CaptureHealth
An out-of-band health signal for the log-capture edge.
Why this exists
The capture queue is bounded, so an application that logs faster than the exporter drains loses events instead of growing the heap without limit (#2124). That trade is only acceptable if the loss is visible: bounded-and-silent would swap a failure you can see (memory climbing) for one you cannot, which is the exact inversion #1860 was about.
Read it from LogCaptureInstallation.health — in-process, never through the logging pipeline, because the logging pipeline is what is failing.
Why it is not ExporterHealth
us.tractat.kuilt.otel.ExporterHealth answers the neighbouring question ("is the durable write path alive?") and this deliberately mirrors its shape — a data class of cumulative counters behind a StateFlow, no timestamps, no clock on a hot path. It is a separate type because the drop happens above the exporter, in the queue that feeds it: an event dropped here never reached the exporter, so folding it into the exporter's counters would attribute a queue overflow to a component that never saw the event. The two are read together and mean different things — droppedEvents climbing with a healthy ExporterHealth says the export path works and is merely too slow for this log volume.
Properties
Events discarded because the capture queue was full when they were logged, cumulative across the process. Exact, not sampled: the channel's own overflow path reports each evicted element once, so every increment is one application log line that will never be exported. It counts only overflow — events the capture policy declines (below CaptureConfig.minLevel, or one of the exporter's own loggers) never enter the queue, and events logged after capture is closed are not overflow.