Glossary

This page defines every term you will encounter in the Prelude Collector documentation. Definitions are intentionally short. For worked examples, see the tutorials. For an end-to-end walkthrough of how these pieces interact, see Data Flow.

Core objects

Device : A network element you want to monitor — typically a router, switch, firewall, or optical platform. A device has an IP address, a name, and one or more protocol records attached to it. The collector treats every device the same regardless of vendor, so the rest of your pipeline does not need to care whether the underlying box is Cisco, Juniper, Nokia, or Arista.

Protocol : The collection method used to reach a device. Prelude Collector supports gNMI, NETCONF, SNMP, and CLI. A protocol record carries credentials, the port, and any protocol-specific options for one device. A device can have several protocol records attached if you want to reach different parts of its data plane through different protocols.

Subscription : A binding between a device and a model that drives active collection. A subscription declares which model to use, which protocol to use, and how often to poll. When you enable it, the collector starts a worker for that subscription. When you disable it, the worker stops. Subscriptions are the unit of "this device is being collected right now."

Model : A named schema that describes which fields to collect and how to interpret them. A model is independent of any particular device or vendor — you point many devices at the same model so that downstream consumers see a consistent shape no matter where the data came from. A model is organized as a family (the stable, uniquely-named identity) that owns one or more versions; the fields and mappings live on a version. See also: built-in vs custom model, model version.

Model family : The stable identity of a model — its unique name. Renaming a family does not change its identity, so subscriptions and downstream consumers keep working across a rename. A family holds one or more versions.

Model version : One schema revision of a model family, labeled with a semantic version string such as 1.0.0 or 2.1.0. Multiple versions of the same family can coexist, each with its own fields and mappings, so you can evolve a model without disturbing devices still on an earlier revision. A new version starts as an inactive draft that copies the source version's fields and mappings.

Version pinning : How a subscription chooses which version of a model to collect. A subscription can pin a specific version, or leave the pin blank to track the latest active version — in which case it automatically follows the newest active version as the family evolves.

Key field (identity key) : The one field in a model flagged as its protocol-independent identity key. Each collected row is uniquely identified by this field's value (an interface name, a BGP peer address, a sensor ID), so downstream systems can tell whether two records describe the same object regardless of which protocol produced them. Exactly one field per model version carries the flag.

Field : A single data point inside a model, identified by a name and a type. Each field has one or more mappings that tell the collector where to find the value in the device response — for example, a YANG path for gNMI or NETCONF, an OID for SNMP, or a TTP (Template Text Parser) template for CLI.

Mapping : A rule that binds a raw value from a device response to a field in a model. A mapping holds the source path expression, optional key extraction logic, and any inline transformations to apply. Mappings are how you reshape vendor-specific output into your model.

Transform : A named function applied to a field value before it is stored. Transforms normalize, convert, or enrich raw data — for example converting tenths of a degree to degrees Celsius, decoding a bitfield, or looking up an OID label in a MIB. See also: built-in vs custom transform.

Snapshot : The complete result of one collection pass through a subscription. A snapshot is an instance of a model, populated with mapped and transformed values, tagged with the device, the timestamp, and the subscription that produced it. Snapshots are what the collector publishes to your output backends.

Output : A backend that receives snapshots. Supported outputs include NATS, Prometheus, InfluxDB, Kafka, webhook, file, and TimescaleDB. You can enable any combination of outputs at the same time, and every snapshot fans out to all of them in parallel.

Variants

Built-in model : A model that ships inside the collector binary. Built-in models cover common operational data — interface state, system health, routing summaries — and are available immediately after install with no configuration.

Custom model : A model you create yourself, stored in the collector's database. Custom models are hot-reloaded: when you save a change, running subscriptions pick it up on their next collection cycle without a restart.

Built-in transform : A transform shipped inside the collector binary. Built-in transforms cover unit conversions, common string parsing, OID lookups, type coercions, and similar everyday cases. They are referenced by name in mappings.

Custom transform : A transform you write in Starlark, a safe Python-like scripting language. Custom transforms run inside the collector process, take a single value as input, and return a single value as output. Like custom models, they are hot-reloaded on save.

Adjacent concepts

API token : The credential the REST API uses to authenticate requests. You create tokens through the customer portal and pass them as a bearer header on every API call. Treat tokens like passwords: rotate them, scope them, and never commit them to source control. Examples in this documentation use <your-api-token> as a placeholder.

License : The entitlement that controls how many devices a Prelude Collector instance can collect from. The free tier is built in and allows up to 20 active devices with no key required; a paid license raises that cap to your purchased quantity. The collector validates paid licenses against the Arolo Customer Portal on a schedule. Free-tier instances are expected to register with the portal within 3 months of installation.

YANG/MIB browsers : Built-in tools in the collector UI that let you explore vendor YANG trees and SNMP MIBs without leaving the application. Use them to find the path or OID you need when authoring a mapping.

Scalar : The third-party tool used to render the collector's REST API reference in this documentation. You will see "Scalar" in the API section header. It does not affect runtime behavior — it is only the format of the API docs.

Related deployment terms

OCI image : The container image format used to distribute the collector. You can run the image under Docker, Podman, or any other OCI-compliant runtime. The same image works across platforms.

systemd unit : A native Linux service definition you can use to run the collector outside of a container, managed alongside other services on the host.