Concepts-Architecture on ZAPP

Containers

Mon, 01 Jan 0001 00:00:00 +0000

ZAPP containers can embed multiple data formats in one container. Key features include:

Minimal overhead: 4-byte container header and 10-byte header for each payload
Variable-length multiple payloads with no inherent container size limit
Extensible via IANA ID + TypeID mechanism

Redfish listener architecture

Mon, 01 Jan 0001 00:00:00 +0000

The Redfish listener example combines Redfish sensor discovery, a ZAPP Listener pipeline, and ZAPP Aggregator forwarding.

The Redfish listener discovers or collects telemetry from Redfish-enabled baseboard management controllers (BMCs) and forwards telemetry to the ZAPP Aggregator.

Main components

BMC Redfish endpoints: BMC Redfish endpoints provide sensor metadata and telemetry from managed infrastructure.
Sensor pipeline: The envPlugins.sensorPipeline configuration runs before pipeline components start. It loads or discovers sensors and populates the listener sensor manifest.
Redfish listener pipeline: The listener pipeline runs inside the zapp container. For Redfish deployments, the pipeline includes Redfish configuration and forwards telemetry to an aggregatorStreamer component.
ZAPP Aggregator: The ZAPP Aggregator receives telemetry from the listener and exposes metrics, manifest data, and subscriber gRPC access.

Data flow

The listener reads the pipeline file and expands environment and secret references.
The sensor pipeline reads envPlugins.sensorPipeline.
ZAPP discovers or loads Redfish sensors into the manifest.
Pipeline components start.
The listener forwards telemetry to the ZAPP Aggregator.
Operators inspect /metrics, /manifest, or /manifest.json to validate deployment health.

The Helm chart mounts the pipeline at /config/pipeline.yaml, mounts Redfish credential files as Kubernetes Secrets, and passes the ZAPP Aggregator address to the listener with --aggregator.

Time-series telemetry

Mon, 01 Jan 0001 00:00:00 +0000

ZAPP represents decoded sensor telemetry as time-series models. Operators usually interact with this model indirectly through pipeline components, the ZAPP Aggregator, and gRPC subscriptions.

A time-series model contains:

readings, which group telemetry by sensor ID
Instance readings, which represent individual samples
Window readings, which represent aggregated samples over a time interval
snapshots, which represent the latest known values for multiple sensors at one timestamp

Pipeline components use time-series models when telemetry has been decoded and associated with the sensor manifest. For example, payloadProcessor converts NVIDIA time-series payloads into *timeseries.Model values, and redfishCollector emits *timeseries.Model values from Redfish polling.

ZAPP Listener

Mon, 01 Jan 0001 00:00:00 +0000

A ZAPP Listener runs a telemetry pipeline from a YAML configuration file. A listener can receive ZAPP payloads, poll Redfish endpoints, process payload batches, forward telemetry to the ZAPP Aggregator, or expose telemetry directly to consumers.

A listener pipeline can poll BMC Redfish endpoints and expose the resulting time-series telemetry directly through a grpcServer component.

ZAPP overview

Mon, 01 Jan 0001 00:00:00 +0000

ZAPP collects telemetry from infrastructure systems and forwards it through a configurable pipeline. Many deployments include one or more ZAPP Listeners and one ZAPP Aggregator.

ZAPP Listeners collect or receive telemetry near the source. A ZAPP Aggregator receives telemetry from multiple listeners and exposes one client-facing endpoint.

ZAPP Listener

A ZAPP Listener runs a configured telemetry pipeline. Depending on the pipeline, the listener can receive telemetry packets, discover sensors, collect Redfish telemetry, process payloads, and forward telemetry to the ZAPP Aggregator or directly to downstream consumers.

Concepts

Mon, 01 Jan 0001 00:00:00 +0000

Use these pages to understand the telemetry concepts that ZAPP components and plugins share.

ZAPP Aggregator

Mon, 01 Jan 0001 00:00:00 +0000

The ZAPP Aggregator receives telemetry from ZAPP Listeners and exposes a stable API surface for consumers. Use it when you need centralized listener fan-in, manifest visibility, and one client endpoint for telemetry subscribers.

Helm values

Most deployments review image, replica, port, resource, and monitoring settings first.

zappAggregator:
 enabled: true
 image:
 repository: nvcr.io/nvidia/zapp-aggregator
 tag: ""
 pullPolicy: IfNotPresent

 replicas: 1
 metricsPort: 8888
 manifestUI: true

 containerPorts:
 listenerGrpc: 9991
 udpTelemetry: 9992
 clientGrpc: 9999

 serviceMonitor:
 enabled: false
 interval: 30s

Important fields:

Components

Mon, 01 Jan 0001 00:00:00 +0000

ZAPP deployments are built from two runtime components: ZAPP Listeners and the ZAPP Aggregator. Listener pipelines run near telemetry sources. The ZAPP Aggregator provides central fan-in, listener coordination, and consumer-facing APIs.

Use these pages to understand what each component runs, which configuration fields matter first, and where pipeline configuration fits into a deployment.

Pipeline components

Mon, 01 Jan 0001 00:00:00 +0000

A ZAPP pipeline is a YAML map of named components. Each component declares a type, component-specific fields, and optional targets. Targets connect one component output to another component input.

Components usually fit one of three roles:

Source components receive or collect telemetry
Processing components convert or route telemetry
Terminal components forward telemetry to a service, network endpoint, or consumer API

Channels

Pipeline components pass data through typed channels. Source and processing components expose outputs with targets, and downstream components receive those outputs as inputs. During startup, ZAPP creates the channels, connects each target to the named component, and validates that the receiving component accepts that input type.