Skip to main content
Version: 3.1.0 (Preview)

Ambari 3.1 Architecture

Ambari Server, Agent, React applications, metadata database, managed services, and monitoring data plane

ComponentResponsibilities
Ambari ServerREST APIs, authorization, topology/configuration, operation scheduling, Agent coordination, Stack metadata, and the monitoring query boundary
Metadata databaseDurable management state, configuration versions, request/task records, user/permission data, and monitoring dashboard/datasource definitions
Ambari AgentHost registration, package/configuration work, service lifecycle scripts, command status, and the Linux/component telemetry exporter
React Web and Admin applicationsAuthorized operator and administrative workflows based on Server state
Managed servicesHadoop ecosystem processes defined by the installed Stack
VMAGENT and VictoriaMetricsIndependent metric scraping, remote-write buffering, time-series storage, and queries

Request And Data Paths​

The following shows control and request paths; metric responses return to the scraper:

React / Admin UI -> Ambari REST API -> Ambari Server -> Metadata database
                                          |
Stack metadata ---------------------------+
                                          |
                                          +-> Agent commands -> Service scripts
                                          +-> Telemetry assignments -> Agent exporter

VMAGENT -> HTTP service discovery -> Ambari Server
VMAGENT -> Agent exporter -> Linux /proc and service endpoints
VMAGENT -> remote write -> VictoriaMetrics
React -> Ambari query proxy -> VictoriaMetrics

Server records operations as requests and tasks. Agent-side scripts perform host work and report status; the UI observes authoritative state through REST and realtime updates. A successful API submission is not a completed operation.

Request, Task, And Recovery State​

Persisted Ambari requests, stages, host tasks, Agent commands, status reports, reconnect recovery, and supported retry

Refresh and reconnect reload persisted Server state rather than restarting work. A supported retry creates follow-up work from the failed boundary without silently repeating completed tasks.

Configuration And Extensions​

Stack metadata determines which services, components, configuration properties, dependencies, and commands are valid. Configuration versions and host/group overrides are resolved before Agent work is dispatched. Blueprints, Stack inheritance, and Themes build on these contracts.

Extensions must preserve permissions, state transitions, cancellation, retries, and reload recovery. Adding a React route or button alone does not establish a supported management operation.

Monitoring Separation​

Telemetry descriptors and JMX profiles are compiled into complete per-host assignments. Agent exporters expose current values; metric samples do not travel inside Agent heartbeats. VMAGENT discovers and scrapes targets, then sends samples to VictoriaMetrics.

The metadata database stores datasource and dashboard definitions, not the historical metric samples. Small direct-JMX values needed for management and health checks remain separate from time-series monitoring. See the monitoring architecture.

Security And Recovery​

Ambari API authorization, Agent enrollment/trust, component Kerberos authentication, exporter network access, and datasource credentials are separate boundaries. Configure and verify each one. A monitoring-view permission does not grant service installation or configuration mutation.

Recover failed operations through the Server's request/task state and the workflow's supported retry path. Validate package/database/configuration consistency before rollback, as described in the upgrade guide.

Source References​

See the pinned Server source, Agent source, and React routes.