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. See also: built-in vs custom model.

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, and file. 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.