Scenario logs

Logger components emit messages under scenarios.<scenario>.<node>. Curated runtime and deployment events use nussknacker.events. Configure your log viewer to select these categories and preserve the structured fields described below. Selecting the scenarios. prefix shows messages authored in Log nodes only.

User-facing events

Events describe the failure without copying arbitrary exception messages, input data or scenario variables:

Event code	Level	Meaning
processing.timeout	ERROR	Processing timed out; check the external service and timeout configuration.
processing.connection_failed	ERROR	A connection or hostname lookup failed; check address, availability and network access.
processing.secure_connection_failed	ERROR	A TLS handshake failed; check the external service's certificate and the connection's TLS settings.
processing.failed	ERROR	Another processing failure; check the node configuration and input data.
request.invalid_input	WARN	The request cannot be parsed; check it against the scenario's API definition.
request.failed	ERROR	The request could not be completed outside the normal interpreter error path.
deployment.accepted / deployment.failed	INFO / ERROR	The engine accepted the deployment request, or that request failed. Acceptance does not mean the scenario is already running.
cancellation.accepted / cancellation.failed	INFO / ERROR	The engine accepted the cancellation request, or rejected it or could not be reached; check the scenario status.

The scenario's runtime emits the processing.* and request.* events: live Flink and Lite interpreters report processing failures, and the request-response HTTP endpoint also reports request parsing and response encoding failures. The Designer emits the deployment.* and cancellation.* events, so they appear in the Designer's logs, not in the runtime's. Scenario tests emit none of these events.

Technical logs and existing exception consumers retain their current behavior, including stacktraces, exception topics and restart policies. Failures outside these paths, such as a crashed worker, can still appear only in technical logs, so retain them for diagnosis.

Repeated runtime errors are grouped for 60 seconds by node and event code. The first error is emitted immediately. A .repeated event reports how many more were grouped: when any later error arrives after the 60 seconds, when the group is evicted, or when the runtime stops normally. No periodic background flush is used, so the count of a group that stays quiet appears with the next error or at the stop. A grouping state retains at most 1024 groups, without records or exceptions. In Flink every operator of the scenario keeps its own state; a request-response scenario keeps one for processing and one for its HTTP endpoint. The grouping is therefore not cluster-wide, and a crash can lose pending counts. Summary events omit record IDs, because they represent several records. Log-node messages are never grouped by this mechanism.

Correlation and OpenTelemetry

context_id identifies processing within an engine run and may repeat after restart. correlation_id preserves NU's existing arbitrary trace-id value, including UUIDs. HTTP header names are matched without regard to case. This value is present only when the source provides it: standard Flink sources currently do not populate it, so use context_id for a Flink record instead of expecting a correlation ID. A Lite source reads the trace-id before deserializing the record, so the error event of a record that cannot be deserialized keeps it. These fields are independent of OpenTelemetry's trace_id and span_id; no synthetic OTel identifiers are derived from NU IDs. The logging helper keeps OTel fields already present in the logging context but does not propagate tracing context across threads or operators. See HTTP tracing with OpenTelemetry for tracing request-response scenarios.

Logging configuration

The runtime writes these fields through MDC: nu_log_source, scenario_name, node_id, node_name, context_id, correlation_id and event_code. node_name is the name shown on the canvas; node_id is the node's technical identifier. The Logback configurations bundled with Nussknacker use plain text patterns that do not print MDC, so add the fields you need to the pattern or use a JSON layout that keeps MDC. For example:

<pattern>%d{HH:mm:ss.SSS} %-5level %logger{36} [%X{scenario_name}/%X{node_name}] %X{event_code} %X{correlation_id} - %msg%n</pattern>

The category for curated events is nussknacker.events; existing Log-node categories remain scenarios.<scenario>.<node>. Do not treat every pl.touk.nussknacker.* logger as a user-facing event: for example, NU's HTTP client emits Resolving addresses of ... took ... ms, and RocksDB initialization and memory warnings are technical diagnostics as well.