开发者学堂课程【PostgreSQL 实战进阶：PostgreSQL 监控实战（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/112/detail/1904
PostgreSQL 监控实战（一）
内容介绍：
一、快速上手：利用监控系统观察数据库状态
二、解决方案：如何部署属于自己的监控系统
三、解决问题：如何用监控系统解决实际问题
一、快速上手：利用监控系统观察数据库状态：
进入今天的第一个主题快速上手：利用监控系统观察数据库状态。
在开始之前，实际中的兼容性什么样，这里是一个环境，在我的笔记本上有四个虚拟机系列，其中两个数据库集群组成，这个里面有两个节点，四个数据库实例，这个数据库实例，其中一个是一组两层的，一个30例集群，整个环境差不多是这样的一个情况，这个监控系统是由很多的面板组成的，Service instance and database，这是五个监控的层次，
比如如果关心的这个 PG Cluster，可以看数据库集群信息，比如这是一个集群，采用的是3.1版本的这个数据库，里面有三个实例的IP地址、实例名称，他们的角色，以及所属 servive，这个集群上面是有一些负载的，这里列出了负载水平，整体负载水平24.5，主库没有负载，从库有一点负载。同时也可以看到这里集群有些报警，也可以从这里看到从第一级开始，从主库复制二，从二复制到三，这样两条复制链接，同时也可以看到这个集群中有很多的表，这些表上面还有一些查询正在运行，所有的这些查询也可以看到包括他们在哪个实例上运行时间怎么样，都是可以从监控中看到，监控系统中能看到的不止于此，比如说我们想看这个 pigsty 中当两个服务,想看这个从库服务，这个从库服务其实是两个实例，两个实例在前面有负载均衡器，这个负载均衡器把流量导流到了这两个从库，而没有把流量导到这个主库上，所以这里是一个流量分发的 PG service 监控，
那么在往下走具体到某一个实例里面去看，比如看一下主库提供了哪些监控指标，PG instance 是一个很实用的监控面板，有几百个监控仪表盘，整个监控可以分成很多个部分，比如会列出这个实例的一些核心指标，它的负载水平，活跃的服务器数量，活跃的客户端数量，以及他的TPS和年龄，以及这台实例上面正在发生着的警报的事情。同时也会有一些比如说机器节点，这个实例上面的机器，它的 CPU，内存，网络相关指标。
接下来是赋值，就包括这个库它是主库，我们可以从他上面把查询到从库的一些相关信息，比如说 occasion 的一些相关指标，还有 transaction 这个数据库上正在发生的事务的 TPS 回滚，以及每一个事物的平均响应时间，以及锁的情况。
下面还有一些其他的指标，比如 para QBS，一个事务里面有多个查询，所以 QPS不太一样，包括 QPS 的 archie Cincinnati。接下来还可以进一步看到这个实例里面的每一个查询，每一类查询都会有自己的 QPS，这对于分析慢查询来说是非常实用的。同时还可以看到关于数据库里面的链接，我们有多少条数据库链接，都处于什么样的状态，这些链接都是从哪里来的？从数据库可以看到链接，从链接池和中间的角度也可以看到链接。这里就是链接尺寸的指标，关于数据库，因为一个实例上它可能会有多个数据库，每一个数据库都会有自己的一些相关指标，比如说增删改查、临时文件、缓存命中率这些数据库相关的指标。
最后还有这个实例的persist，就说他使用的磁盘、IO、文件占用、检查点、写日志的相关指标，内存，内存的使用，内部数据结构的使用。最后还会有这个监控系统的自监控，这个 ex porter 它花在哪个收集气场时间，抓取的指标数量，以及是不是有查询错误注册，最后还有实例级别的统计，比如今天总共有多少查询，花费多少资源，对于计量计费是非常有用，这是实例监控，
一般来说，对于运维来说，实例级别的监控就已经足够了，但是有时候我们会希望了解更多，这时候就需要用到对象级监控，比如想了解这个当前数据库里的每一张表上面的增删改查的访问情况，那么我就可以使用 PG table 去查看每一张表上的增删改查。不仅可以看到每张表，还可以看到这个表上的每一个索引，比如每个索引上的访问细节，以及每个台数的访问细节，如果对某一种表比较感兴趣，可以点进 PG Table Detail 去看到这张表最为详细的分析，包括这张表上发生的访问情况。
除了表之外，还可以看到查询级别的信息，数据库里的所有查询都会被归类，每一类查询都会分配一个查询 ID，比如可以按类去查看不同的查询，每个查询都可以查到。所以这就是一个生产环境中实际可以使用到的监控系统，走马观花的看了一下，可以说是比较有意思的一个东西。这样的监控系统其实对于日常管理运维是非常有帮助的。因为无论是性能优化也好，还是故障定位也好，监控系统都相当于你的眼睛，如果没有监控系统去管理数据库，那就跟蒙眼开车一样危险。
介绍完了监控系统大概的样子之后，来做几个小实验，来验证一下这样一个监控系统的功能。
实验1：利用监控系统观测查询负载
监控系统最基本的功能正确的反映出这个数据库系统本身的状态，这里做一个小测试，给数据库添加一些人工的负载，负载是用 PG 自带的压测工具 PG banshj 生成的，比如这里一行命令，用 PG banshj 给从库 select only 加上了1000的 TPS，第二条命令，给主库加上了50个TPS，主库使用四条链接，从库使用两条链接，那么期待的结果当然是：总共加了1050 TPS，主库50，从库1000，两个从库每个各500。
来看一下监控系统是不是如实的反映出了这样的一个情况？看这些的数据，这里监控系统的 TPS1035，如果想要看到具体细分的TPS，可以进入 PEGclass，这可以看到整个集群的TPS数据。主库上的TPS差不多就是50左右，从库上的 TPS 差不多就是1000，这三个实力，可以看到主库上的这个差不多一直就是50左右，从库上的这个差不多就是每一个500是符合我们预期的。
接下来稍微改动一下，还是施加同样的负载，再改一个参数，使用实例的链接数量，使用40条链接来发送只读查询，一个是使用20条链接来发送读写查询。期待看到原来用了两条链接，现在用20条，整个系统里面他的这个链接数是应该有一个上升的，比如原来活跃的客户端链接数是二，现在就是20，来看一下监控系统。关于链接可以访问 PG Cluster Session，这个是专门关于集群的绘画相关的指标，可以看一下，这里是 active dry and by instance，按照实力划分的链接数，近五分钟的情况，可以看到刚才使用了六条链接，两主两从，我们用60条，就变成20，20，20。如果说TPS指标它是有一定抖动误差，那么链接数这个指标都是可以说是非常精确，这是第二个步骤。
第三个步骤，采用没有 TPS 限制 pgbench，这样他就会尽自己最大所能去把这个系统给压满，就可以观察一下这个系统在过载情况下的表现。比如回到主页,可以看到这个监控面板，刚才这里都是绿的或者黄的，负载比较温和，现在这个负载水平已经明显爆表了，超过100%了，比如主库的负载已经严重的超标，两个从库也已经基本进入过载状态，这个系统的负载曲线可以看到，从刚才的这种20%，30%，一下子飙升到了现在100%左右，所以说整个系统已经进入了一个过载的状态。
赶紧把这个负载给停掉，重新加回比较温和的负载。看看这个系统是不是能重新的回到一个比较温和的状态。可以看到能把负载改掉之后，这个系统里面显示整个系统的负载水平就开始往下走了。整个系统都已经降到了45%。这个是按分钟统计的，响应实时的，会立刻看到变化，系统在负载过程上的一个变化。这个实验是反映监督系统的基本功能，就是他应该能够如实的反映我们给整个集群施加的负载，以及这个集群本身内部的状态。
实验2：重启主库，观察集群领导群交接
接下来第二个实验就是观察某一个事件对这个数据库集群产生的影响。举个例子，高可用，通常所说的高可用就是说当一个系统的主库宕机的时候，应该有的从库自动会提升出来，接管这个系统。这样的一个操作，其实如果没有监控系统，看到的就是一个很抽象的东西，但是有监控系统，就可以把这个事件很有趣的可视化出来，比如这里我登录到第一台机器上，主库所在的机器上。然后执行reboot，把这台机器关机了，可以看到这个负载都开始报错了，看这个查询用不了一两秒时间就恢复过来了，无论是读流量还是写流量，它都自动恢复过来，这说明什么？可以看到这个监控系统主库被踢掉了，PG test1已经没了，而现在 Pgbench 提升成新的主库了，这个新的主库现在开始承接写流量，让这个机器重启完成之后，DPS 的重启完成之后，它是一台死掉的 problem，它会尝试把自己降格为一台新的从库，重新挂在 PG test2，可以观察一下这个行为。同时可以看到整个集群的领导权leadership，这个图表已经发生了转移，比如原来是 PG test1，现在集团新领导已经变成了 PG test2。这是第二个实验，高可用实验，所以监控系统对于反应系统状态来说，还是非常实用的工具。
二、解决方案：如何部署属于自己的监控系统
第二个部分解决方案，刚才介绍了一个监控系统，以及这个监控系统做了一些实验，接下来学习监控系统看上去不错，但是跟我有关系，我怎么能用这样的东西？就要说到这个东西。它是什么？它怎么获得？这个监控系统我所使用的是叫Pigsty。是 postgres In Graphic STYle 的缩写，这是一个开源免费的 Progress 的监控方案，官方网站就是 https://pigsty.ccexcite CC。
是我目前能够找到的最好的一个开源的系统。那么在实际生产环境中其实已经有了一些应用，比如上图是现在某一个管理的生产环节用到的这样的一个实例，大概有1TB 的数据，有90多个集群。
这个金融系统里面的指标其实是非常丰富的，比如刚才那个 PD instance，一个屏幕都截不完，还得截两个屏长度才能把它完整的截下来。所以它提供了非常丰富的面板，30多个面板，总共用 Json 定义下来，大概有十几万行的代码，提供了这些监控面板。
要详细介绍的是如何在你自己的笔记本或者说生产环境拉起这样的一套监控系统，Pigsty 提供了沙箱环境,您可以在你的笔记本上快速拉起一个监控系统，而且拉起的不仅仅是一个监控系统，他还把这个数据库一起拉起来了，会拉起很多很多的组件，四个节点，有 pg、pgb 高可用组件,Consal 来做服务发现，有 exporter 监控系统暴露指标，基础设施有 DNS，有 NTP 服务器，还会有一个样木源，以及基础设施，还有 countil 源数据库，同时整个系统还会有VIP本来地方的权利，保证负载均衡器本身的高可用。那么这样复杂的组件，其实你如果是自己手动的一步一步去配置，可以想象这是非常棘手的事情。但是提供的这个沙箱，其实是非常简单的，你只需要克隆这个项目，然后依次敲敲下这几个命令，然后他就会在本地拉起一个就像我刚才所使用的这样的一个演示集群，可以说是非常简单了。
那么如果有问题，可以参考并在官方网站提供的文档。这里它就会拉起这样一个群，刚才看到这个集群 proxy 负责流量代理，Consul 负责高可用，以及前面会有DNS 解析和负责做负载均衡。所以这个就是所说的如何有这样的监控系统。
