一、基础介绍
OCP云平台伴随 OceanBase 数据库而生，是用于管理 OceanBase 的平台，支持 OceanBase V1.4~V4.x 的所有主流版本。
我：OCP 不仅提供对 OceanBase 集群和租户等组件的全生命周期管理服务，同时也对 OceanBase 相关的资源（主机、网络和软件包等）提供管理服务，能够更加高效地管理 OceanBase 集群，它有以下特性：
- 高效的 OceanBase 集群管理
- 支持高可用性。
- 响应速度可达到秒级。
- 清晰的信息框架
- 全新面向对象的架构设计，提供单个集群、单个租户的沉浸式管理视角，更符合用户心智。
- 依据 DBA 的工作场景，划分沉浸式导航的功能模块，功能入口更加清晰。
- 流畅高效的用户路径
- 对核心 Job 的任务进行串连设计，流程清晰、无断点。
- 提供运维任务的快捷入口，在所有页面均可快速切换至任务。
- 可视化的体验
- 任务详情提供流程图和自然灵活的画布交互，管理任务进度更直观、高效。
- 新增集群和租户的拓扑图，透出分布式的业务逻辑，展示运行状态、关键数据。
- 专业化的功能
- 提供 OceanBase 集群的全生命周期管理。
- 针对 OceanBase 特性设计的管理功能。
- 从集群到会话的递进式管理功能。
- 精心设计的拓扑图功能。
二、功能介绍
租户管理
OCP 对于 OceanBase 租户也提供了丰富的管理功能，包括租户的创建、租户结构拓扑图、性能监控、会话管理和参数管理等。
OBProxy 管理
OCP 提供了 OBProxy 的全生命周期管理功能，包括集群创建、删除、扩缩容、升级等。
备份恢复
备份恢复是 OceanBase 数据库高可用的核心特性，主要用于保障数据的安全，包括预防存储介质损坏，用户的错误操作及其他意外情况导致的数据丢失。在上述情况下，可以通过已备份文件将数据恢复到在线集群中。包括对 OceanBase 集群、租户级别的全量备份、增量备份、日志备份功能。
性能诊断
性能诊断主要围绕 OceanBase 集群来进行性能展示和问题诊断，包括 SQL 诊断和性能报告。SQL 诊断包括 topsql、slowsql、可疑sql等，性能报告包括 AWR 报告和 ASH 报告。
监控告警
监控和告警是企业级 IT 管理软件中非常重要的一部分，OCP 监控支持 OceanBase 集群、租户、主机等不同维度。
用户可以使用内置的告警项来满足基本的告警需求，也可以通过告警项配置功能配置自定义告警，同时告警通道还支持通过模板方式配置 HTTP 和脚本通道以适应各种消息通道。
巡检
OCP 巡检功能用来检查所监管的 OceanBase 系统及其环境是否满足预期，以报告的方式来暴露监控或告警场景无法覆盖的安全隐患，并提供报告的下载功能，帮助用户及时发现系统存在的隐患。
主机管理
主机管理提供了主机的信息展示以及主机的添加和删除等功能。
安全
主要包括用户管理、角色管理和用户中心三部分。
OCP 中的用户主要通过角色获取对各种资源的管理权限。您可以在用户管理和角色管理模块中对 OCP 中的各种用户和角色进行管理，包括对用户和角色执行创建、修改或删除操作。
您还可以对角色的权限进行赋予和回收操作，从而实现常见企业级数据库监控软件所需的大部分用户管理功能。
用户中心提供了个人安全信息相关的各种管理功能，主要用于管理 OCP 用户的个人设置、密码箱和告警订阅等信息。
系统管理
系统管理主要提供任务管理和 OCP 参数管理功能。
通过任务管理功能可以查看任务并对运行中的任务进行管理。
参数管理功能允许用户根据自己的业务需求管理 OCP 系统参数。
三、重点功能与监控指标讲解
租户性能监控
请求等待队列
- 每秒 SQL 进入等待队列个数： 这个指标表示的是每秒钟有多少SQL请求被放入等待队列中。当一个SQL请求到达时，如果系统当前的资源（如线程）不足，那么这个请求就会被放置到等待队列中，直到有可用资源来处理它。高数值可能表明系统正在经历高负载或者资源瓶颈，导致新的SQL请求不能被立即处理。
- request_enqueue_count: 进入处理队列的请求数量： 这个计数器记录了所有进入处理队列的SQL请求总数。处理队列是等待CPU或I/O资源来执行的SQL请求队列。这个指标可以用来评估系统的整体工作负载和请求处理能力。
- request_dequeue_count: 从处理队列出队的请求数量： 这个计数器记录了从处理队列中移除（即已经完成处理或开始处理）的SQL请求总数。与enqueue_count对比，可以帮助你了解处理队列的效率以及是否存在长时间停留在队列中的请求。
如何衡量这个指标达到性能瓶颈？
这个指标需要根据其他系统资源（如CPU、内存）没有达到饱和，且查询响应时间仍然保持在可接受范围内，那么这可能是一个正常的负载水平。如果在短时间内这个数值突然激增，比如达到几万甚至更高，同时伴随着上述提到的资源利用率上升、响应时间增加等问题，那么这就可能预示着系统正面临性能瓶颈。
MEMStore使用百分比
MEMStore（内存存储）是 OceanBase 数据库中的一种关键的数据结构，主要用于暂存已提交但尚未持久化的数据，它负责接收来自客户端的写入操作（如 INSERT、UPDATE 或 DELETE）缓存到内存中，并将这些操作的结果暂时存储在内存中，而不是立即写入硬盘上的文件。。
- Memstore_percent: MEMStore使用百分比 这个指标表示当前MEMStore所占用的总内存空间最大允许内存空间的百分比。是用于存储已提交但未持久化到磁盘的数据的一个内存结构。每当有数据写入操作发生时，数据会被首先写入MEMStore。一旦MEMStore的使用达到一定阈值，OceanBase会触发一个称为“冻结”的过程，将MEMStore中的数据转化为SSTable并持久化到磁盘上，从而释放MEMStore的空间。
- Active_memstore_percent: MEMStore使用占触发冻结百分比 这个指标更加具体地指出了当前MEMStore的使用情况距离触发下一次冻结操作还有多远。OceanBase有一个固定的阈值，当MEMStore的使用达到这个阈值时，系统会自动进行冻结操作。
Active_memstore_percent就是当前MEMStore使用量与这个冻结触发阈值的比率。如果这个百分比接近100%，则可能触发冻结操作。冻结是OceanBase的一种数据管理机制，主要是将内存中的数据持久化到磁盘，确保数据的安全性，然后释放内存空间供新的写入操作使用，冻结也叫转储操作。
如何衡量这个指标达到性能瓶颈？
触发冻结会对OceanBase数据库的性能产生短暂影响，比如：CPU资源消耗、磁盘IO负载增加。需要结合其它指标分析是否达到性能瓶颈，CPU使用率、IO等待时间、内存使用、分析冻结频率和时间（频繁发生会影响写入性能，因为系统需要频繁地执行冻结操作）、sql响应时间。
题外话：
我们去控制台结合分析一遍，比如这个租户，cpu 内存 qps 响应时间 sql执行时间 等等基础指标都比较正常，然后发现MEMStore活跃冻结百分比基本上都是比较高的，时不时会有断崖式的情况出现，结合刚才的多种基础指标分析，所以它是正常情况，为什么说是正常情况？因为这个MEMStore内存存储是缓存客户端操作的，所以快接近100%的时候，就会触发冻结转储操作，把数据转储到磁盘里，保障了数据的安全性和一致性。所以大家记住，不管是什么技术栈，需要知道有没有达到性能瓶颈，一定要学会看监控指标，你不清楚指标什么意思的，可以去查查资料，当你看到一个指标不正常或者很高的时候，并不代表它一定是达到了性能瓶颈，还需要结合其它指标综合分析，才能判断出是否达到性能瓶颈。
这个综合分析，不要局限于控制台上面提供的指标，比如硬件设备的配置、网卡的带宽、CPU的频率、内存的频率、硬盘的IOPS和吞吐量，还有系统层的优化 比如：内核参数调优、针对平台特性调优，然后是应用层自身的参数调优，最后就是把监控覆盖到位，这些都需要去关注并且结合起来，才能分析出，是哪个环节出现问题，导致的性能瓶颈？有些问题可能是串联起来的，比如CPU不足或频率低，导致计算能力弱，即使硬盘再好也没有空闲CPU资源调度了，自然发挥不出最大性能，这只是一些帮助大家容易理解的示范。还有就是应用层的调优，没优化好某些参数，发挥不出该有的性能。所以大家可以通过一些案例，学习到方法，并不是所有东西都有标准答案的。要学“神”的层面，不要停留在“形”。
物理 IO 次数
- ssstore_read: SSStore 每秒读次数
- ssstore_write: SSStore 每秒写次数
- clog_read: clog 每秒读次数
- clog_write: clog 每秒写次数
如何衡量这个指标达到性能瓶颈？
需结合其它指标综合分析，首先了解存储设备的IOPS多大，然后了解系统是否做了配置和优化，接着实时观察监控：CPU、磁盘吞吐和IO响应时间，同时观察读写操作的增加是否导致了业务延迟、吞吐量下降或其他性能指标的恶化，才能判断出物理IO次数是否达到了瓶颈。同理，其它物理IO耗时、物理IO吞吐量的监控指标也是需要综合分析。
SQL诊断
TopSQL 诊断
TopSQL 是以 SQL 请求的 SQL ID 为聚合维度来统计各种不同形状 SQL 的执行统计信息，并按照不同的资源消耗进行 SQL 排序、展示 SQL 执行的历史趋势。通过 TopSQL 功能分析此类 SQL 的请求行为，发现其中可能存在的异常请求，或者有针对性地对 SQL 进行性能调优分析。
可疑 SQL 诊断
SQL 诊断源于 OCP 现有的 TopSQL 采集数据，并内置专家经验来对 SQL 进行诊断，找出存在潜在风险的 SQL，即为可疑 SQL。SQL 诊断的数据来源与 TopSQL 相同，每个诊断项都从 OCP 的 monitordb 元数据中，通过一定规则匹配（CPU 时间、执行频率等）获取待诊断的对象进行诊断。 可疑 SQL 会将性能下降和执行计划发生变化的 SQL 进行展示，您需重点关注。同时，可疑 SQL 的诊断结果中包含性能下降的原因分析等信息，可以为您的 SQL 调优提供更明确的指导意见。
SlowSQL
OCP 将执行时间超过一定时间（可设定，默认 100ms）的 SQL 称之为 SlowSQL，您可根据业务场景来对 SlowSQL 进行不同的阈值配置，SlowSQL 的影响在于：
- SQL 响应时间慢，响应时间长。
- 系统资源开销大，极端情况可能导致系统不可用。
因此，需要将这些有可能会影响系统稳定性的 SlowSQL 进行收集分析，帮助您提早排查问题，规避风险。OCP 的 SlowSQL 关注单次 SQL 执行的信息，对 oceanabse v$sql_audit 的数据进行采样保存，您能从各个维度来分析 SlowSQL 的资源消耗和执行详情。
下图可以看出响应时间里，有条SQL是83.26ms
可以点击SQL进去查看优化建议，以及历史响应时间
上面是一些比较重要的功能和监控指标的讲解，其他的监控指标都是比较简单易懂的。