OceanBase 数据库监控目前主要依赖 OCP 的监控功能，支持数据库集群维度、租户维度、节点维度的性能、容量、运行状态等指标 7*24 监控采集，图表可视化展现，帮助用户全面了解 OceanBase 集群使用状况，及时发现集群异常，触发事件及时预警，确保数据库稳定、高效的正常运行。
监控
OceanBase 数据库监控从处理链路方面可以分为以下几个部分组成：
Metric 链路（常规监控指标）：OBServer 状态监控、OBProxy 状态监控、主机指标监控。
OB SQL 链路：包括 OceanBase 数据库相关的 SQL、Plan 指标。
OB 资源水位链路：采集 OceanBase 集群、租户资源水位。
Metric 链路
此链路根据采集了以下几种指标：
主机指标：包括主机、主机上部署的相关服务（如 OBServer、OBProxy） 的 CPU、磁盘、IO 、LOAD 等信息。
OBProxy 指标：OBProxy 的相关请求、会话、事务等信息。
OB 秒（分钟）级别指标：对应 OB 节点的资源状态、QTPS 等性能监控监控信息。
Metric 链路依赖部署 OCP 管理的主机上的 OCP Agent 的 ocp_exporter 程序来进行采集，ocp_exporter 对外提供了一组 RESTFul 服务来进行监控采集，接口提供 Prometheus 规范的监控指标，内部依赖 NodeExporter（主机监控）、OBProxyExporter（OBProxy 监控）、OBCollector（OceanBase 监控）来采集多种指标。OCP 在采集到指定类型监控指标后会将监控指标汇总转换后保存到监控库（MonitorDB），监控计算引擎会根据监控表达式（基于 Prometheus 的表达式）到监控库查询监控数据并进行计算后返回给客户端，客户端根据返回的计算后的信息展示监控图表。
OB SQL 链路
此链用来采集各个 OB 集群的 SQL 数据和 SQL 执行计划数据，主要从以下OB 数据字典采集数据：
v$sql_audit：记录 SQL 的执行审计信息，
v$plan_cache_plan_explain：记录的是执行计划的每个算子的信息。
v$plan_cache_plan_stat：记录执行计划的审计信息。
考虑到 SQL 数据和 SQL 执行计划的数据量比较大，为了提升性能和降低资源消耗，此链路的采集程序 obstat2 是使用 C++ 开发的高性能、轻量级的程序。 它会根据采集频率配置，在采集周期内从 OB 数据字典采集 SQL 和执行计划信息，并在本地汇总计算后存入OCP 的监控库 （MonitorDB）。 OCP 后台任务会定期去监控库中进行汇总计算，将最小粒度的 SQL audit 和 SQL plan 数据汇总成大时间粒度的结果，并保存下来。当从web页面进行查询时，如果选择时间区间较小时，直接查询原始上报的表，如果时间粒度较大的则查询汇总表。
OB 资源水位链路
此链路负责采集 OceanBase 集群的资源水位，主要从以下数据源采集数据：
CPU 信息：
- GV$OB_SERVERS：CPU 总核数、已分配核数。
内存信息
- GV$OB_SERVERS：内存总大小、已使用大小。
磁盘信息
- GV$OB_SERVERS：磁盘总大小、已使用信息。
系统事件信息
- oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY：OceanBase 集群系统事件信息。
OB 资源水位链路是由 OCP 的定时任务触发，使用各个集群的 sys 租户按照集群、租户、数据库、表等维度采集 OBServer 上的 CPU、Memory、Disk 等使用率，并将数据保存到监控库。在客户端发起查询请求时查询引擎会按照集群、租户、数据库、表等维度进行统计，将统计后的数据返回给前端展示。
告警
OceanBase 数据库主要通过 OCP 告警实现对于生产中主机、数据库风险、故障的预警。当数据库及数据库所处主机环境即将发生故障或发生故障时，内置的告警项会检测到异常，并通过告警通道将告警发送给告警订阅者。主要从告警项配置、告警检测、告警聚合、告警订阅四个方面为您介绍告警功能。
告警项
OCP 内置了约60个告警项，每个告警项描述了告警的基本信息，如告警名称、等级、概述模板、详情模板等，以及告警检测相关的规则信息。
根据告警的风险程度，划分了5个告警等级：停服、严重、警告、注意、提醒。产生告警时，会生成一些相关的模板变量，模板变量可以配置在概述模板和详情模板中，以展示必要的上下文信息。告警检测规则是基于监控表达式的检测规则，如检测时长、检测周期、告警恢复周期、检测表达式配置等。
这些内置的告警项大致是从数据库资源、数据库事件、主机资源、OCP事件等方面描述告警，如数据库CPU、内存、memstore、磁盘使用率等数据库资源告警，合并超时、悬挂事务等数据库事件告警，主机网络、磁盘告警，以及OCP的监控API状态异常、metadb同步OB集群等告警。
告警检测
告警检测是检测内置的告警项并触发告警的过程，分为 2 种检测：基于监控表达式的检测和定时任务的逻辑检测。告警检测之后，会产生告警事件，也就是产生了告警；但该告警事件是否需要通知到用户，还依赖后续的告警聚合逻辑：可能会需要对告警做一些抑制操作，避免发生大量告警消息。
基于监控表达式的告警，可以通过监控API从不同维度聚合监控数据，对API的查询结果作阈值匹配，满足告警触发规则就会产生告警事件。
上图是基于监控表达式的告警检测中的状态流转，duration 是指告警的检测时长，当在 duration 时长内连续触发告警，则会产生告警事件。duration 常用于对异常状态的容错场景：偶发的一次异常不期望立即触发告警，只有持续异常才触发告警。
定时任务的逻辑检测是对应一些复杂场景，需要用一些脚本语言来检测。这类检测方法是直接调用告警 API，产生告警事件，如 OceanBase 日志告警、OMS 告警等，适用于外部系统（OCP 以为的系统）的基于事件的告警。
告警聚合
聚合告警是指，把告警消息以预设规则合并成少量告警消息（称之为聚合消息），以防止告警风暴。
如下，是告警的聚合配置，这是一个深度优先匹配规则，如 OceanBase 日志告警（ob_log_alarm）的聚合维度是 alarm_type（告警项）+ob_error_code（日志错误码）+obregion（OceanBase 集群名）。
aggregate:
# root 层为默认聚合，按照 告警类型，对象 进行聚合
match: {}
group_by:
- "alarm_type"
aggregate_wait_seconds: 10
aggregate_interval_seconds: 60
repeat_interval_seconds: 3600
aggregates:
# 对于 OB 告警，按照 告警类型，OB集群 进行聚合
- match:
app: "OB"
group_by:
- "alarm_type"
- "obregion"
aggregate_wait_seconds: 10
aggregate_interval_seconds: 60
repeat_interval_seconds: 3600
aggregates:
# 对于 OB日志告警，按照 告警类型, 日志错误码，OB集群 进行聚合
- match:
alarm_type: "ob_log_alarm"
group_by:
- "alarm_type"
- "ob_error_code"
- "obregion"
aggregate_wait_seconds: 10
aggregate_interval_seconds: 60
repeat_interval_seconds: 3600
aggregate_wait_seconds 是首次产生高警时等待时长，该时间内产生的相同聚合维度的告警将会聚合为一条告警消息。
aggregate_interval_seconds 是相同聚合维度的聚合周期，即：多久新产生一条聚合的告警消息。
repeat_interval_seconds 是同一告警（相同告警 id，告警未恢复是 id 不会递增）的发送周期，即：同一告警要在下个 repeat_interval_seconds 周期才会被聚合。
告警订阅
告警订阅功能是为了方便将告警消息发送给不同的用户。
首先会将告警项划分为不同的分组，订阅时可直接订阅该告警分组，当前 OCP 划分了如下 6 个告警分组：
ocp：OCP 相关告警项。
dba：OceanBase 数据库相关告警项。
info：操作类（Info 级别）告警项。
oms：OMS 应用告警项。
backup：备份恢复告警项。
dev：运维相关告警项。
可以按照集群、级别订阅告警，将不同的告警发送到不同的告警通道。告警通道定义了如何将告警发送出去，现在支持通过 bash/python 脚本发送，或通过 HTTP API 发送；也支持在通道上设置限流策略，避免发送过多告警。
