开发者学堂课程【PostgreSQL 实战进阶：PostgreSQL 监控实战（二）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/112/detail/1904
PostgreSQL 监控实战（二）
内容介绍：
一、快速上手：利用监控系统观察数据库状态
二、解决方案：如何部署属于自己的监控系统
三、解决问题：如何用监控系统解决实际问题
三、解决问题：如何用监控系统解决实际问题：
如何用这样的一套监控系统来解决现实问题？假设您已经执行了第二部里面的步骤，拥有了一个本地的金融系统，那么现在假设你已经把它放到生产环境中，可以用这个系统来干什么？或者说我怎么上手联系？
第一步最重要的就是了解这个系统里面的指标。毕竟监控系统的面板只是面子，而监控指标才是这个监控系统的里子。Pigsty 提供了约1200个指标，可以说是市面上你能找到覆盖率最广的奖金，基本上其他那些方案结果指标差不多，多的也就一两百个，少的话可能一些饮料也就只有十几件指标。可以说是指标覆盖率非常全的，但是实际对于运维来说，你要关注的指标没有多，可能就是这十个核心指标。总结出来十个指标需要特别的关注，这也是这个 PG class that board 在首屏上面呈现出的关键指标，比如数据库饱和度，这个是最重要指标，按照监控再加实践，这些指标可以分为四大类，饱和度、延迟、流量和错误，都是具有很重要的参考价值。
学习最重要的一个指标就是 PG Load，数据库的负载程度，PG Load 就是有很多的指标，但是很多时候人就只关心一件事，就是你告诉我这个数据库现在是是个什么水平，比如0就是很健康的，1就是快死了，这样的一个指标，PG Load 就是这样的一个指标。他是一个规划指标，用来衡量数据库的负载程度，这是一个自己设计的指标，但是它是采用了类似于操作系统那个 note Load 类似的思想，它是使用 PG 处于活跃状态的实务时长占CPU总时间的比例这样的一个思想的设计。在实际生产使用中，其实这个效果是特别好的，一条简单的指导原则，就是说这个指标如果超过40%，那就是中负载（黄线），如果超过70%，那就是非常危险的一个高负载（红线），如果超过100%，那说明你的数据库已经进入了一个雪崩状态，所以说是相当简单的。比如说下面这就是这个生产环境中所有集群的这样一个 load，大多数情况下，这个 load 都是在黄线以下，偶尔有些峰值超过黄线和红线，那就是需要特别关注了,所以有这么一个很简单的单一的指标，对于衡量数据库性能指标水位是非常方便的
但是 PG Load 也不是没有问题，就是它其实基于一个假设，就是这个数据库它是独占式部署，整个机器检测的所有资源都为这个数据库。但如果有些情况，您的数据库是混的，有一些其他的组件也会吃 CPU，就会出现一个问题，比如另外一个程序把这个机器的 CPU 吃满了，数据库已经处于一个负载的很大的状态，但是从 PG Load 上看不出来。因此我们还有一个进一步加工指标，就是 PG Saturation（ PG饱和度）。所谓饱和度就是某个资源使用的程度，通常这个百分比，理论上我们说PG Load 的整体的一个饱和度，应该把每一个分项资源饱和度做一个聚合，求最大值。比如内存使用70%，硬盘使用60%，然后 CPU 使用50%，那么整体上来看，你的资源使用水位就是最大的为准。但是实际上会发现，像内存、CPU 这种其他的这些资源往往都不是瓶颈，瓶颈往往就是两个就是 CPU 和那个数据库本身的链接资源。所以定 PG Saturation 等于 max PG Load and CPU usage 的计算公式，这是一个基于PG Load 进行修饰和稍微加工过的一个衍生指标，PG Saturation 饱和度作为一个核心监控指标。
如下图可以看到，这里使用的指标就是 Saturation 饱和度,这里使用 Load，这里看到的 Saturation，使用 Saturation 好处就是可以反映出这个 CPU 的使用状态，不会错失这样的一个故障隐患。这是第二个黄金指标 PG Saturation。
接下来水位评估除了直观的衡量实时的数据库负载水，它还可以用来计算数据库的水位，水位其实就是一个长期的资源使用量指标。通常来说，比如如果某一个数据库集群长时间处于高负载状态，就水平较高，可能给他扩容，如果他长时间处于低水位状态，处于闲置，就给它缩容，扩容和缩容的依据就是所谓的水位，水位其实就是过去某一个时间段饱和度的百分点，比如现在采用就是过去一天里面水位的99分位，这对于那种有周期性的负载来说，一天是一个比较好的这种衡量指标，如果您的业务，它的周期性可能比如说一周或者一月，您可以使用过去一周或者一个月的饱和度数据来计算的九九分位点，评估这个集群的水位，比如这里有一套集群，它的水位是30%，那么就是意味着系统在过去一天的99%的时间里面，他的资源使用率都在30%以内，所以我们就认为他的水位是30%。对于评估长时间段系统的资源利用率是很有用，评估资源率你就可以评估成本，及时的进行优化。这是一个典型应用。
刚才介绍了监控系统里面的一些指标，更重要的东西就是用这些指标进行报警，毕竟人去看的指标，实时盯着指标，那是一个非常辛苦的活，更好的选择当然是由机器来盯着这些指标，您设定好规则，机器发现这些指标超出异常范围的时候，自动触发，发送一些报警，其实里面是提供了一系列的报警规则。可以看到是有一系列的报警规则，给他一些负载，可以看到触发的这个 note CPU 的报警。而报警事件也可以在监控系统的面板里面看到，通过这种条状的这种类似于甘特图的方式，可以看到哪一个时间段触发了报警事件，从而有的放矢的去排查检查，所以这是报警系统。提供了很多的这种计算好的衍生指标，所以您可以不用再写特别复杂的表达式了。直接用起来，就比如说负载水平大于百分之七，持续三分钟，然后发一个报警，这种报警指标其实定义起来是非常方便的。
那么介绍完指标报警之后，再来介绍一个实际的监控问题，就是慢查询。慢查询是数据库大敌。这里可以做一个小实验，就是用 Pgbench 模拟一个慢查询。先把这个系统的负载给加上。现在的主库是2号库，Pgbench 是 PG 自带的工具，它会创建一个 TBC 一个用例，就是以这个仓库银行转账的一个例子。读写都是基于这个例子来的，这个例子会创建四张表，PgbenchXX 表。这四张表可以很简单粗暴的把组件给删掉，这个系统马上就会崩，
举个例子，读写查询从原来的十毫秒一下子变成了秒级别的，性能损失1000倍，可以想见的是这个系统马上就会被压雪崩，比如一号库就是刚才已经死掉，现在二号和三号库一主一从这个组合，这个主从库无论是读写还是只读产品，现在都已经处于一个雪崩状态，同样的查询内容，所以删掉之后开始雪崩了，这就是一个很典型的慢查询，这样的一个慢查询，怎么来分析和处理呢？比如刚才这个慢查询，这个系统已经过载了，这个集群的qbs有了一个显著的下滑，实际上这个机器我把已经卡死了，有了慢查询之后，我们就要进行定位,怎么定位慢查询？首先让我们进入PG Cluster。前面我们会发现主库和从库都处于严重过载状态，挑一个主库Pgbench 进行分析，从主库上进入 PG Statement。可以发现有两个查询，它的占用的时间突然有了一个飙升，QPS 有一个显著的下降，而他的响应时间有了显著的上升，那说明这个查询变成了慢查询。
现在已经知道了这个查询变成慢查询了，接下来怎么办？就要定位一下这个慢查询是什么，举例，刚才看到的这个查询是哪一个？编号是35744，就可以使用这个查询 ID，去对应的监控面板里面查询一下，到底是哪一个查询变慢了。可以看到这个查询就是 select theme from ti banker com po ID 等于这样的一个值。看到这样的查询变慢，很显而易见我们就能提出一个猜想，是这个表上这个索引，当然因为刚把索引删掉了，但是为了验证我们的猜想，可以前往 PG TableDetail 去验证对比。
PG Count 这张表，可以仔细看一下它在过去一段时间里面的变化，我们发现这个表上的索引，索引扫描在这里戛然而止，而相应的它的顺序扫描有了一个显著的增长，也就是说原来他是走索引的，现在他不走了，走顺序全表扫描，原来呢，他总是 index ES，我们可以看到原来有一个PK索引，索引没了，之后，他就没法去访问了，所以可以确定这个问题确实是因为这张表上面缺少合适的索引导致。我们提出这样的猜想，就会有相应的解决方案，只要给他创建一个对应的索引，就能解决这个问题了。
比如在这张表上，给 ID 创建一个索引。然后可以看到神奇的事情发生了，原来都是一秒钟两秒多的差距，现在通通都是又重新变成了个位数的毫秒数了，可以看一下这个系统，分钟级 Load 还没有恢复过来，但是实时显示的数据库负载已经开始回落了，从刚才的这个满载状态开始往下掉，现在已经重新回到一个比较正常的水平45%，原来这是100%的水平。再重新观察一下这个 PG cluster activity，这个集群的 QPS 又重新回到了一个回到了正轨，可以认为这个系统从雪崩满载状态中恢复回来。在刚才的这个过程中，也看到这个系统触发了一系列的报警，包括整个集群里面的Load开，这个机器的CPU使用率高，机器的负载高，以及VIP海查询响应时间变高，所以说他成功地触发了这些报警的条件，然后又在重新加回索引之后，这些报警都解除了。
这就是一个典型的慢查询处理的方法论，最后可能需要复盘或者评估，就可以利用监控系统提供的指标去做一个精准评估，比如有一个实际的库，现在给他加了一个索引，原来这个库的负载水平在40%左右，索引之后可能就变成了4%，那么原来你用十台机器，现在你只用一台就可以实现了，就等于省下多少成本，然后你省多少钱，然后优化了多少存储，优化多少个 IO，诸如此类。因为这个东西，确实是一个很好的数据支撑，能让您去做汇报或者是做分析，都能做到有理有据。
