PMM Managed Backend
Relevant source files
The following files were used as context for generating this wiki page:
PMM Managed (pmm-managed) is a core backend component of the Percona Monitoring and Management (PMM) Server. It is responsible for managing the configuration of various PMM server components, such as VictoriaMetrics and Grafana, and providing a unified API for internal and external management tasks. It acts as the orchestration layer that bridges user configurations with the underlying monitoring infrastructure.
Sources: CONTRIBUTING.md:25-27, managed/CONTRIBUTING.md:3-5
The module serves as the primary backend for the pmm-admin tool and the PMM User Interface, exposing endpoints for system settings, updates, inventory management, and security controls. It is designed to run within the PMM Server container and interacts with a PostgreSQL database for persistent storage of configuration and metadata.
Sources: CONTRIBUTING.md:25-27, managed/CONTRIBUTING.md:32-34
Architecture and Component Structure
The pmm-managed backend is structured into logical directories that separate API definitions, business logic (services), and data persistence (models).
Internal Directory Layout
The following table describes the primary directory structure of the managed backend:
| Directory | Description |
|---|---|
bin | Contains compiled binaries. |
cmd | Entry points for scripts and the main application. |
data | Alerting templates and auto-generated code. |
models | Database types and helpers; includes the schema in database.go. |
services | API implementations for internal services (e.g., checks, VictoriaMetrics). |
testdata | Static files used for unit testing. |
utils | Shared utility functions. |
Sources: managed/CONTRIBUTING.md:216-224
System Relationships
The following diagram illustrates how the Managed Backend interacts with other PMM components:
The diagram shows pmm-managed as the central orchestrator within the PMM Server container, interacting with the database, monitoring engines, and external clients.
Sources: CONTRIBUTING.md:25-35, README.md:39-41, managed/CONTRIBUTING.md:32-34
Core Services and API
The backend exposes the ServerService, which provides generic management APIs for the PMM Server. These are defined via Protocol Buffers and exposed as both gRPC and REST endpoints.
Server Management Endpoints
Key API operations available through the Managed backend include:
| Endpoint | Method | Description |
|---|---|---|
/v1/server/version | GET | Returns versions for PMM Server and pmm-managed. |
/v1/server/readyz | GET | Health check for container and Kubernetes readiness. |
/v1/server/settings | GET/PUT | Retrieves or modifies global PMM configurations. |
/v1/server/updates | GET | Checks for available PMM Server updates. |
/v1/server/updates:start | POST | Initiates the PMM Server update process. |
Sources: api/server/v1/server.proto:238-305, api/server/v1/server.swagger.json:17-180
Settings and Configuration
The Settings data structure controls the functional state of the PMM environment. Users can toggle specific features to conserve system resources.
Key configuration fields include:
metrics_resolutions: Defines High (hr), Medium (mr), and Low (lr) resolution intervals for Prometheus.data_retention: Duration for which Prometheus and QAN data is kept.enable_advisor: Toggles the Advisor service for security and performance checks.enable_alerting: Toggles the Percona Alerting engine.enable_access_control: Controls Label-Based Access Control (LBAC).
Sources: api/server/v1/server.proto:159-181, ui/apps/pmm/src/pages/settings/Settings.messages.ts:31-75
Feature Management Systems
Advisor Service
The backend manages "Advisors," which are automated checks that analyze database environments for security threats and performance issues.
The flow shows the lifecycle of an Advisor check from scheduling to display.
Sources: managed/CONTRIBUTING.md:126-150, api/server/v1/server.proto:148-156
Update Orchestration
The backend handles the complexity of updating PMM Server components. It provides asynchronous status reporting during the update process.
The sequence illustrates the polling mechanism used by the UI to track update progress.
Sources: api/server/v1/server.proto:106-134, api/server/v1/server.swagger.json:115-160
Development and Testing Environment
Development of the backend occurs primarily within a "devcontainer" to ensure consistency with the PMM Server filesystem and dependencies.
Environment Variables
Developers can control backend behavior using specific variables:
| Variable | Description | Default |
|---|---|---|
PMM_DEV_TELEMETRY_INTERVAL | Reporting interval for telemetry. | 24h |
PMM_DEV_ADVISOR_STARLARK_ALLOW_RECURSION | Enables recursive functions in checks. | false |
PMM_ADVISOR_CHECKS_DISABLE_START_DELAY | Bypasses startup delay for checks. | false |
PMM_DEV_PERCONA_PLATFORM_ADDRESS | Target address for platform services. | https://check.percona.com |
Sources: managed/CONTRIBUTING.md:65-75
Implementation Details
- Database: Uses
pmm-managedPostgreSQL database for production andpmm-managed-devfor unit tests. - Service Management: Uses
supervisorctlto manage and restart backend processes during development cycles (via therun-managedtarget). - Communication: Interacts with
pmm-agentvia a secure channel to manage exporters and collect metrics resolution settings.
Sources: managed/CONTRIBUTING.md:46-55, api/server/v1/server.proto:137-145