E-R Model of Infra Cluster

The INFRA module is a management hub made of infrastructure nodes, rather than a traditional cluster. It provides core services for the deployment. Each node is an autonomous service unit that runs components such as Nginx, Grafana, and VictoriaMetrics. Together, these nodes provide observability and management for database clusters.

There are two core entities in Pigsty’s INFRA module:

• Node: A server that runs infrastructure components. It can be a physical server, VM, container, or Pod.
• Component: An infrastructure service on a node, such as Nginx, Grafana, or VictoriaMetrics.

INFRA nodes usually also serve as administration nodes, which form the Pigsty control plane.

Component Composition

Each INFRA node runs the following core components:

These components together form Pigsty’s observability infrastructure.

Examples

This example defines a two-node INFRA deployment:

infra:
  hosts:
    10.10.10.10: { infra_seq: 1 }
    10.10.10.11: { infra_seq: 2 }

The configuration defines these entities:

For production, use at least two INFRA nodes for component redundancy.

Identity Parameters

The INFRA_ID parameter group assigns deterministic identities to INFRA entities. One parameter is required:

Set the node sequence number at node level. Pigsty generates unique identifiers with these rules:

INFRA assigns infra-N identifiers to distinguish infrastructure nodes in monitoring. This does not change their hostname or system identity. Nodes retain their existing hostname or IP address for identification.

Service Portal

INFRA nodes provide web access through Nginx. infra_portal defines the services that Nginx exposes.

The default configuration only defines the home server:

infra_portal:
  home : { domain: i.pigsty }

Pigsty configures reverse proxy endpoints for enabled components, including Grafana, VictoriaMetrics, and AlertManager. To access them through separate domains, add explicit configuration:

infra_portal:
  home         : { domain: i.pigsty }
  grafana      : { domain: g.pigsty, endpoint: "${admin_ip}:3000", websocket: true }
  prometheus   : { domain: p.pigsty, endpoint: "${admin_ip}:8428" }   # VMUI
  alertmanager : { domain: a.pigsty, endpoint: "${admin_ip}:9059" }

Use domain names to access Pigsty services where possible, instead of an IP address and port.

Deployment Scale

The number of INFRA nodes depends on deployment scale and HA requirements:

In a single-node deployment, INFRA shares a node with PGSQL, ETCD, and other modules. Small deployments usually use INFRA nodes as the administration node, backup administration node, and local software repository (/www/pigsty). Larger deployments can assign these responsibilities to dedicated nodes.

Monitoring Label System

Pigsty collects metrics from INFRA components themselves. Unlike database modules, INFRA treats each component as a separate monitoring object. The cls (class) label distinguishes component types.

A two-node INFRA deployment with infra_seq: 1 and infra_seq: 2 uses these component labels:

All INFRA component metrics have job="infra". The cls label distinguishes components:

nginx_up{cls="nginx", ins="nginx-1", ip="10.10.10.10", job="infra"}
grafana_info{cls="grafana", ins="grafana-1", ip="10.10.10.10", job="infra"}
vm_app_version{cls="vmetrics", ins="vmetrics-1", ip="10.10.10.10", job="infra"}
vlogs_rows_ingested_total{cls="vlogs", ins="vlogs-1", ip="10.10.10.10", job="infra"}
alertmanager_alerts{cls="alertmanager", ins="alertmanager-1", ip="10.10.10.10", job="infra"}