Skip to main content
Version: 2.0.0 (Latest)

Glossary

Quick reference for PADAS terms you’ll see in the UI, docs, and logs. Deeper behaviour: Configuration & Runtime Engine, REST API Reference, Security.

Runtime & Architecture​

Core​

The PADAS engine process: routes events (StreamRouter), runs tasks and connectors, optional WAL, and serves /api/v1/*. Registry rows live under [api.persistence].config_dir (for example streams.json, tasks.json, connectors.json). Tune paths and limits in padas.toml — see Configuration & Runtime Engine.

Runtime Engine​

Same as Core in practice — one process runs your pipelines; there is no separate “pipeline service” per workflow.

StreamRouter​

In-process component that buffers and routes events per stream to subscribers (tasks, consumers, WAL). Shared across all pipelines on that Core.

Streams & Processing​

Stream​

Named channel events flow through inside Core. Sources publish in; tasks read and write; sinks read out. Optional WAL enables durability and historical reads.

WAL​

On-disk write-ahead log for a stream when enabled. Trades disk (and sometimes latency) for crash recovery and replay. If WAL is off for a stream, some query paths may fail — check stream settings and Configuration & Runtime Engine.

Consumer lag​

How far a consumer’s offset is behind the stream head. Large lag may push reads toward WAL; tune [core.subscriber.lag] and sink throughput.

Task​

Registry object that reads from source stream(s), runs PDL, writes to sink stream(s). Start / stop control execution on the Core after deploy. See Tasks.

Processing task​

Task mode: typically one PDL evaluation per inbound event on the hot path (plus window state for aggregates). Distinct from detection rule evaluation.

Detection task​

Task mode: multiple saved conditions (queries/rules), evaluated for alerting-style matches.

PDL​

Padas Domain Language — pipeline expressions (|-separated stages: parse, filter, eval, aggregate). Full syntax: PDL Reference.

Aggregation​

Windowed summarisation (timespan, group_by, …). Emits flat result rows; processing tasks may fan out one downstream event per group when configured.

Watermark​

Signal that a time window is ready to flush idle aggregates — ties to [core.task.aggregation.*] and shutdown behaviour.

Replay​

Reading past events via stream consume APIs or POST /api/v1/query, bounded by retention and WAL. Operational replay datasets (saved slices for tests) live under Testing.

Connectors & Pipelines​

Connector​

Source or sink integration: moves data between external systems and streams. Stored in connectors.json; start / stop after deploy.

Source connector​

Ingests from outside (syslog, HTTP, Kafka, …) into a stream.

Sink connector​

Reads from a stream (or task output path) and delivers outward.

Connector class​

Implementation type (http, syslog, kafka, …) — sets config schema and behaviour.

Pipeline​

Registry workflow: one source, ordered tasks, one or more sinks. Defined under Configuration; assigned and deployed under Management. See Pipelines.

Operations & Deployment​

Assign​

Choose which sources, tasks, and sinks belong on a Core (or attach a pipeline to Cores). Saves intent — does not push to the engine by itself.

Deploy​

Apply registry changes to the Core so running config matches what you assigned.

Deploy All​

Push pending pipeline/deploy updates across the selected Cores (bulk deploy).

Assign and deploy​

Save placement and deploy in one step for that Core/pipeline row.

Drift​

UI/registry definition no longer matches what’s running — often needs Deploy, restart, or fixing partial file edits.

Monitoring & Testing​

Monitoring​

Live EPS (events per second), drops, stream/task/connector rows, Query, Monitor, and metrics for the selected Core — shows what’s happening now, not the registry editor. See Monitoring.

Testing​

Capture or upload events, run PDL against them on a Core without changing production pipelines. See Testing.

Capture​

Saved event slice from Monitoring (or uploads) used as input for Testing.

Security & Identity​

Service account token​

JSON on the Core host (service-account.token); token value is sent as Authorization: Bearer to /api/v1/*. The UI stores the same secret per row as account token. See Security.

JWT session​

Browser session to padas-ui (HTTP-only cookies). Not sent to Core APIs for normal console flows — Core trusts Bearer, not UI roles.

Bearer authentication​

When [api.auth].enabled, every /api/v1 route requires a valid Bearer header (including /health and /metrics).

Token rotation​

Core can issue a new service-account secret (/api/v1/auth/token/refresh); update automation and UI account token rows before old tokens expire.

Lockout​

Too many bad Bearer attempts from one client IP can temporarily block auth — check proxy X-Forwarded-For headers. Details: Security.

API & Runtime Control​

REST API​

Core’s /api/v1 HTTP surface (Axum): CRUD and lifecycle for streams, tasks, connectors, query, reload, auth. Same process as the engine — handlers use EmbeddedApiState, not forked CLI per request. See REST API Reference.

Runtime status​

GET /api/v1/status (and per-resource …/status) — snapshot of health and resources for triage.

Configuration & Runtime Engine · REST API Reference · Security · Monitoring · Testing