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

其中metatags部分是服务的元数据,存储有实例的身份信息

服务查询

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

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

Identity Management - 图3

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

服务发现

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

  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. #==============================================================#
  9. #======> pg-meta-1 [primary]
  10. - labels: {cls: pg-meta, ins: pg-meta-1, ip: 10.10.10.10, role: primary, svc: pg-meta-primary}
  11. targets: [10.10.10.10:9630, 10.10.10.10:9100, 10.10.10.10:9631, 10.10.10.10:9101]
  12. #======> pg-test-1 [primary]
  13. - labels: {cls: pg-test, ins: pg-test-1, ip: 10.10.10.11, role: primary, svc: pg-test-primary}
  14. targets: [10.10.10.11:9630, 10.10.10.11:9100, 10.10.10.11:9631, 10.10.10.11:9101]
  15. #======> pg-test-2 [replica]
  16. - labels: {cls: pg-test, ins: pg-test-2, ip: 10.10.10.12, role: replica, svc: pg-test-replica}
  17. targets: [10.10.10.12:9630, 10.10.10.12:9100, 10.10.10.12:9631, 10.10.10.12:9101]
  18. #======> pg-test-3 [replica]
  19. - labels: {cls: pg-test, ins: pg-test-3, ip: 10.10.10.13, role: replica, svc: pg-test-replica}
  20. 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)