服务发现
所有的服务都有身份，例如，所属的集群，集群内的唯一标识，在集群中扮演的角色。等等。
身份管理
当我们为系统设计好命名规则与模式后，第二个问题，就是如何将身份赋予/关联数据库实例。
数据库本身并不知道自己为谁而服务。属于哪个业务，是集群中的几号实例。因此在生产环境大规模集群管理中，我们必须为数据库实例赋予身份。
身份赋予可以有多种形式，例如人肉死记硬背也是一种身份赋予，管理员在脑海中记住了10.20.30.40 IP地址上的数据库实例是用于支付的，而另一台上的数据库实例则用于订单。
更好的方式是通过配置文件，或者更进一步，服务发现的方式来管理集群成员的身份。将身份信息注册到监控系统中是系统自动运行的重要环节，这一步与Kubernetes往etcd中写元数据类似。
Pigsty提供两种身份管理的方式：基于服务发现（Consul/etcd），与基于配置文件。
参考配置：prometheus_sd_method
Prometheus使用的服务发现机制，默认为consul，可选项：
consul：基于Consul进行服务发现static：基于本地配置文件进行服务发现
Pigsty建议使用consul服务发现，当服务器发生Failover时，监控系统会自动更正目标实例所注册的身份。
基于Consul的服务发现
Pigsty内置了基于DCS的配置管理与自动服务发现，用户可以直观地察看系统中的所有节点与服务信息，以及健康状态。Pigsty中的所有服务都会自动注册至DCS中，因此创建、销毁、修改数据库集群时，元数据会自动修正，监控系统能够自动发现监控目标，无需手动维护配置。
目前仅支持Consul作为DCS，用户亦可通过Consul提供的DNS与服务发现机制，实现基于DNS的自动流量切换。后续会提供etcd的完整支持，但下面的介绍都将基于consul进行。
注册
在每个节点上，都运行有 consul agent。服务通过JSON配置文件的方式，由consul agent注册至DCS中。
JSON配置文件的默认位置是/etc/consul.d/，采用svc-<service>.json的命名规则，以postgres为例：
{
"service": {
"name": "postgres",
"port": {{ pg_port }},
"tags": [
"{{ pg_role }}",
"{{ pg_cluster }}"
],
"meta": {
"type": "postgres",
"role": "{{ pg_role }}",
"seq": "{{ pg_seq }}",
"instance": "{{ pg_instance }}",
"service": "{{ pg_service }}",
"cluster": "{{ pg_cluster }}",
"version": "{{ pg_version }}"
},
"check": {
"tcp": "127.0.0.1:{{ pg_port }}",
"interval": "15s",
"timeout": "1s"
}
}
}
查询
您可以通过Consul提供的DNS服务，或者直接调用Consul API实现服务发现。注册到Consul中的服务
使用DNS API查阅consul服务的方式请参阅Consul文档。
发现
Prometheus会自动通过consul_sd_configs发现环境中的监控对象。同时带有pg和exporter标签的服务会自动被识别为抓取对象：
- job_name: pg
# https://prometheus.io/docs/prometheus/latest/configuration/configuration/#consul_sd_config
consul_sd_configs:
- server: localhost:8500
refresh_interval: 5s
tags:
- pg
- exporter
被Prometheus发现的服务
Prometheus会自动通过consul_sd_configs发现环境中的监控对象。同时带有pg和exporter标签的服务会自动被识别为抓取对象：
- job_name: pg
# https://prometheus.io/docs/prometheus/latest/configuration/configuration/#consul_sd_config
consul_sd_configs:
- server: localhost:8500
refresh_interval: 5s
tags:
- pg
- exporter
维护
有时候，因为数据库主从发生切换，导致注册的角色与数据库实例的实际角色出现偏差。这时候需要通过反熵过程处理这种异常。
基于Patroni的故障切换可以正常地通过回调逻辑修正注册的角色，但人工完成的角色切换则需要人工介入处理。
使用以下脚本可以自动检测并修复数据库的服务注册。建议在数据库实例上配置Crontab，定期检测并修正服务。
/pg/bin/pg-register $(pg-role)
基于静态文件的服务发现
static服务发现依赖/etc/prometheus/targets/*.yml中的配置进行服务发现。采用这种方式的优势是不依赖Consul。
当Pigsty监控系统与外部管控方案集成时，这种模式对原系统的侵入性较小。
但是缺点是，当集群内发生主从切换时，您需要自行维护实例角色信息。
手动维护时，可以根据以下命令从配置文件生成Prometheus所需的监控对象配置文件并载入生效。
./infra.yml --tags=prometheus_targtes,prometheus_reload
Pigsty默认生成的静态监控对象文件示例如下：
#==============================================================#
# File : targets/all.yml
# Ctime : 2021-02-18
# Mtime : 2021-02-18
# Desc : Prometheus Static Monitoring Targets Definition
# Path : /etc/prometheus/targets/all.yml
# Copyright (C) 2018-2021 Ruohang Feng
#==============================================================#
#======> pg-meta-1 [primary]
- labels: {cls: pg-meta, ins: pg-meta-1, ip: 10.10.10.10, role: primary, svc: pg-meta-primary}
targets: [10.10.10.10:9630, 10.10.10.10:9100, 10.10.10.10:9631, 10.10.10.10:9101]
#======> pg-test-1 [primary]
- labels: {cls: pg-test, ins: pg-test-1, ip: 10.10.10.11, role: primary, svc: pg-test-primary}
targets: [10.10.10.11:9630, 10.10.10.11:9100, 10.10.10.11:9631, 10.10.10.11:9101]
#======> pg-test-2 [replica]
- labels: {cls: pg-test, ins: pg-test-2, ip: 10.10.10.12, role: replica, svc: pg-test-replica}
targets: [10.10.10.12:9630, 10.10.10.12:9100, 10.10.10.12:9631, 10.10.10.12:9101]
#======> pg-test-3 [replica]
- labels: {cls: pg-test, ins: pg-test-3, ip: 10.10.10.13, role: replica, svc: pg-test-replica}
targets: [10.10.10.13:9630, 10.10.10.13:9100, 10.10.10.13:9631, 10.10.10.13:9101]
接下来
将数据库服务注册至DCS后，我们为每个实例赋予了身份信息，因此可以将监控指标与实例的身份关联起来。
阅读下一节 监控指标 了解Pigsty提供的监控指标，以及这些指标是如何通过标签组织起来的。