These docs are under active development and cover the v0.20 Kobicha security model.
Peios Learn
On this page
Print Full Specification
§4.3

Log Writer

§4.3.1 Ingestion thread

eventd MUST run a dedicated log ingestion thread that reads datagrams from the log socket and writes log records to the log store. The log ingestion thread is independent of the event drain threads and event writer threads -- log ingestion does not contend with event ingestion.

§4.3.2 Batched writes

The log writer uses the same adaptive batch sizing approach as the event writer (§2.4). Log records are accumulated into a transaction and committed when either the batch size or latency threshold is reached.

The log writer's batch parameters are configured independently from the event writer:

Key Type Default Valid range Description
LogMaxBatchSize REG_DWORD 5000 100--100000 Maximum number of log records in a single transaction.
LogMaxBatchLatencyMs REG_DWORD 500 10--5000 Maximum time in milliseconds between the first log record entering a batch and the batch being committed.
ⓘ Informative
The default log batch latency (500ms) is higher than the event batch latency (100ms) because log loss is tolerable and power-loss resilience is less critical for logs than for events. Larger, less frequent batches improve throughput efficiency for the common case where log volume is moderate.

§4.3.3 SQLite configuration

The log store database MUST be opened in WAL mode. The synchronous pragma SHOULD be set to NORMAL rather than FULL. Per-transaction fsync is not required for logs because log loss on power failure is acceptable. NORMAL mode syncs at checkpoint time, providing durability against process crashes without the per-commit fsync overhead.

This is a deliberate divergence from the event store, which uses synchronous = FULL for per-transaction durability. The different durability requirements of events and logs justify different SQLite configurations.