logger for a system under simulation — the same API, routed into eta_log.

Why logging is a determinism hazard

A logger call does not just format a string. It hands the event to a handler, and the default handler logger_std_h is a process the scheduler does not own. Under load it switches from asynchronous to synchronous mode, at which point a log call becomes a synchronous call into an OTP service process — the same class of real-time dependency as code_server, and one of the ones docs/05 tells you to grep for. The handler then runs on the real scheduler and makes the caller runnable again at a moment nothing chose.

So a chatty system under test can have its schedule decided by how busy its log handler happens to be, and the symptom is a seed that mostly reproduces.

What this does instead

While a run is collecting, a call lands in eta_log as a {Level, Args} event: no process, no message, no blocking, and a sequence number from the same counter as everything else. Your system's own logging becomes part of the narrative eta_log:analyze/0 prints, interleaved with the scheduler's decisions rather than scrolling past in a separate stream.

With no run in progress it delegates to logger unchanged, so a module built with the transform logs normally outside a simulation. That is the same bargain eta_time makes with the real clock.

What it does not do

It does not filter by level, consult logger's configuration, or run formatters. An event is recorded whatever the level, because the run's log is a record of what happened rather than an operator's console, and deciding at record time what a reader will want is how you lose the line that mattered.

This documentation is LLM-generated. See the AI disclosure in README.md.