Skip to main content

Architecture

FleetAMP uses a layered architecture so upstream protocol changes and optional integrations do not leak into the core domain.

FleetAMP layered architecture from presentation through application, domain, adapters and storage

Management boundary​

The first management implementation is OpAMP:

OpAMP protocol translated into the FleetAMP domain model at the adapter boundary

OpAMP protobufs should remain inside the OpAMP adapter. Application, API, storage, and UI code should operate on FleetAMP domain types.

Deployment independence​

A managed agent is independent of its runtime. VM, bare metal, container, and Kubernetes information belongs to deployment context and metadata. Kubernetes or cloud platforms remain responsible for scheduling, replicas, and infrastructure lifecycle; FleetAMP focuses on telemetry-agent management state and configuration.

Future integrations​

Provider interfaces are reserved for configuration sources such as Git systems and enrichment sources such as CSDM/CMDB. These are optional integrations, not dependencies of the core.

Current verified data path​

The first working FleetAMP end-to-end path is:

Collector information flowing through the OpAMP adapter into FleetAMP inventory, API and UI

The Collector's OTLP telemetry pipeline is independent of this management connection. FleetAMP manages the Collector control-plane state; it does not sit in the telemetry data path.