监控层级

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

监控系统层次

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

图：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-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预定义的角色。

接下来？

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