Ambari Design

Ambari 3.1 retains cluster provisioning and management while replacing its monitoring backend and primary Web UI. This section describes the current management contracts, not an archived installation recipe.

System Boundaries

Start with the overall architecture and technology stack. Ambari Server owns topology, authorization, desired configuration, and operation records. Agents execute host-level work. React presents the management workflows. Monitoring has a separate scrape/storage/query data plane.

Provisioning And Security

Blueprints describe logical host groups and configuration for repeatable cluster deployment. The template maps those groups to real hosts; inspect asynchronous request state rather than assuming that successful submission means installation has finished.

Kerberos adds identity, keytab, and service-configuration management. Its descriptors and KDC settings remain management contracts even when time-series monitoring no longer uses AMS.

Stack And Service Contracts

Stack definitions declare supported services, components, packages, commands, configuration, dependencies, and upgrade behavior. Inheritance and common-service reuse avoid duplicating complete service definitions.

Enhanced Configs use service Themes for configuration forms. These form controls are not the removed monitoring widgets. Quick links resolve service endpoints from installed topology and configuration.

Operational Feedback And Extensions

Alerts are Ambari health checks and notifications. Do not assume that installing VictoriaMetrics also installs Prometheus Alertmanager.

Views extend Ambari through server-managed view definitions, instances, permissions, and embedded applications. See the extension overview before choosing an integration boundary.

For historical time-series data, dashboards, and PromQL, use the dedicated monitoring architecture and service telemetry guide.