A Logger Name Is Not the Name of a Failed Component

When a robot cell stops or a controller begins behaving unexpectedly, one of the first artifacts a service team reaches for is the log output. The names that appear beside each line—often strings that look like component identifiers—can invite a particular reading: that the named entity is the thing that failed. This reading is seductive but unreliable. A logger name identifies the channel through which a message was emitted, not a diagnosis. Treating it as a diagnosis without independent support is a recurring source of error in repair-intake documentation, and it deserves careful unpacking before any handover or root-cause narrative is drafted.

What a Logger Name Actually Records

ROS 2 Jazzy logging documentation describes named loggers and severity levels DEBUG, INFO, WARN, ERROR and FATAL. The logger’s effective level determines which message severities it processes. A name helps attribute a message within the software’s logging arrangement; it does not independently establish which physical component failed. Reading it as a diagnosis would add a conclusion requiring other evidence.

For an intake record, an editorial approach is to preserve the observed message and its logger name separately from any proposed failed-component explanation. A person may have a useful hypothesis, but the record should label it as such. This site’s technical category provides related reading; it is not an internal service note verifying a particular hypothesis.

Severity Is a Filter, Not a Verdict

Severity levels are frequently misunderstood as a ladder of certainty: ERROR must mean something broke, FATAL must mean the system died. In practice, severity is a filtering mechanism. A logger will only process log messages with severity at or higher than a specified level chosen for the logger ROS 2 Jazzy logging severity and emission behavior. A system integrator configures thresholds so that only messages at or above a given level reach a particular destination—console, disk, or rosout. A module author decides at which level to emit each message. Neither decision is a diagnostic act. A developer might log a recoverable retry as WARN; another might log the same condition as INFO. Neither choice establishes whether the condition contributed to a failure.

When reviewing logs for a repair intake, it is useful to ask: at what severity threshold was this destination configured? A message logged at DEBUG will simply never appear if the threshold is set to WARN, and its absence from the record tells you nothing about whether the event occurred. Recording "no ERROR lines observed" is a factual statement about the log output; recording "no fault occurred in component X" is an inference that the log output alone cannot support.

Provenance Thinking: Who Said What, and When

The W3C PROV Primer offers a useful mental model for this problem. It introduces entities, activities, and agents—things, processes involving things, and responsible actors—as the basic building blocks of provenance descriptions W3C PROV Primer on entities, activities, and agents. A log message can be thought of as an entity: it has content, a timestamp, and an associated logger (the agent that produced it). The act of filtering and routing that message to a console or a file is an activity. Writing down a provenance description—"logger X emitted an ERROR at time T"—records a relationship between these elements. Provenance records are metadata W3C PROV Primer on entities, activities, and agents, and like any metadata, their reliability depends on the observations that fed them.

Applied to repair intake, this means that documenting "the navigation logger reported ERROR" is a provenance claim: it records that a particular agent produced a particular entity. It does not, by itself, confirm that the navigation subsystem was the failed component. The failure interpretation requires additional evidence—sensor readings, mechanical inspection, reproduction steps—that is independent of the log entry. Keeping these layers distinct in the intake record prevents later readers from conflating the source of a message with the source of a fault.

Console, Disk, and Rosout: Three Destinations, Three Blind Spots

The ROS logging documentation describes console, disk and rosout destinations and per-node controls for enabling them. An intake reviewer should record which outputs were actually obtained and what configuration is known. Do not assume that a console extract, a disk file or a topic recording contains every message. The relevant question is the observed coverage and filtering, rather than an unsupported account of why a record might be absent.

A careful negative observation names its scope: no specified messages were found in the material examined. It should not silently expand into a statement about all activity in the system. The article archive is a route to related explanations, not a repository of this machine’s repair records. Preserving that distinction helps subsequent readers see what was examined and which conclusions remain tentative.

Common Misconceptions Worth Naming Explicitly

Several recurring patterns deserve direct mention because they distort repair records in predictable ways. First, the "loudest logger" fallacy: the logger that produced the most lines, or the most severe lines, is assumed to be the failed component. Volume is a function of logging verbosity, not fault centrality. A chatty debug node that happens to be running when a failure occurs may dominate the output without being involved in the fault at all.

Second, the "name match" fallacy: a logger whose name contains a recognizable component identifier—say, "arm_controller" or "safety_monitor"—is taken as evidence that the named component is at fault. Logger names are chosen to reflect nodes or modules. They may refer to a node that wraps multiple hardware subsystems, or to a software layer that merely passes messages through. The name is a pointer to code, not a pointer to a broken part.

Third, the "severity equals certainty" fallacy: an ERROR line is treated as proof of a fault, while a WARN line is treated as a harmless anomaly. In reality, severity reflects the developer's judgment at the time the logging call was written. That judgment may have been calibrated for a different operating context, or it may simply reflect a convention that does not map cleanly onto the failure modes the service team is investigating.

Practical Questions for the Intake Form

Rather than asking "which component failed?"—a question that the log output alone cannot answer—an intake form can guide the recorder toward more defensible entries. Useful questions include: Which logger names appear in the captured output? At what severity level was each message emitted? What destinations were active and what thresholds were configured? Were any expected messages absent—INFO lines that normally appear during startup, for example? What independent observations (sensor readings, operator reports, mechanical checks) corroborate or contradict the log content?

These questions do not produce a root-cause conclusion. They produce a structured record of what the logging system actually showed and what it did not show, with the provenance of each entry preserved. That record is far more useful to a downstream analyst than a premature component-failure label copied from a logger name. It also respects the boundary between observation and inference that keeps repair documentation honest—a boundary that, once blurred, is difficult to restore.