如果用户只希望使用Pigsty的监控系统部分，比如希望使用Pigsty监控系统监控已有的PostgreSQL实例，那么可以使用 仅监控部署（monitor only） 模式。
仅监控模式的部署流程与标准模式大体上保持一致，但省略了很多步骤
- 在元节点上完成基础设施初始化的部分，与标准流程一致。
- 修改配置文件，在仅监控模式中，通常只需要修改监控系统部分的参数。
- 使用专用的剧本在数据库节点上完成仅监控部署，
./pgsql-monitor.yml。
部署说明
监控用户
Pigsty在 PG供给 的阶段会创建监控用户，仅监控模式跳过了这些步骤，因此用户需要自行创建用于监控的用户。
用户需要自行在目标数据库集群上创建监控用户，并创建重要的监控模式与扩展（只有pg_stat_statements是必选项）。在待监控数据库实例上执行以下SQL以创建监控用户。
-- 创建监控用户
CREATE USER "dbuser_monitor" ;
ALTER ROLE "dbuser_monitor" PASSWORD 'DBUser.Monitor';
ALTER USER "dbuser_monitor" CONNECTION LIMIT 16;
GRANT "pg_monitor" TO "dbuser_monitor";
GRANT "dbrole_readonly" TO "dbuser_monitor";
-- 创建监控模式与扩展
CREATE SCHEMA IF NOT EXISTS monitor;
GRANT USAGE ON SCHEMA monitor TO "dbuser_monitor";
CREATE EXTENSION IF NOT EXISTS "pg_stat_statements" WITH SCHEMA "monitor";
-- 额外的监控函数，用于监控共享内存指标，只有PG13及以上版本才需要。
CREATE OR REPLACE FUNCTION monitor.pg_shmem() RETURNS SETOF
pg_shmem_allocations AS $$ SELECT * FROM pg_shmem_allocations;$$ LANGUAGE SQL SECURITY DEFINER;
COMMENT ON FUNCTION monitor.pg_shmem() IS 'security wrapper for pg_shmem';
监控连接串
默认情况下，Pigsty会尝试使用以下规则生成数据库与连接池的连接串。
PG_EXPORTER_URL='postgres://{{ pg_monitor_username }}:{{ pg_monitor_password }}@:{{ pg_port }}/{{ pg_default_database }}?host={{ pg_localhost }}&sslmode=disable'
PGBOUNCER_EXPORTER_URL='postgres://{{ pg_monitor_username }}:{{ pg_monitor_password }}@:{{ pgbouncer_port }}/pgbouncer?host={{ pg_localhost }}&sslmode=disable'
如果用户使用的监控角色连接串无法通过该规则生成，则可以使用以下参数直接配置数据库与连接池的连接信息：
作为样例，沙箱环境中元节点连接至数据库的连接串为：
PG_EXPORTER_URL='postgres://dbuser_monitor:DBUser.Monitor@:5432/meta?host=/var/run/postgresql&sslmode=disable'
懒人方案
如果不怎么关心安全性与权限，也可以直接使用dbsu ident认证的方式，例如
postgres用户进行监控。
pg_exporter默认以dbsu的用户执行，如果允许dbsu通过本地ident认证免密访问数据库（Pigsty默认配置），则可以直接使用超级用户监控数据库。Pigsty非常不推荐这种部署方式，但它确实很方便，既不用创建新用户，也不用配置权限。PG_EXPORTER_URL='postgres:///postgres?host=/var/run/postgresql&sslmode=disable'
相关参数
使用仅监控部署时，只会用到Pigsty参数的一个子集。
基础设施部分
基础设施与元节点仍然与常规部署保持一致，除了以下两个参数必须强制使用指定的配置选项。
service_registry: none # 须关闭服务注册，因为目标环境可能没有DCS基础设施。
prometheus_sd_method: static # 须使用静态文件服务发现，因为目标实例可能并没有使用服务发现与服务注册
目标节点部分
目标节点的身份参数仍然为必选项，除此之外，通常只有监控系统参数需要调整。
---
#------------------------------------------------------------------------------
# MONITOR PROVISION
#------------------------------------------------------------------------------
# - install - #
exporter_install: none # none|yum|binary, none by default
exporter_repo_url: '' # if set, repo will be added to /etc/yum.repos.d/ before yum installation
# - collect - #
exporter_metrics_path: /metrics # default metric path for pg related exporter
# - node exporter - #
node_exporter_enabled: true # setup node_exporter on instance
node_exporter_port: 9100 # default port for node exporter
node_exporter_options: '--no-collector.softnet --collector.systemd --collector.ntp --collector.tcpstat --collector.processes'
# - pg exporter - #
pg_exporter_config: pg_exporter-demo.yaml # default config files for pg_exporter
pg_exporter_enabled: true # setup pg_exporter on instance
pg_exporter_port: 9630 # default port for pg exporter
pg_exporter_url: '' # optional, if not set, generate from reference parameters
# - pgbouncer exporter - #
pgbouncer_exporter_enabled: true # setup pgbouncer_exporter on instance (if you don't have pgbouncer, disable it)
pgbouncer_exporter_port: 9631 # default port for pgbouncer exporter
pgbouncer_exporter_url: '' # optional, if not set, generate from reference parameters
# - postgres variables reference - #
pg_dbsu: postgres
pg_port: 5432 # postgres port (5432 by default)
pgbouncer_port: 6432 # pgbouncer port (6432 by default)
pg_localhost: /var/run/postgresql # localhost unix socket dir for connection
pg_default_database: postgres # default database will be used as primary monitor target
pg_monitor_username: dbuser_monitor # system monitor username, for postgres and pgbouncer
pg_monitor_password: DBUser.Monitor # system monitor user's password
service_registry: consul # none | consul | etcd | both
...
通常来说，需要调整的参数包括：
exporter_install: binary # none|yum|binary 建议使用拷贝二进制的方式安装Exporter
pgbouncer_exporter_enabled: false # 如果目标实例没有关联的Pgbouncer实例，则需关闭Pgbouncer监控
pg_exporter_url: '' # 连接至 Postgres 的URL，如果不采用默认的URL拼合规则，则可使用此参数
pgbouncer_exporter_url: '' # 连接至 Pgbouncer 的URL，如果不采用默认的URL拼合规则，则可使用此参数
局限性
Pigsty监控系统 与 Pigsty供给方案 配合紧密，原装的总是最好的。尽管Pigsty并不推荐拆分使用，但这样做确实是可行的，只是存在一些局限性。
指标缺失
Pigsty会集成多种来源的指标，包括机器节点，数据库，Pgbouncer连接池，Haproxy负载均衡器。如果用户自己的供给方案中缺少这些组件，则相应指标也会发生缺失。
通常Node与PG的监控指标总是存在，而PGbouncer与Haproxy的缺失通常会导致100～200个不等的指标损失。
特别是，Pgbouncer监控指标中包含极其重要的PG QPS，TPS，RT，而这些指标是无法从PostgreSQL本身获取的。
工作假设
Pigsty监控系统 如果要与外部供给方案配合，监控已有数据库集群，需要一些工作假设：
- 数据库采用独占式部署，与节点存在一一对应关系。只有这样，节点指标才能有意义地与数据库指标关联。
- 目标节点可以被Ansible管理（NOPASS SSH与NOPASS SUDO），一些云厂商RDS产品并不允许这样做。
- 数据库需要创建可用于访问监控指标的监控用户，安装必须的监控模式与扩展，并合理配置其访问控制权限。
服务发现
外部供给方案通常拥有自己的身份管理机制，因此Pigsty不会越俎代庖地部署DCS用于服务发现。这意味着用户只能采用 静态配置文件 的方式管理监控对象的身份，通常这并不是一个问题。
在Pigsty沙箱中，当实例的角色身份发生变化时，系统会通过回调函数与反熵过程及时修正实例的角色信息，如将primary修改为replica，将其他角色修改为primary。
pg_up{cls="pg-meta", ins="pg-meta-1", instance="10.10.10.10:9630", ip="10.10.10.10", job="pg", role="primary", svc="pg-meta-primary"}
但与外部供给方案集成时，除非用户显式通知或回调 监控系统，根据最新角色定义生成配置文件，否则监控系统无法意识到主从发生了切换。上面的样例监控指标中，role与svc标签会因为不及时的角色调整受到影响，这意味着Service级别的监控数据准确性会受到影响（即pg:svc:*系列指标，例如服务的QPS）。但其他层次的监控指标与图表不受主从切换影响，因此影响不大，且有其他办法解决。
管理权限
Pigsty的监控指标依赖 node_exporter 与 pg_exporter 获取。
尽管pg_exporter可以采用exporter拉取远程数据库实例信息的方式部署，但node_exporter必须部署在数据库所属的节点上。
这意味着，用户必须拥有数据库所在机器的SSH登陆与sudo权限才能完成部署。换句话说，目标节点必须可以被Ansible纳入管理，而云厂商RDS通常不会给出此类权限。