Identity Management

How does pigsty manage identity of monitoring targets

所有的实例都具有身份（Identity），身份信息是与实例关联的元数据，用于标识实例。

Identity Management - 图1

图：使用Consul服务发现时，Postgres服务带有的身份信息

身份参数

身份参数是任何集群与实例都必须定义的唯一标识符。

名称变量类型说明
集群pg_cluster核心身份参数集群名称，集群内资源的顶层命名空间
角色pg_role核心身份参数实例角色，primary, replica, offline,…
标号pg_seq核心身份参数实例序号，正整数，集群内唯一。
实例pg_instance衍生身份参数${pg_cluster}-${pg_seq}
服务pg_service衍生身份参数${pg_cluster}-${pg_role}

身份关联

为系统中的对象命名后，还需要将 身份信息 关联至具体的实例上。

身份信息属于业务赋予的元数据，数据库实例本身不会意识到这些身份信息，它不知道自己为谁而服务，从属于哪个业务，或者自己是集群中的几号实例。

身份赋予可以有多种形式，最朴素的身份关联方式就是运维人员的记忆：DBA在脑海中记住了IP地址为10.2.3.4上的数据库实例，是用于支付的实例，而另一台上的数据库实例则用于用户管理。更好的管理方式是通过配置文件，或者采用服务发现的方式来管理集群成员的身份。

Pigsty同时提供这两种身份管理的方式：基于Consul的服务发现，与基于配置文件的服务发现

参数 prometheus_sd_method (consul|static) 控制这一行为：

  • consul：基于Consul进行服务发现，默认配置
  • static：基于本地配置文件进行服务发现

Pigsty建议使用consul服务发现，当服务器发生Failover时，监控系统会自动更正目标实例所注册的身份。

Consul服务发现

Pigsty默认采用 Consul服务发现的方式管理环境中的服务。

Pigsty内置了基于DCS的配置管理与自动服务发现，用户可以直观地察看系统中的所有节点与服务信息，以及健康状态。Pigsty中的所有服务都会自动注册至DCS中，因此创建、销毁、修改数据库集群时，元数据会自动修正，监控系统能够自动发现监控目标，无需手动维护配置。

用户亦可通过Consul提供的DNS与服务发现机制，实现基于DNS的自动流量切换。

Identity Management - 图2

Consul采用了Client/Server架构，整个环境中存在1～5个不等的Consul Server，用于实际的元数据存储。所有节点上都部署有Consul Agent，代理本机服务与Consul Server的通信。Pigsty默认通过本地Consul配置文件的方式注册服务。

服务注册

在每个节点上，都运行有 consul agent。服务通过JSON配置文件的方式，由consul agent注册至DCS中。

JSON配置文件的默认位置是/etc/consul.d/，采用svc-<service>.json的命名规则，以postgres为例：

  1. {
  2.   "service": {
  3.     "name": "postgres",
  4.     "port": {{ pg_port }},
  5.     "tags": [
  6.       "{{ pg_role }}",
  7.       "{{ pg_cluster }}"
  8.     ],
  9.     "meta": {
  10.       "type": "postgres",
  11.       "role": "{{ pg_role }}",
  12.       "seq": "{{ pg_seq }}",
  13.       "instance": "{{ pg_instance }}",
  14.       "service": "{{ pg_service }}",
  15.       "cluster": "{{ pg_cluster }}",
  16.       "version": "{{ pg_version }}"
  17.     },
  18.     "check": {
  19.       "tcp": "127.0.0.1:{{ pg_port }}",
  20.       "interval": "15s",
  21.       "timeout": "1s"
  22.     }
  23.   }
  24. }

其中meta与tags部分是服务的元数据，存储有实例的身份信息。

服务查询

用户可以通过Consul提供的DNS服务，或者直接调用Consul API发现注册到Consul中的服务

使用DNS API查阅consul服务的方式，请参阅Consul文档。

Identity Management - 图3

图：查询pg-bench-1上的 pg_exporter 服务。

服务发现

Prometheus会自动通过consul_sd_configs发现环境中的监控对象。同时带有pg和exporter标签的服务会自动被识别为抓取对象：

  1. - job_name: pg
  2.   # https://prometheus.io/docs/prometheus/latest/configuration/configuration/#consul_sd_config
  3.   consul_sd_configs:
  4.     - server: localhost:8500
  5.       refresh_interval: 5s
  6.       tags:
  7.         - pg
  8.         - exporter

Identity Management - 图4

图：被Prometheus发现的服务，身份信息已关联至实例的指标维度上。

服务维护

有时候，因为数据库主从发生切换，导致注册的角色与数据库实例的实际角色出现偏差。这时候需要通过反熵过程处理这种异常。

基于Patroni的故障切换可以正常地通过回调逻辑修正注册的角色，但人工完成的角色切换则需要人工介入处理。

使用以下脚本可以自动检测并修复数据库的服务注册。建议在数据库实例上配置Crontab，或在元节点上设置定期巡检任务。

  1. /pg/bin/pg-register $(pg-role)

静态文件服务发现

static服务发现依赖/etc/prometheus/targets/*.yml中的配置进行服务发现。采用这种方式的优势是不依赖Consul。

当Pigsty监控系统与外部管控方案集成时，这种模式对原系统的侵入性较小。但是缺点是，当集群内发生主从切换时，用户需要自行维护实例角色信息。手动维护时，可以根据以下命令从配置文件生成Prometheus所需的监控对象配置文件并载入生效。

详见 Prometheus服务发现。

  1. ./infra.yml --tags=register_prometheus
  2. ./nodes.yml --tags=register_prometheus
  3. ./pgsql.yml --tags=register_prometheus
  4. ./redis.yml --tags=register_prometheus
  5. ./infra.yml --tags=prometheus_config,prometheus_reload

Pigsty默认生成的静态监控对象文件示例如下：

  1. #==============================================================#
  2. # File      :   targets/all.yml
  3. # Ctime     :   2021-02-18
  4. # Mtime     :   2021-02-18
  5. # Desc      :   Prometheus Static Monitoring Targets Definition
  6. # Path      :   /etc/prometheus/targets/all.yml
  7. # Copyright (C) 2018-2021 Ruohang Feng
  8. #==============================================================#
  10. #======> pg-meta-1 [primary]
  11. - labels: {cls: pg-meta, ins: pg-meta-1, ip: 10.10.10.10, role: primary, svc: pg-meta-primary}
  12.   targets: [10.10.10.10:9630, 10.10.10.10:9100, 10.10.10.10:9631, 10.10.10.10:9101]
  14. #======> pg-test-1 [primary]
  15. - labels: {cls: pg-test, ins: pg-test-1, ip: 10.10.10.11, role: primary, svc: pg-test-primary}
  16.   targets: [10.10.10.11:9630, 10.10.10.11:9100, 10.10.10.11:9631, 10.10.10.11:9101]
  18. #======> pg-test-2 [replica]
  19. - labels: {cls: pg-test, ins: pg-test-2, ip: 10.10.10.12, role: replica, svc: pg-test-replica}
  20.   targets: [10.10.10.12:9630, 10.10.10.12:9100, 10.10.10.12:9631, 10.10.10.12:9101]
  22. #======> pg-test-3 [replica]
  23. - labels: {cls: pg-test, ins: pg-test-3, ip: 10.10.10.13, role: replica, svc: pg-test-replica}
  24.   targets: [10.10.10.13:9630, 10.10.10.13:9100, 10.10.10.13:9631, 10.10.10.13:9101]

身份关联

无论是通过Consul服务发现，还是静态文件服务发现。最终的效果是实现身份信息与实例监控指标相互关联。

这一关联，是通过 监控指标 的维度标签实现的。

身份参数维度标签取值样例
pg_clusterclspg-test
pg_instanceinspg-test-1
pg_servicessvcpg-test-primary
pg_roleroleprimary
node_ipip10.10.10.11

Identity Management - 图5

阅读下一节 监控指标 ，了解这些指标是如何通过标签组织起来的。

Last modified 2022-06-04: fill en docs (5a858d3)