Operational Logging
Operational logging records diagnostics about the Relay process, including startup, configuration, plugins, gateway behavior, and runtime failures. It is separate from agent observability through ATOF, ATIF, OpenTelemetry, or OpenInference.
Relay writes operational logs to stderr. Optional file sinks receive additional copies of those records. Each record includes a root Relay ID for correlation.
Defaults
Without configuration, Relay uses:
erroras the minimum log level- Human-readable stderr output
- No file sinks
Choose a Configuration Source
Use the source that matches how Relay is launched:
For CLI processes, Relay selects one source in this order:
--log-*options or--log-config-pathNEMO_RELAY_LOG*environment variables[logging]in the resolved Relayconfig.toml- Built-in defaults
Sources are selected rather than merged. Python, Node.js, and Go install a
process-lifetime LoggingRuntime when the binding loads, using environment
configuration or built-in defaults. Rust applications explicitly choose which
LoggingRuntime initialization method to use and do not apply the CLI
precedence rules.
CLI Options
Configure the minimum level and stderr format directly:
Use an absolute TOML path when file sinks or other logging settings are needed:
Do not combine --log-config-path with --log-level or
--log-stderr-format.
Environment Variables
Set these variables for a Python, Node.js, or Go process, the CLI, or a Rust
application that initializes logging with
LoggingRuntime::configure_from_environment():
Supported values are:
NEMO_RELAY_LOG:error,warn,info,debug, ortraceNEMO_RELAY_LOG_STDERR_FORMAT:humanorjsonl
Alternatively, select an absolute TOML file:
NEMO_RELAY_LOG_CONFIG_PATH cannot be combined with the other logging
environment variables.
When none of these variables are set, Python, Node.js, and Go install Relay’s
built-in default logger unless the host already owns Rust’s process-global
log facade. They also preserve an existing Relay logger rather than replacing
it. Records emitted before any logger is installed are discarded, and a host
cannot install its own logger after Relay has claimed the facade. Set one of
these variables when Relay must configure its own logging.
This binding behavior differs from
LoggingRuntime::configure_from_environment(), which always attempts to
install Relay’s built-in defaults when no variables are set.
Python and Node.js drain pending file-sink records during normal runtime
teardown. Go applications that configure file sinks must call
nemo_relay.ShutdownLogging before main returns; defer it near the start of
main so it runs after other Relay cleanup.
TOML Configuration
Logging settings use a [logging] table:
File sink paths are resolved relative to the process working directory. File
sinks use asynchronous queues, and queue_capacity cannot exceed 8,192 entries
per sink. Size-based rotation is optional; when enabled,
max_file_size_bytes and retained_files must be configured together.
retained_files counts backup files in addition to the active file and cannot
exceed 9. A record larger than max_file_size_bytes remains intact rather
than being split. File sinks remain append-only when rotation settings are
omitted.
When Relay layers config.toml files, the resolved destination path is the
file sink identity. Distinct paths are emitted in highest-to-lowest precedence
order: system, project, then explicit-or-user. For matching paths, higher-layer
fields recursively overlay lower-layer fields, producing one effective sink.
Path aliases such as relay.log and ./relay.log resolve to one sink, using
the higher-layer spelling and settings.
Rust Library API
Initialize operational logging once during application startup by choosing one of these public APIs:
LoggingRuntime::configure(config)for a constructedLoggingConfigLoggingRuntime::configure_from_environment()for environment configurationLoggingRuntime::configure_from_file_path(path)for an absolute TOML path
For example:
Keep the returned runtime alive until application shutdown so pending file records can be flushed.