Logging & telemetry

Beyond the run data the editor always captures, Flowdrome can emit a structured event stream of everything useful for finding issues — and send it to your logging system.

Admin → Logging is the switch. It applies live: no restart, production included. Off costs nothing.

What gets emitted

EventCarries
workflow.loaded / workflow.unloadeda host started/stopped serving a deployed workflow (with its version)
workflow.deployedthe Nucleus pushed a workflow to a host
run.started / run.completed / run.errorrun boundaries: workflow, run id, duration, error, executed-node count
node.completed / node.errorevery node execution: type, label, status, duration, start/end time, items in/out, error
audit.*every audit event as telemetry too: logins/logouts (incl. failures), user & role changes, settings changes, workflow save/delete/deploy — with actor, subject, and IP

Workflows running on the built-in host are covered automatically: the host is spawned pre-wired to report home, so the one Admin → Logging switch governs everything you see in the consoles — and toggling it applies to the host live, no restart.

Node events also carry phase timings where nodes report them — the SQL node splits connect (socket + TLS + auth) from query, the HTTP nodes time the request — plus the node’s payload bytes in/out and the worker’s memory at execution time. That’s the raw material for “why is this flow slow” answered from your log platform.

Where it goes

  • Internal log only — events echo to the Nucleus console and are written durably as downloadable NDJSON files (see below).
  • HTTP endpoint — batched JSON arrays POSTed to any collector, optional bearer token.
  • Splunk — the HTTP Event Collector: give it the HEC base URL and token; events arrive as flowdrome:telemetry sourcetype envelopes.
  • Azure Monitor (Log Analytics) — workspace id + shared key; events land in a custom table (FlowdromeTelemetry_CL by default).

Batching (size + flush interval) is configurable; a Send test event button proves the pipe before you trust it. Export is non-blocking by design — a slow or down collector never slows a run, and drops under backpressure are counted and shown.

Internal log files

With the internal log active (as the target, or mirrored alongside an external sink), the complete event record is written to disk as NDJSON — one full JSON event per line, nothing truncated. The files rotate and prune themselves:

  • Max size per file (MB) — a file rotates once it reaches the cap.
  • Sequential naming{prefix}-000001.log, -000002.log, … (the prefix is yours to set).
  • Files kept — the oldest files beyond the retention count are deleted automatically.

The Logging panel lists every file on disk with its size and age. Download any single file, or Download all (.zip) for the complete set — that’s your “give me everything” export when a support case or postmortem needs the raw record.

External hosts

External hosts can report into the same Admin-configured pipeline: pin the ingest token on the Nucleus with FLOWDROME_TELEMETRY_INGEST_TOKEN, then point each host at the Nucleus:

FLOWDROME_TELEMETRY=1
FLOWDROME_TELEMETRY_TARGET=http
FLOWDROME_TELEMETRY_URL=https://<nucleus>/api/telemetry/ingest
FLOWDROME_TELEMETRY_TOKEN=<the ingest token>

Events arriving at the ingest endpoint flow through whatever the Admin → Logging config says — internal files, Splunk, Azure, HTTP — and the enabled toggle gates them live.

Hosts (production)

Hosts serving deployed workflows emit the same events, configured by environment (a data-plane machine has no admin UI):

FLOWDROME_TELEMETRY=1
FLOWDROME_TELEMETRY_TARGET=splunk            # internal | http | splunk | azure
FLOWDROME_TELEMETRY_URL=https://splunk:8088
FLOWDROME_TELEMETRY_TOKEN=<hec-token>
# azure instead: FLOWDROME_TELEMETRY_WORKSPACE_ID / FLOWDROME_TELEMETRY_SHARED_KEY / FLOWDROME_TELEMETRY_LOG_TYPE