监控层级

介绍Pigsty监控系统中的层次关系

正如 命名原则 中所介绍,Pigsty中的对象分为多个层次:集群,服务,实例,节点。

监控层级 - 图1

监控系统层次

Pigsty的监控系统中有着更多的层次,除了实例集群这两个最为普遍层次,整个系统中还有着其他层次的组织。自顶向下可以分为7个层级:概览,分片,集群,服务,实例,数据库,对象。

监控层级 - 图2

图:Pigsty的监控面板被划分为7个逻辑层级与5个实现层级

逻辑层次

生产环境的数据库往往是以集群为单位组织的,集群是基本的业务服务单元,也是最为重要的监控层次。

集群是一个由主从复制所关联的一组数据库实例所构成的,实例是最基本的监控层次。

而多套数据库集群共同组成一个现实世界中的生产环境概览(Overview) 层次的监控提供了对整个环境的整体描述。

按照水平拆分的模式服务于同一业务的多个数据库集群称为分片(Shard),分片层次的监控对于定位数据分布、倾斜等问题很有帮助。

服务 是夹在集群与实例中间的层次,服务通常与DNS,域名,VIP,NodePort等资源紧密关联。

数据库(Database) 是亚实例级对象,一个数据库集群/实例可能会同时有多个数据库存在,数据库层面的监控关注单个数据库内的活动。

对象(Object) 是数据库内的实体,包括表,索引,序列号,函数,查询,连接池等,对象层面的监控关注这些对象的统计指标,与业务紧密相关。

层次精简

作为一种精简,正如网络的OSI 7层模型在实际中被简化为TCP/IP五层模型一样,这七个层次也以 集群实例 为界,简化为五个层次: 概览(Overview)集群(Cluster)服务(Service)实例(Instance)数据库(Database)

这样,最终的层次划分也变得十分简洁:所有集群层次以上的信息,都是 概览 层次,所有实例以下的监控都算作 数据库 层次,夹在 集群实例 中间的,就是 服务 层次。

命名规则

分完层次后,最重要的问题就是命名问题:

  1. 需要一种方式来标识、引用系统中不同层次内的各个组件,

  2. 这种命名方式,应当合理地反映出系统中各个实体的层次关系

  3. 这种命名方式,应当可以按照规则自动生成,只有这样,才可以在集群扩容缩容,Failover时做到免维护自动化运行,

当我们理清了系统中存在的层次后,就可以着手为系统中的每个实体起名。

Pigsty所遵循的基本命名规则,请参考 命名原则 一节。

Pigsty使用独立的名称管理机制,实体的命名自成体系。

如果需要与外部系统对接,用户可以直接使用这套命名体系,或通过转接适配的方式采用自己的命名体系。

集群命名

Pigsty的集群名称由用户指定,满足[a-z0-9][a-z0-9-]*的正则表达式,形如pg-testpg-meta

节点命名

Pigsty的节点从属于集群。Pigsty的节点名称由两部分组成:集群名节点编号,并使用-连接。

形式为${pg_cluster}-${pg_seq},例如pg-meta-1pg-test-2

在形式上,节点编号是长度合理的自然数(包括0),在集群范围内唯一,每个节点都有自己的编号。

实例的编号可以由用户显式指定并分配,通常采用从0或1开始分配,一旦分配,在集群生命周期内不再变更

实例命名

Pigsty的实例从属于集群,采用独占节点式部署。

因为实例与节点存在一一对应关系,因此实例名与节点命保持一致。

服务命名

Pigsty的服务从属于集群。Pigsty的服务名称由两部分组成:集群名角色(Role),并使用-连接。

形式为${pg_cluster}-${pg_role},例如pg-meta-primarypg-test-replica

pg_role的可选项包括:primary|replica|offline|delayed

primary是特殊的角色,每个集群必须,且只能定义一个pg_role = primary的实例作为主库。

其他的角色大体上由用户定义,其中replica|offline|delayed 是Pigsty预定义的角色。

接下来?

划分好监控的层级后,需要对为监控对象赋予身份,方能进行管理。

最后修改 2022-05-27: init commit (1e3e284)