Log files

Composer writes its full log history to disk in two parallel formats: a JSON stream (machine-readable; what monitoring stacks ingest) and a plain-text format (the same content, suitable for grep and human reading).

Layout and rotation

• Filename pattern: VindralComposer-<HOSTNAME>-<YYYYMMDD>.{json,log}
• One file per day per format — Composer rolls over at local midnight.
• Default location: <application-root>/Logs/ — configurable through <LogDirectory> in settings.xml (relative or absolute path), or with the -l <path> startup flag (e.g. -l C:\temp\logs).
• Retention: the 30 most recent files per type are kept; older files are deleted as new ones roll in. Configure via <LogRetentionDays> in settings.xml.

Severity levels

Five levels, in increasing severity:

There is also a sub-debug verbose (a.k.a. trace) level that is filtered out by default — see Enabling verbose logging below for when and how to turn it on.

Enabling verbose logging

For deep diagnostics — reproducing a hard-to-catch bug, walking through a startup failure, or triaging a "looks fine but something's off" performance issue — Composer can drop the log floor below debug to also include the engine's verbose (trace) entries. Verbose mode is off by default because trace entries are noisy: tens to hundreds of times the volume of a normal log.

Enable it the same way in either build, via a command-line flag at launch:

Both flags set the same internal EnableTraceLogging switch:

• The on-disk .json and .log files (and Loki, if you ship to Composer Monitor) start including Verbose-level entries from this point on.
• The console / stderr minimum is also lowered to Verbose, so you'll see the same firehose in the terminal.
• The very first log line confirms the change: Logger:Verbose logging active: true.

There is no settings.xml or in-app toggle for verbose — it has to be set at launch. Restart Composer with the flag dropped to return to the normal debug floor. For routine production logging, leave it off; turn it on only for the duration of a reproduction, then disable to keep disk usage and Loki ingestion sane.

Performance and statistics streams

While the project is Running, Composer emits structured stats entries into the regular log on a 10-second cadence. They appear interleaved with the rest of the log, tagged by their message string so monitoring tools can pull them out separately. Each entry's Properties dictionary carries the actual values; the human-readable message is just the tag.

• PerformanceLog — the primary heartbeat. One entry every 10 s, severity info, identifier 2002 (InfoTick). Gated by the project property <LogPerformance> (default: enabled). Carries ~30 fields covering: session uptime, congestions in the last second, processing-queue size, average / max / 10k-window processing time (ms and as a % of frame budget), congestive-frame count, process RAM usage (current + 10-min avg/min/max in GB), GPU power draw / power state / power-management state, GPU utilization / encoder utilization / decoder utilization, GPU memory used and free (GB), CPU utilization, frame counter, and WebSocket statistics (client count, per-subscription-type subscriber counts, ingress / egress kB/s, queue lengths). This is the right stream to scrape for Grafana / Prometheus when you don't have the Composer Monitor plug-in.
• TargetStatistics — per-target encoder / decoder / network counters, one entry per target per 10-second tick. Gated by <LogPerformance> and <UseExtendedLogging> (the second is opt-in). Each entry's properties depend on the target type (RTMP, SRT, NDI, file, …).
• InputStatistics — per-input counters, one entry per input per 10-second tick. Gated by <UseExtendedLogging>. Common fields include connection state and ingest counters; type-specific fields cover SRT / RTMP / NDI specifics.

All three streams write into the same .json log file as the rest of the log. The 10-second cadence is fixed; the only knobs are on/off via <LogPerformance> and <UseExtendedLogging> in the project file.

Tip: When <LogPerformance> is on you'll see Stats: ::Uptime: ... in the human-readable log too — that's the same data summarised on a single line, distinct from the structured PerformanceLog properties used by monitoring tools.

Per-frame performance CSV (debug only)

Separate from the structured streams above, an internal <EnablePerformanceLog> setting produces a per-frame CSV next to the executable: Performance-Debug-<YYYYMMDD HHMMss>.csv with semicolon-separated columns (DateTime;Frame;ProcessingQueSize;CongestionsLastSecond;NumCongestionsSinceStart;ProcessingTime;MaxProcessingTime;AverageProcessingTime;AverageProcessingTimeLong;NumAuthorizedApiCalls;NumErrors;NumWarnings). Off by default — Composer warns at startup that "this might require a large amount of disk space" because it writes one row per rendered frame. Use only when reproducing a hard-to-catch performance regression.

stderr redirect

Some early-startup failures land on stderr before the log subsystem is online (CUDA missing, .NET runtime missing). Redirect stderr to a file when running headless to capture them:

./vindralcomposerruntime ... 2> /var/log/composer-stderr.log

The same trick works on Windows with 2>composer-stderr.log from cmd.exe.

Extended Monitoring

With Composer Monitor configured, the JSON log stream is shipped to a centralised Loki instance and surfaced through pre-built Grafana dashboards across every Composer instance in your fleet — far easier than ssh-ing into hosts and tailing files. From R2 2026 Composer Monitor is included in the base Composer licence (older releases required a separate Extended Monitoring plug-in licence).