开发者学堂课程【PolarDB-X 开源系列课程：第五节：PolarDB-X 集群运维2(一）】学习笔记与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/1032/detail/15161
第五节：PolarDB-X 集群运维2
内容介绍：
一、polarDB-X 产品介绍
二、PolarDB-X CCL&SQL Advisor
课程主要分成两个部分，第一部分会介绍是如何对 polarDB-X 进行监控的，第二部分是当polarDB-X 系统里面遇到了一些问题的 SQL，如何通过现有的手段对其进行处理、优化，来保障目前系统上的业务稳定运行的。
一、polarDB-X 产品介绍
1、polarDB-X 架构
polarDB-X 是阿里云上的云原生分布式数据库，这是它的架构图，从架构图中可以看到它有四个核心的组件构成。第一个组件是计算节点 CN，它是整个集群流量的入口，负责收到应用服务器发过来的业务 SQL，将其进行相应的分布式的计算以及路由，同时也负责了全分布式事务的维护，以及全局二级索引的维护。第二个组件是 DN 节点，它是实际的数据存储节点，同时它还通过了 paxos 协议保证数据的强一致和高可靠。第三个组件是语言数据中心 GMS，它存储了整个 polarDB-X 集群中的拓扑，同时也是分布式事务所依赖的 TSO 的授时组件。第四个组件是 CDC，它的主要作用是将每一个天上存在的物理 binlog 汇聚成一条与 mysql binlog 完全兼容的逻辑 Binlog 流，能够与大下游的大数据的生态系统进行无缝对接。
2、PolarDB-X Operator 架构
前面提到了 PolarDB-X 是一款云原生的分布式数据库，既然提到云原生，自然也就绕不开 K8S 话题。PolarDB-X 也积极地拥抱了 K8S 生态，我们在 K8S 上也构建了自己的扩展叫 PolarDB-X Operator。基于 K8S 也有的像 scheduler、apiserver、controller-manager 这样的一些基础能力，我们构建了 PolarDB-X 自己的控制面，能够在 K8S 集群上对 PolarDB-X 数据库进行部署，以及相关的运维能力。例如，依赖 deployment 对 CDC 和 CN 这样的无状态的组件进行管理，依赖类似 statefulset 这样的方式对采用 Xpaxos 的 DN 节点进行管理，除了正常的一些部署和常规的运维的生命周期方面的能力外，还提供了像弹性伸缩、高可用、备份恢复以及监控审计等一系列的能力。今天的课程所介绍的监控也是围绕 K8S 的operator 的方式进行构建的。
二、课程演示
1、PolarDB-X 监控
首先给大家演示如何在 K8S 集群里面为 PolarDB-X 集群安装监控，然后通过 Grafana 访问目前的监控报表。
第一步需要安装 PolarDB-X monitor 这个组件，因为 PolarDB-X 的监控是通过 Prometheus 和 Grafana 来实现的，因此在 PolarDB-X Monitor 组件里集成了 kube-promethus 组件栈，只要安装 PolarDB-X Monitor 即可一键安装整套的 Prometheus 的软件栈。在这个过程中，有一个前置的要求，第一步需要有运行中的 K8S 集群，同时已经安装好了Helm3，另外也需要安装好 PolarDB-X 的 Operator，给大家先简单看一下，
通过 kubectl get polardbxcluster 的方式，可以看到已经安装好了 PolarDB-X 的 operator 和创建好了 PolarDB-X 的实例，操作过程和前两天在课程中使用的云起实验室是类似的。
同时，也可以通过 kubectl get pxc 命令查看 PolarDB-X 的状态，可以理解 pxc 就是 polardbxcluster 资源的缩写。
接下来将按照监控文档中的步骤开启监控。首先，需要创建一个叫 PolarDB-X monitor 的命名空间，通过这个命令创建，
创建完成。由于 PolarDB-X Operator 是直接安装的，所以这边 monitor 的 CRD 会默认安装，下面是可以跳过的，在文档中也有说明，在实际操作中可以参考。
下面直接通过 Helm 仓库的方式安装 PolarDB-X monitor 组件，第一步是添加 PolarDB-X的 helm 仓库，接下来使用这样一条命令创建 PolarDB-X monitor。
一个需要说明的地方，因为是在 ecs 上通过 minikube 的方式虚拟化出了一个 K8S 的集群，而 monitor 组件里面由于依赖了 Prometheus，它默认的资源要求会相对较高一点，如果在 minikube 上安装，需要将它的资源通过 yaml 文件的方式默认调小一点，这样能够保证它创建成功，不然可能会出现因为资源不够导致的创建失败。
这边已经准备好了一个 values 文件，通过-f 的参数去指定它，就可以对它进行创建。
这边已经创建出来了，来看一下 values 文件的内容。
values 文件里面定义了 monitor 里面的 Prometheus 组件，将它的 resource 的 limits 限制到了2C、8G，request 限制到了1C、2G 这一部分的内容，已经在监控文档上有了一个说明，注:如果您是在 minikube 上安装 PolarDB-X Monitor,可能会因为资源不够导致组件无法创建，可以参考配置 Prometheus 和 Grafana 规格调整组件的规格。可以参考监控文档，按这个操作来进行。上面这样的输出表示 PolarDB-X monitor 已经安装完成了，接下来就要查看 PolarDB-X monitor 里面依赖的相关组件是否到了 running 的状态，通过 kubectl get pods -n polardbx-monitor 这样的命令，查看 PolarDB-X monitor 命名空间下所有的 pod 是否引起来。
可以看到所有的 pod 都已经到了 running 的状态，它主要包括几个关键的组件。第一个像grafana，它是一个可视化组件，还有 node-exporter，它是资源采集的一个组件，还有一个重要的 Prometheus。这几个组件都已经进入了 running 的状态，接下来将为 PolarDB-X 实例开启监控。
已经提前创建好了 PolarDB-X 的实例，
要为它开启监控，需要创建对应的叫 PolarDB-X monitor的一个对象，这个对象的内容会通过 PolarDB-X monitor的 yaml 文件去定义，简单看一下里面的内容，
它的内容也比较简单，第一个部分就是它的 kind，它的资源类型是 PolarDB-X monitor 类型，它的名字可以随便起一个，这边直接就叫 Pxc-demo-monitor，Spec 部分有三个关键的参数，第一个是 clustername，它表示的是需要开启监控的 PolarDB-X 的集群的名称，也就是对应的通过上面这款命令拿到的 Pxc-demo。第二个参数是 monitor-interval，它表示的是监控采集的间隔，这边设了15秒。第三个是 scropertimeout，表示的是监控数据每次采集的超时时间。有了这样的文件，通过 kubectl apply 的方式来创建 PolarDB-X monitor 的对象。
通过 kubectl get pxm 这个命令，
这个对象已经创建完成，目前正在一个监控的状态。
接下来将去访问 grafana 的 dashboard 查看具体的监控指标，通过 kubectl port- forward svc/grafana -n polardbx-monitor 3000 这样一条命令将 grafana 的服务转发到我的本地，可以看一下创建了哪些 svc，
可以看到在 PolarDB-X monitor 命名空间下创建了 grafana service 还有 Prometheus 的service，监控报表就是在 grafana service 上面，所以通过这样的一条命令将端口转化到这台ecs 上。这边有一个说明，因为需要从我本地的 Mac 电脑来访问这台 ecs，因此它是要从外部机制访问的，需要加上--address 的一个参数，就是要等于0.0.0，
然后对它进行端口的转化。
接下来通过浏览器访问监控页面，进入到 grafana 的登录页面，
默认的用户名和密码都是 admin 和 admin。密码就不重设了，直接通过 skip 的方式跳过它。为了演示的效果，也开启 sysbench 的一个压测流量，
看一下它的日志 kubectl logs sysbench-select-j48qh-g，
目前 QPS 在 4000 多左右，接下来访问监控页面，
监控页面已经展示出来了，目前 QPS 在4800左右，RT 在1.34毫秒。首先简单介绍一下 PolarDB-X 的监控页面布局，它分成几个部分，
第一个部分是 overview 部分，它给出了几个重要的一些指标的概括概论情况，下面分别是 GMS、CN、DN 和 CDC 4个不同组件的详细的监控指标。
对 overview 部分的两个指标做简单的介绍，
第一个是 QPS，分成了两个，一个叫逻辑 QPS，也就是 logical QPS，一个叫 physical QPS，就是物理 QPS，逻辑 QPS 表示的是应用服务器发送的业务 SQL 到 PolarDB-X 每一秒的 SQL 数，物理 QPS 对应的是 PolarDB-X 经过相应的防布式的路由与计算，将逻辑 SQL 转换成了对应的物理 SQL 下发到 DN 上每一秒的 SQL 数，可以看逻辑 QPS 和物理 QPS 是比较接近的，它说明的一个问题是基本上所有的业务请求都是只涉及某单个 DN 分片的查询，属于偏点查点写的业务。假如突然发现物理 QPS 远远高于逻辑 QPS，这时可能要注意，有可能业务中有一些 SQL 涉及了较多的分片查询，需要关注是否需要对其进行优化。另外一个指标是 response time，也就是 RT，它也是分成了逻辑和物理两部分，逻辑 RT 表示的是应用服务器发送 SQL 到 PolarDB-X，直到把所有的处理结果返回到应用服务器的时间，而物理 RT 表示的是 PolarDB-X 的 CN 节点把物理 SQL 发到 DN 节点，然后 DN 返回结果给 CN 节点的时间。通过这两个指标，可以帮助判断当前系统的瓶颈主要在哪里，例如发现系统的 RT 突然上升了，这时候去看发现主要的变化是物理 RT 占了大部分，可能系统的问题主要在 DN 层面，假如发现 DN 的就物理 RT 并没有什么变化，但是逻辑 RT 却上升的很高，很有可能系统的瓶颈点就出现在了 CN 层。通过这两个指标能够帮助快速的定位系统的状态，以及可能出现问题的组件。另外这个报表里面还有很多其他的一些监控指标，大家可以按照文档操作去体验，去上面查看。
2、Polar DB-X 监控架构
首先对刚才演示的 PolarDB-X 监控能力的架构做一个简单介绍，首先看一下监控指标的采集层，它的指标分成两种类型，一部分是引擎相关的指标，例如像刚才说的 QPS、RT 等等的一些指标，针对每一个不同的组件构建了 Exporters 的服务，它通过 HTTP 的方式暴露监控指标，Prometheus 会定期的从这边来拿取数据，这个定期就是刚才在 PolarDB-X monitor对象里面限定的 monitor interval 参数决定的。对于资源层面，例如像 CPO、内存这些基本的指标，是通过开源的 Node Exporters 去暴露的。刚才在 PolarDB-X monitor 命名空间下也创建好了一些 Node Exporters 这样的一些 port 负责监控的采集，采集完监控指标之后，Prometheus 会将它的监控指标存到内部的时序数据库里面，之后 grafana 的监控报表会通过 PromQL 这种方式从 Prometheus 里面拉取监控数据，然后构建相应的一些监控图表，让我们了解实例的运行状况。除此之外，对于 Prometheus 的 Cluster 是通过Prometheus operator 这个组件管理的，它可以帮助有效的部署和管理 Prometheus 的集群。另外，对于 K8S 集群内哪些 PolarDB-X 实例需要监控，以什么样的频率去监控，这都是刚才创建的 PolarDB-X monitor 对象所控制的，它会告诉 Prometheus 需要采集哪些实例的监控指标。下边便是整个 PolarDB-X 在 K8S 上构建的监控体系的基本架构，
