博文推荐|Apache Doris Grafana 监控指标介绍

作者: ApacheDoris

整个集群重点关注的几个指标:

- 集群 FE JVM 堆统计
- 集群BE内存使用情况概览
- Max Replayed journal id
- BDBJE Write
- Tablet调度情况
- BE IO统计
- BE Compaction Score
- Query Statistic这部分查询请求数及响应时间
- BE BC(Base Compaction)和CC(Compaction Cumulate)

1 总览视图

1.1 Doris FE状态

如果FE节点将显示为彩色点表示该节点已经掉线。如果所有前端都活着,则所有点都应为绿色。 

1.2 Doris BE状态

宕机的BE节点将显示为彩色点。如果所有BE都活着,则所有点都应为绿色。

1.3 【重点】集群 FE JVM 堆统计

每个 Doris 集群的每个前端的 JVM 堆使用百分比。

1.4 集群 BE CPU 使用情况

每个 Doris 集群的后端 CPU 使用情况概览。

1.5 【重点】集群BE内存使用情况概览

每个 Doris 集群的 BE 内存使用情况概览。

1.6 集群 QPS

统计 按集群分组的 QPS 统计信息。每个集群的 QPS 是在所有FE处理的所有查询的总和。

1.7 集群磁盘状态 磁盘状态。

绿色点表示该磁盘处于联机状态。红点表示该磁盘处于离线状态,处理离线状态的磁盘表示可能磁盘损坏,需要运维修复或者更换磁盘进行处理。 

2.集群概览

2.1 集群概览

  1. FE Node:总的FE节点数

  2. FE Alive:当前正常的FE节点数

  3. BE Node:集群中BE的节点总数

  4. BE Alive:当前集群中正常存活的BE节点数,如果这个数量和BE Node的数量不一致说明集群中有掉线的BE节点,需要去查看处理

  5. Uesd Capacity:当前集群已使用的磁盘空间

  6. Total Capacity:集群整体存储空间

2.2 【重点】Max Replayed journal id

Doris FE的最大重播元数据日志 ID。正常Master的journal id最大,其他非Master FE节点的这个值基本保持一致,小于Master节点的这值,如果有FE节点这个值和其他节点差别特别大,说明这个节点元数据版本太旧,数据会存在不一致的情况,这种情况下可以将该节点从集群中删除,然后在作为一个新的FE节点加入进来,这样正常情况下这个值和其他节点就会保持一致。  这个值也可以通过Doris的Web界面看到,从下图上看,两个非Master节点的值是一样的,也会存在不一致的情况,不过差别会很小,也会很快的就变成一致的。 

2.3 Image counter

Doris Master FE 元数据image生成计数器。并且 Image 计数器成功推送到其他非Master节点。这些指标预计会以合理的时间间隔增加通常,它们应该相等。 

2.4 【重点】BDBJE Write

这是一个重要监控指标 BDBJE 写入情况,正常都是毫秒级别,如果出现秒级的写入速度就要警惕了,可能会出现元数据写入延迟,严重可能会引起写入错误。 BDBJE:Oracle Berkeley DB Java Edition (opens new window)。在 Doris 中,们使用 bdbje 完成元数据操作日志的持久化、FE 高可用等功能 左侧 Y 轴显示 99th 写入延迟。右侧的 Y 轴显示日志的每秒写入次数。 

2.5 【重点】Tablet调度情况

开始调度运行的Tablet数量。这些 tablet 可能处于recovery 或Balance 过程中 

2.6 【重点】BE IO统计

而对于 IO 操作,目前还没有提供单独的 Compaction 操作的 IO 监控,们只能根据集群整体的 IO 利用率情况来做判断。们可以查看监控图 Disk IO util:  这个监控展示的是每个 BE 节点上磁盘的 IO util 指标。

数值越高表示IO越繁忙。当然大部分情况下 IO 资源都是查询请求消耗的,这个监控主要用于指导们是否需要增加或减少 Compaction 任务数。

2.7 【重点】BE Compaction Score

这是一个重要监控指标
Doris 的数据写入模型使用了 LSM-Tree 类似的数据结构。数据都是以追加(Append)的方式写入磁盘的。这种数据结构可以将随机写变为顺序写。这是一种面向写优化的数据结构,他能增强系统的写入吞吐,但是在读逻辑中,需要通过 Merge-on-Read 的方式,在读取时合并多次写入的数据,从而处理写入时的数据变更。

Merge-on-Read 会影响读取的效率,为了降低读取时需要合并的数据量,基于 LSM-Tree 的系统都会引入后台数据合并的逻辑,以一定策略定期的对数据进行合并。Doris 中这种机制被称为 Compaction

正常这个值在100以内算是正常,不过如果持续接近100这个值,说明你的集群可能存在风险,需要去关注。

这里反映的是集群中每个 BE 节点,所有 Tablet 中数据版本最多的那个 Tablet 的版本数量,可以反映出当前版本堆积情况,

观察数据版本数量的趋势,如果趋势平稳,则说明 Compaction 和导入速度基本持平。如果呈上升态势,则说明 Compaction 速度跟不上导入速度了。

如果呈下降态势,说明 Compaction 速度超过了导入速度。如果呈上升态势,或在平稳状态但数值较高,则需要考虑调整 Compaction 参数以加快 Compaction 的进度。这里需要去参考第七部分BE的 7.10小节 :Base Compaction 和 Cumulative Compaction

通常版本数量维持在 100 以内可以视为正常。而在大部分批量导入或低频导入场景下,版本数量通常为10-20甚至更低。
 如果版本数量有上升趋势或者数值较高,则可以从以下两方面优化 Compaction:

修改 Compaction 线程数,使得同时能够执行更多的 Compaction 任务。

优化单个 Compaction 的执行逻辑,使数据版本数量维持在一个合理范围。

3.QUERY STATISTIC

这部分主要是监控整个集群各种请求情况,Select查询及响应时间 3.1 RPS 每个FE的每秒请求数。请求包括发送到FE的所有请求。 

3.2 【重点】QPS

每个FE的每秒查询数。查询仅包括 Select 请求。 

3.3 99th Latency

每个FE 的 99th个查询延迟情况。 

3.4 【重点】查询效率、失败查询及连接数

  1. Query Percentile:左 Y 轴表示每个FE的 95th 到 99th 查询延迟的情况。右侧 Y 轴表示每 1 分钟的查询率。

  2. Query Error:左 Y 轴表示累计错误查询次数。右侧 Y 轴表示每 1 分钟的错误查询率。通常,错误查询率应为 0。

  3. Connections:每个FE的连接数量

4.JOB作业信息

4.1 Mini Load Job

每个负载状态下的Mini Load 作业数量的统计。这个已经慢慢废弃不在使用

  • 4.2 Hadoop Load Job 每个负载状态下的Hadoop Load 作业数量的统计。
  • 4.3 Broker Load Job 每个负载状态下的Broker Load 作业数量的统计。
  • 4.4 Insert Load Job 由 Insert Stmt 生成的每个 Load State 中的负载作业数量的统计。
  • 4.5 Mini load tendency Mini Load 作业趋势报告
  • 4.6 Hadoop load tendency Hadoop Load 作业趋势报告
  • 4.7 Broker load tendency Broker Load 作业趋势报告
  • 4.8 Insert Load tendency Insert Stmt 生成的 Load 作业趋势报告
  • 4.9 Load submit 显示已提交的 Load 作业和 Load 作业完成的计数器。

如果Load 提交是Routine 操作,则这两行显示为并行。右侧 Y 轴显示加载作业的提交率 

4.10 SC Job

正在运行的Schema 更改作业的数量。 4.11 Rollup Job 正在运行Rollup 构建作业数量 4.12 Report queue size Master FE 中报告的队列大小。

5.TRANSACTION

5.2 Txn Begin/Success on FE 显示Txn 开始和成功的数量和比率 

5.2 Txn Failed/Reject on FE

显示失败的 txn 请求。包括被拒绝的请求和失败的 txn 

5.3 Publish Task on BE

发布任务请求总数和错误率。 

5.4 Txn Requset on BE

在 BE 上显示 txn 请求 这里包括:begin,exec,commit,rollback四种请求的统计信息 

5.5 Txn Load Bytes/Rows rate

左 Y 轴表示 txn 的总接收字节数。右侧 Y 轴表示 txn 的Row 加载率。 

6.FE JVM

这块内容主要是统计分析Doris FE JVM内存使用情况监控 6.1 FE JVM Heap 指定FE 的 JVM 堆使用情况。左 Y 轴显示已使用/最大堆大小。右 Y 轴显示使用的百分比。 

6.2 JVM Non Heap

指定FE 的 JVM 非堆使用情况。左 Y 轴显示使用/提交的非堆大小。 

6.3 JVM Direct Buffer

指定 FE 的 JVM 直接缓冲区使用情况。左 Y 轴显示已用/容量直接缓冲区大小。 

6.4 JVM Threads

集群FE JVM线程数 

6.5 JVM Young

指定 FE 的 JVM 年轻代使用情况。左 Y 轴显示已使用/最大年轻代大小。右 Y 轴显示使用的百分比。 

6.6 JVM Old

指定 FE 的 JVM 老年代使用情况。左 Y 轴显示已使用/最大老年代大小。右 Y 轴显示使用的百分比。通常,使用百分比应小于 80%。 

6.7 JVM Young GC

指定 FE 的 JVM 年轻 gc 统计信息。左 Y 轴显示年轻 gc 的时间。右 Y 轴显示每个年轻 gc 的时间成本。 

6.8 JVM Old GC

指定 FE 的 JVM 完整 gc 统计信息。左 Y 轴显示完整 gc 的次数。右 Y 轴显示每个完整 gc 的时间成本。 

这部分内容主要是监控BE的CPU,内存,网络,磁盘,tablet,Compaction等指标

7.1 BE CPU Idle

BE 的 CPU 空闲状态。低表示 CPU 忙。说明CPU的利用率越高 

7.2 BE Mem

这里是监控集群中每个BE的内存使用情况 

7.3 Net send/receive bytes

每个BE节点的网络发送(左 Y)/接收(右 Y)字节速率,除了"IO” 

7.4 Disk Usage

BE节点的磁盘利用率 

7.5 Tablet Distribution

每个BE节点上的Tablet分布情况,原则上分布式均衡的,如果差别特别大,就需要去分析原因 

7.6 BE FD count

BE的文件描述符( File Descriptor)使用情况。左 Y 轴显示使用的 FD 数量。

右侧 Y 轴显示软限制打开文件数。 FileDescriptor 顾名思义是文件描述符 ,FileDescriptor 可以被用来表示开放文件、开放套接字等。比如用 FileDescriptor 表示文件来说: 当 FileDescriptor 表示文件时,们可以通俗的将 FileDescriptor 看成是该文件。但是,们不能直接通过 FileDescriptor 对该文件进行操作。 若需要通过 FileDescriptor 对该文件进行操作,则需要新创建 FileDescriptor 对应的 FileOutputStream 或者是 FileInputStream,再对文件进行操作,应用程序不应该创建他们自己的文件描述符。 

7.7 BE Thread Num BE的线程数

7.9 Disk IO util BE

的IO util。高表示 I/O 繁忙。 

7.10 【重点】BE BC(Base Compaction)和CC(Compaction Cumulate)

这个和2.7小节的Base Compaction Score关联使用排查问题

  1. Base Compaction : BE全量压缩率,通常,基本压缩仅在 20:00 到 4:00 之间运行并且它是可配置的。右 Y 轴表示总基本压缩字节。

  2. Compaction Cumulate: BE增量压缩率,右 Y 轴表示总累积压缩字节。 Doris 的 Compaction分为两种类型:base compaction和cumulative compaction。其中cumulative compaction则主要负责将多个最新导入的rowset合并成较大的rowset,而base compaction会将cumulative compaction产生的rowset合入到start version为0的基线数据版本(Base Rowset)中,是一种开销较大的compaction操作。这两种compaction的边界通过cumulative point来确定。base compaction会将cumulative point之前的所有rowset进行合并,cumulative compaction会在cumulative point之后选择相邻的数个rowset进行合并。 

7.11 BE Scan / Push

  1. Scan Bytes:BE扫描效率,这表示处理查询时的读取率。

  2. Push Rows:BE的Load Rows效率,这表示在Load作业的 LOADING 状态下加载的行的速率。右侧 Y 轴显示集群的总推送率。 

7.12 Tablet Meta Write

Y 轴显示了保存在rocksdb 中的tablet header 的写入速率。右侧 Y 轴显示每次写入操作的持续时间。 

7.13 BE Scan Rows

BE 的行扫描速率,这表示处理查询时的读取行率。 

7.14 BE Scan Bytes

BE的扫描速率,这表示处理查询时的读取字节速率。 

7.15 Table Meta Read

Y 轴显示了保存在rocksdb 中的tablet header 的读取速率。右侧的 Y 轴显示每次读取操作的持续时间。 

8 BE TASK

8.1 Tablet Report

左侧 Y 轴表示指定任务的失败率。通常,它应该是 0。右侧 Y 轴表示所有 Backends 中指定任务的总数。 

8.2 Single Tablet Report

左侧 Y 轴表示指定任务的失败率。通常,它应该是 0。右侧 Y 轴表示所有 Backends 中指定任务的总数。 

8.3 Finish task report

左侧 Y 轴表示指定任务的失败率。通常,它应该是 0。右侧 Y 轴表示所有 Backends 中指定任务的总数。 

8.4 Push Task

左侧 Y 轴表示指定任务的失败率。通常,它应该是 0。右侧 Y 轴表示所有 Backends 中指定任务的总数。 

8.5 Push Task Cost Time

每个BE推送任务的平均消耗时间。 

8.6 Delete Task

左侧 Y 轴表示指定任务的失败率。通常,它应该是 0。右侧 Y 轴表示所有 Backends 中指定任务的总数。 

8.7 【重点】Base Compaction Task Base Compaction任务的运行情况

左侧 Y 轴表示指定任务的失败率。通常,它应该是 0。右侧 Y 轴表示所有 Backends 中指定任务的总数。 

8.8 【重点】Cumulative Compaction

Task Cumulative Compaction任务运行情况
左侧 Y 轴表示指定任务的失败率。通常,它应该是 0。右侧 Y 轴表示所有 Backends 中指定任务的总数。 

8.9 Clone Task

左侧 Y 轴表示指定任务的失败率。通常,它应该是 0。右侧 Y 轴表示所有 Backends 中指定任务的总数。 

8.10 BE Compaction Base

BE的Base Compaction压缩速率,通常,基本压缩仅在 20:00 到 4:00 之间运行并且它是可配置的。右测 Y 轴表示总基本压缩字节。 具体的参数配置可以参考官网的BE 配置项 

8.11 Create tablet task

创建tablet任务的统计信息 左侧 Y 轴表示指定任务的失败率。通常,它应该是 0。右侧 Y 轴表示所有 Backends 中指定任务的总数。 

8.12 Create rollup task

创建rollup的任务统计 左侧 Y 轴表示指定任务的失败率。通常,它应该是 0。右侧 Y 轴表示所有 Backends 中指定任务的总数。 

8.13 Schema Change

Task Schema 变更任务统计 左侧 Y 轴表示指定任务的失败率。通常,它应该是 0。右侧 Y 轴表示所有 Backends 中指定任务的总数。 

欢迎扫码关注:

Apache Doris(incubating)官方公众号

Apache Doris官方网站:
http://doris.incubator.apache.org
Apache Doris Githu b:
https://github.com/apache/incubator-doris
Apache Doris 开发者邮件组:
dev@doris.apache.org

更多推荐

更多
  • Pulsar消息队列-一套高可用实时消息系统实现 实时消息【即时通信】系统,有群聊和单聊两种方式,其形态异于消息队列:1 大量的 group 信息变动,群聊形式的即时通信系统在正常服务形态下,瞬时可能有大量用户登入登出。2 ...
  • Pulsar消息队列-Pulsar对比Kafka笔记 很多人查看 Pulsar 之前可能对 Kafka 很熟悉,参照上图可见二者内部结构的区别,Pulsar 和 Kafka 都是以 Topic 描述一个基本的数据集合,Topic 数据又分为若干 Partition,即对数据进行逻辑上的 ...
  • Pulsar消息队列-对 2017 年一套 IM 系统的反思 信系统的开发,前前后后参与或者主导了六七个 IM 系统的研发。上一次开发的 IM 系统的时间点还是 2018 年,关于该系统的详细描述见 [一套高可用实时消息系统实现][1] ...
  • Apache APISIX文档-快速入门指南-如何构建 Apache APISIX 如何构建 Apache APISIX,步骤1:安装 Apache APISIX,步骤2:安装 etcd,步骤3:管理 Apache APISIX 服务,步骤4:运行测试案例,步骤5:修改 Admin API key,步骤6:为 Apac
  • Apache APISIX文档-快速入门指南-快速入门指南 快速入门指南,概述,前提条件,第一步:安装 Apache APISIX,第二步:创建路由,第三步:验证,进阶操作,工作原理,创建上游服务Upstream,绑定路由与上游服务,添加身份验证,为路由添加前缀,APISIX Dashboard
  • Apache APISIX文档-架构设计-APISIX APISIX,软件架构,插件加载流程,插件内部结构,配置 APISIX,插件加载流程,比如指定 APISIX 默认监听端口为 8000,并且设置 etcd 地址为 http://foo:2379, 其他配置保持默认。在 ...
  • Apache APISIX文档-架构设计-Service Service 是某类 API 的抽象(也可以理解为一组 Route 的抽象)。它通常与上游服务抽象是一一对应的,Route 与 Service 之间,通常是 N:1 的关系,参看下图。不同 Route 规则同时绑定到一个 Service ...
  • Apache APISIX文档-架构设计-Plugin Config 如果你想要复用一组通用的插件配置,你可以把它们提取成一个 Plugin config,并绑定到对应的路由上。举个例子,你可以这么做:创建 Plugin config,如果这个路由已经配置了 plugins,那么 Plugin config ...
  • Apache APISIX文档-架构设计-Debug Mode 注意:在 APISIX 2.10 之前,开启基本调试模式曾经是设置 conf/config.yaml 中的 apisix.enable_debug 为 true。设置 conf/debug.yaml 中的选项,开启高级调试模式。由于 ...
  • Apache APISIX文档-架构设计-Consumer 如上图所示,作为 API 网关,需要知道 API Consumer(消费方)具体是谁,这样就可以对不同 API Consumer 配置不同规则。授权认证:比如有 [key-auth] 等。获取 consumer_...
  • 近期文章

    更多
    文章目录

      推荐作者

      更多