INFRA 集群模型

INFRA 模块在 Pigsty 中承担着特殊的角色：它不是传统意义上的"集群"，而是由一组 基础设施节点 构成的管理中枢，为整个 Pigsty 部署提供核心服务。 每个 INFRA 节点都是一个自治的基础设施服务单元，运行着 Nginx、Grafana、VictoriaMetrics 等核心组件，共同为纳管的数据库集群提供可观测性与管理能力。

在 Pigsty 的 INFRA 模块中有两种核心实体：

• 节点（Node）：运行基础设施组件的服务器，可以是裸机、VM、容器或 Pod。
• 组件（Component）：在节点上运行的各类基础设施服务，如 Nginx、Grafana、VictoriaMetrics 等。

INFRA 节点通常承担管理节点（Admin Node）的角色，是 Pigsty 的控制平面所在。

组件构成

每个 INFRA 节点上运行着以下核心组件：

这些组件共同构成了 Pigsty 的可观测性基础设施。

具体样例

让我们来看一个具体的例子，以双节点的 INFRA 部署为例：

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

上面的配置片段定义了一个双节点的 INFRA 部署：

在生产环境中，建议部署至少两个 INFRA 节点，以实现基础设施组件的冗余。

身份参数

Pigsty 使用 INFRA_ID 参数组为 INFRA 模块的每个实体赋予确定的身份。以下一项为必选参数：

只要在节点层面分配了节点序号，Pigsty 就能自动根据规则为每个实体生成唯一标识符。

INFRA 模块会为节点赋予 infra-N 形式的标识，用于监控系统中区分多个基础设施节点。 但这并不改变节点本身的主机名或系统身份，节点仍然使用其原有的主机名或 IP 地址进行标识。

服务门户

INFRA 节点通过 Nginx 提供统一的 Web 服务入口。infra_portal 参数定义了通过 Nginx 暴露的服务列表：

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" }

用户通过访问不同的域名，Nginx 会将请求路由到对应的后端服务：

建议通过域名访问 Pigsty 服务，而不是直接使用 IP + 端口的方式。

部署规模

INFRA 节点的数量取决于部署规模和高可用需求：

单机部署 时，INFRA 组件与 PGSQL、ETCD 等模块共用同一个节点。 通常在小规模部署中，INFRA 节点通常还承担着 “管理节点” / “备用管理节点”，以及本地软件仓库（/www/pigsty）的角色。 在更大规模的部署中，这些职责可以剥离至专用节点。

监控标签体系

Pigsty 的监控系统会采集 INFRA 组件自身的指标。与数据库模块不同，INFRA 模块的每个组件都被视为独立的监控对象，通过 cls（类）标签区分不同组件类型。

以双节点 INFRA 部署（infra_seq: 1 和 infra_seq: 2）为例，各组件的监控标签如下：

所有 INFRA 组件的监控指标都使用统一的 job="infra" 标签，通过 cls 标签区分组件类型：

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"}