监控层级
正如 命名原则 中所介绍,Pigsty中的对象分为多个层次:集群,服务,实例,节点。
监控系统层次
Pigsty的监控系统中有着更多的层次,除了实例与集群这两个最为普遍层次,整个系统中还有着其他层次的组织。自顶向下可以分为7个层级:概览,分片,集群,服务,实例,数据库,对象。
图:Pigsty的监控面板被划分为7个逻辑层级与5个实现层级
逻辑层次
生产环境的数据库往往是以集群为单位组织的,集群是基本的业务服务单元,也是最为重要的监控层次。
集群是一个由主从复制所关联的一组数据库实例所构成的,实例是最基本的监控层次。
而多套数据库集群共同组成一个现实世界中的生产环境,概览(Overview) 层次的监控提供了对整个环境的整体描述。
按照水平拆分的模式服务于同一业务的多个数据库集群称为分片(Shard),分片层次的监控对于定位数据分布、倾斜等问题很有帮助。
服务 是夹在集群与实例中间的层次,服务通常与DNS,域名,VIP,NodePort等资源紧密关联。
数据库(Database) 是亚实例级对象,一个数据库集群/实例可能会同时有多个数据库存在,数据库层面的监控关注单个数据库内的活动。
对象(Object) 是数据库内的实体,包括表,索引,序列号,函数,查询,连接池等,对象层面的监控关注这些对象的统计指标,与业务紧密相关。
层次精简
作为一种精简,正如网络的OSI 7层模型在实际中被简化为TCP/IP五层模型一样,这七个层次也以 集群 和 实例 为界,简化为五个层次: 概览(Overview) ,集群(Cluster) , 服务(Service),实例(Instance) ,数据库(Database) 。
这样,最终的层次划分也变得十分简洁:所有集群层次以上的信息,都是 概览 层次,所有实例以下的监控都算作 数据库 层次,夹在 集群 与 实例 中间的,就是 服务 层次。
命名规则
分完层次后,最重要的问题就是命名问题:
-
需要一种方式来标识、引用系统中不同层次内的各个组件,
-
这种命名方式,应当合理地反映出系统中各个实体的层次关系
-
这种命名方式,应当可以按照规则自动生成,只有这样,才可以在集群扩容缩容,Failover时做到免维护自动化运行,
当我们理清了系统中存在的层次后,就可以着手为系统中的每个实体起名。
Pigsty所遵循的基本命名规则,请参考 命名原则 一节。
Pigsty使用独立的名称管理机制,实体的命名自成体系。
如果需要与外部系统对接,用户可以直接使用这套命名体系,或通过转接适配的方式采用自己的命名体系。
集群命名
Pigsty的集群名称由用户指定,满足[a-z0-9][a-z0-9-]*
的正则表达式,形如pg-test
,pg-meta
。
节点命名
Pigsty的节点从属于集群。Pigsty的节点名称由两部分组成:集群名 与 节点编号,并使用-
连接。
形式为${pg_cluster}-${pg_seq}
,例如pg-meta-1
,pg-test-2
。
在形式上,节点编号是长度合理的自然数(包括0),在集群范围内唯一,每个节点都有自己的编号。
实例的编号可以由用户显式指定并分配,通常采用从0或1开始分配,一旦分配,在集群生命周期内不再变更。
实例命名
Pigsty的实例从属于集群,采用独占节点式部署。
因为实例与节点存在一一对应关系,因此实例名与节点命保持一致。
服务命名
Pigsty的服务从属于集群。Pigsty的服务名称由两部分组成:集群名 与 角色(Role),并使用-
连接。
形式为${pg_cluster}-${pg_role}
,例如pg-meta-primary
,pg-test-replica
。
pg_role
的可选项包括:primary|replica|offline|delayed
。
primary
是特殊的角色,每个集群必须,且只能定义一个pg_role = primary
的实例作为主库。
其他的角色大体上由用户定义,其中replica|offline|delayed
是Pigsty预定义的角色。
接下来?
划分好监控的层级后,需要对为监控对象赋予身份,方能进行管理。
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.