StarRocks 监控报警配置指南

一、监控告警方案

StarRocks 社区推荐的开源监控方案是Prometheus+Grafana 。StarRocks 提供 了兼容Prometheus 的信息采集接口，Prometheus 可以通过连接BE/FE 的HTTP 端口来获取集群监控指标的metric 信息，存储在自身的时序数据库中。Grafana 则可以将Prometheus  作为数据源来进行图形化展现。搭配StarRocks  提供的 Dashboard 模板，开发者能够便捷的实现StarRocks 集群监控指标的统计展示和 阈值告警。

StarRocks 社区仅提供基于Prometheus 和Grafana 实现的一种StarRocks 可视 化监控方案，原则上不维护和开发这些组件，更多详细的关于Prometheus  和 Grafana 的介绍和使用，请参考对应的官方文档。

下文的内容按照“监控安装-->核心监控项-->配置邮件告警”三个部分展开。

二、监控组件安装

               Prometheus 和Grafana 的端口默认不与StarRocks 冲突，但生产集群仍建议 将监控组件单独部署，以此减少服务资源占用冲突，同时规避混部下该服务器异常宕机时外部无法及时感知的风险。
   此外，Prometheus+Grafana 是无法监控自身服务的存活状态的， 生产环境中 我们通常还会搭配 supervisor 做保活处理，这里暂不展开。
   本次假设我们在中控节点( 192.168.110.23 )使用 root 用户部署监控组件， 对下面的 StarRocks 集群进行监控(StarRocks 集群使用默认端口) 。在我们参考该指南为自己的集群配置监控时，通常只需替换 IP：

说明：Prometheus+Grafana 当前只能监控StarRocks 的FE 和BE，不能监控 Broker。

2.1 Prometheus 部署

2.1.1 Prometheus 下载

Prometheus 的下载网址为：https://prometheus.io/download/
StarRocks 只需要使用Prometheus 的 Server 安装包，以LTS 版本2.45.0 为例， 直接点击下载

或者复制链接使用 wget 下载：

[root@manager  opt]#  wget  https://github.com/prometheus/prometheus/releases/dow nload/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz

不论采用哪种下载方式，在下载完成后，我们将安装包上传或拷贝至manager节点的/opt 目录下。

2.1.2 Prometheus 配置

1) 切换至/opt 目录：

[root@manager ~]# cd /opt

2) 解压安装包：

[root@manager opt]# tar xvf prometheus-2.45.0.linux-amd64.tar.gz

3) 为方便后续程序升级，将解压后的目录重命名为 prometheus：

[root@manager opt]# mv prometheus-2.45.0.linux-amd64 prometheus

4) 创建数据存放目录：

[root@manager opt]# mkdir prometheus/data

5) prometheus  官方只提供了二进制文件 tar 包，为了方便管理， 我们可以创建prometheus 系统服务启动文件：

[root@manager opt]# vim /etc/systemd/system/prometheus.service

输入：

[Unit]
Description=Prometheus service
After=network.target
[Service]
User=root
Type=simple
ExecReload=/bin/sh -c "/bin/kill -1 `/usr/bin/pgrep prometheus`"
ExecStop=/bin/sh -c "/bin/kill -9 `/usr/bin/pgrep prometheus`"
ExecStart=/opt/prometheus/prometheus --config.file=/opt/prometheus/prometheus.y
ml --storage.tsdb.path=/opt/prometheus/data --storage.tsdb.retention.time=30d --stor
age.tsdb.retention.size=30GB
[Install]
WantedBy=multi-user.target

保存退出。
说明：当使用其他目录部署时，注意 ExecStart 命令中的目录需要同步修改 一致。此外， 在启动参数中我们还配置了 Prometheus  中数据存储的过期条件为“30 天”或“大于 30GB”，可以按需修改。

6)修改 prometheus 配置文件 prometheus/prometheus.yml ，这个文件中的配置内 容对格式要求比较严格，修改时需要特别注意空格和缩进。或者我们可以将原始 配置文件重命名，然后粘贴下发需用的内容。

修改原配置文件文件名：

[root@manager opt]# mv prometheus/prometheus.yml prometheus/prometheus_bak.yml

使用 StarRocks 集群信息创建配置文件 prometheus.yml：

[root@manager opt]# vim prometheus/prometheus.yml

输入：

global:
scrape_interval:  15s  #全局的采集间隔，默认是 1m，这里设置为 15s          evaluation_interval:  15s  #全局的规则触发间隔，默认是 1m，这里设置 15s
scrape_configs:
- job_name:  'StarRocks_Cluster01'  #每一个集群称之为一个job，可以自定义名 字作为 StarRocks 集群名
metrics_path:  '/metrics'        #指定获取监控项目的 Restful  API
static_configs:
-  targets:  [' 192.168.110.101:8030','192.168.110.102:8030','192.168.110.103:8
030']
labels:
group:  fe  #这里配置了 FE 的 group，该 group 中包含了 3 个 FE 节点， 需填写各个 FE 对应的 IP 和 http 端口。若部署集群时修改过该端口，这里注意 进行调整
-  targets:  ['192.168.110.101:8040','192.168.110.102:8040','192.168.110.103:8
040']
labels:
group: be  #这里配置了BE 的group，该 group 中包含了3 个BE 节点，需填写各个 BE 对应的 IP 和 http 端口。若部署集群时修改过该端口，这里注意进行调整

在配置文件创建完成后，可使用 promtool 检查配置文件语法是否合规，例 如：

[root@manager opt]# ./prometheus/promtool check config prometheus/prometheus.yml

当看到提示检查通过后，再执行后续操作：

SUCCESS: prometheus/prometheus.yml is valid prometheus config file syntax

7)启动服务：

[root@manager opt]# systemctl daemon-reload
[root@manager opt]# systemctl start prometheus.service

8)查看服务状态：

[root@manager opt]# systemctl status prometheus.service

观察 Active: active (running) 即为启动成功。
prometheus 默认使用的端口为 9090，也可以使用 netstat 命令查看 9090 端口的状态：

[root@manager opt]# netstat -nltp | grep 9090

9)设置开机启动：

[root@manager opt]# systemctl enable prometheus.service

其他相关命令：

停止服务：systemctl stop prometheus.service
重启服务：systemctl restart prometheus.service
热加载配置：systemctl reload prometheus.service
禁用开机启动：systemctl disable prometheus.service

2.1.3  访问 Prometheus
Prometheus 可以通过 Web 页面进行简单的访问。通过浏览器访问其默认的 9090  端口， 即可访问 Prometheus  的页面。例如，我们使用谷歌浏览器访问 192.168.110.23:9090。

在页面中点击导航栏中，Status-->Targets，可以看到配置文件prometheus.yml 中所有分组Job 的监控主机节点。正常情况下，所有节点都应为UP ，表示服务通信正常：

至此，Prometheus 就配置完成了，更详细的资料可以参阅 Prometheus 官方文档：https://prometheus.io/docs/introduction/overview/

2.2 Grafana 部署

2.2.1 Grafana 下载
Grafana 下载网址为：https://grafana.com/grafana/download

找到适用于 CentOS  的安装包， 官方提供的有 rpm 包地址，我们直接使用wget 语句下载

[root@manager  opt]#  wget  https://dl.grafana.com/enterprise/release/grafana-enterpr ise- 10.0.3- 1.x86_64.rpm

2.2.2 Grafana 安装1)使用 yum 命令安装，方便自动安装依赖：

[root@manager  opt]#  yum  -y  install  grafana-enterprise- 10.0.3- 1.x86_64.rpm

2)启动 grafana：

[root@manager  opt]#  systemctl  start  grafana-server.service

3)查看状态：

[root@manager  opt]#  systemctl  status  grafana-server.service

同样， Active: active (running)表示服务已成功启动。
Grafana 默认使用的端口为 3000，使用 netstat 命令验证端口监听状态：

[root@manager  opt]#  netstat  -nltp  |  grep  3000

4)设置开机自启：

[root@manager  opt]#  systemctl  enable  grafana-server.service

5)扩展命令：

关闭服务：systemctl  stop  grafana-server.service
重启服务：systemctl  restart  grafana-server.service
禁用开机自启：systemctl  disable  grafana-server.service

关于Grafana 的使用，详见官方文档：https://grafana.com/docs/grafana/latest/

2.2.3  访问 Grafana
   使用浏览器访问 192. 168. 110.23:3000 ，即可看到 grafana 页面，默认用户名 密码都是 admin，初次登录会提示修改默认的登录密码，若暂时不希望修改密码， 可以点击 Skip 跳过。跳过后即可进入到Grafana 主界面：

2.2.4  数据源配置
配置路径为：Administration  右侧的展开符号-->Data  sources-->Add  data source-->Prometheus

使用我们Prometheus 的信息进行配置，需要修改的配置有：
1) Name：数据源的名称，自定义， 例如 starrocks_monitor

2) URL：Prometheus 的 web 地址，如我们的 http://192. 168. 110.23:9090

3) 完成后单击页面最下放的 Save & test，如果显示Successfully queried the Prometheus API，即表示数据源可用：

2.2.5  配置 DashBoard

1)下载模板：StarRocks 2.5 版本监控模版的下载地址为：

http://starrocks-thirdparty.oss-cn-zhangjiakou.aliyuncs.com/StarRocks-Overview-2.5.j son

浏览器打开下载地址，右键，另存为，在桌面保存即可。这里注意，我们需 要将json 文件下载到“浏览器所在的机器上”，因为 json 模板是需要通过浏览 器上传的，所以这里不要下载到Linux 服务器上，而是需要下载到咱们打开Web所用的机器上

2)配置模板：

点击目录-->Dashboards-->New   右侧的展开符号-->Import-->Upload dashboard JSON file，将下载的json 文件导入。导入后，可以命名Dashboard，默认是 StarRocks  Overview 。同时， 需要选择数据源， 这里选择之前创建的 starrocks_monitor。点击 Import ，即完成导入。之后，可以看到 StarRocks  的Dashboard 展示：

2.2.6  后续访问
   关闭浏览器后，如果需要再次进入监控 Dashboard，还是在浏览器中访问192.168.110.23:3000，输入用户名密码后， 在菜单中点击 Dashboards，在 General目录选择即可

   进入监控页面后，可以在页面右上方手动刷新或配置自动刷新Dashboard 的 时间间隔来观测StarRocks 的集群状态：

三、核心监控项

为了满足开发、运维、DBA 等同学的多重需求，本次社区整理的监控模版包含了尽可能多的监控指标，每项指标的 Description 中也添加了尽量清晰的中文说明。但是，指标项过多也导致了社区一些小伙伴不清楚要重点关注的指标是哪些，因此本次一并整理出实际业务中较常用的一些监控告警规则，仅供参考。

3.1 FE/BE 状态监控

3.2  查询失败监

3.3  外部感知失败监控

3.4  内部操作失败监控

3.5  服务可用性监控

3.6  机器过载监控项

四、配置邮件告警
4.1 配置 SMTP 服务

   Grafana 支持配置钉钉、邮件、Webhook 等多种告警方案，本次我们以通用 性较好的邮件告警举例。
   邮件告警首先需要在 Grafana 中配置 SMTP 信息来用于“邮件发送”。我们 常用的邮箱都支持开启 SMTP 服务，开启服务以及获取授权码的操作不复杂， 网上也有详细的教程，这里不再展开。
   以网易 163 邮箱为例，在部署 Grafana 的节点上，修改 Grafana 配置文件：

[root@manager ~]# vim /usr/share/grafana/conf/defaults.ini

使用我们的SMTP 信息，修改下文标红字体对应的配置，例如：

###################### SMTP / Emailing #####################
[smtp]
enabled = true
#  网易邮箱 host 配置：smtp. 163.com:25
# QQ 邮箱 host 配置：smtp.qq.com:587
host = smtp.163.com:25
user = wumenglongd@163.com
# If the password contains # or;you have to wrap it with triple quotes.Ex
"""#password;"""
password = ABCDEFGHIJKLMNOP   ##  指开启邮箱 SMTP 后获取到的授权密码 cert_file =
key_file =
skip_verify = true    ## Verify SSL for SMTP server
from_address = wumenglongd@163.com    ## Address used when sending out emails
from_name = Grafana
ehlo_identity =
startTLS_policy =
[emails]
welcome_email_on_sign_up = false
templates_pattern = emails/*.html, emails/*.txt
content_types = text/html

配置完成后，重启Grafana 服务：

[root@manager  ~]#  systemctl  daemon-reload
[root@manager  ~]#  systemctl  restart  grafana-server.service

4.2  创建告警渠道

Grafana 中通过配置告警渠道来让我们选择告警触发时通知联系人的方式。点击菜单->Alerting 右侧的展开符号->Contact Points->Add contact point ，在Contact points 页面点击 Add contact point 按钮创建新的告警渠道：

在Name 栏中自定义告警渠道的名称，例如我们填入“StarRocks 开发组”。 在Integration 下拉框中，我们选择通知方式为“Email”：

在Addresses 中输入目标告警人的邮箱地址，这里的邮箱与我们在上文配置 的SMTP 信息中的邮箱厂商没有绑定关系，我们可以使用任意邮箱来接收告警 邮件，但邮件的发件人都为SMTP 中from_address 处配置的邮箱。

当邮件收件人为多个时，各个收件人之间可以用英文分号，英文逗号或者回 车换行分割。

页面中剩余的配置前期都可先使用默认值，需要稍微注意的是“Singleemail” 和“Disable resolved message”这两个选项：

1)“Singleemail”选项：在勾选后， 当目标收件人是多个时， 告警邮件会通过一 封邮件发出，而不是多封。通常建议勾选。

2)“Disable resolved message”选项：在默认情况下，当告警涉及的项恢复时， 例如FE 宕掉触发了告警，我们已手动启动FE 恢复服务后，Grafana 会再发送一 次告警提示服务恢复，若不需要这个恢复提示，可以勾选该选项禁用。通常不建 议禁用。

配置完成后，可以点击图片右上方的“Test”按钮， 再点击弹出框中的“Sent test notification”按钮， 若上文的 SMTP 服务和Addresses 配置都正确，目标邮箱 中就可以收到标题为“TestAlert Grafana”的提示邮件：

在一个告警渠道中，是允许通过Add contact point integration 来配置多种通 知方式的，这里我们不再展开。关于Contact points 的更细节的介绍可参考Grafana官方文档：

https://grafana.com/docs/grafana-cloud/alerting-and-irm/alerting/fundamentals/contac t-points/

在确认可以正常收到告警提示邮件后，就可以点击页面下方的“Save contact point”按钮完成告警渠道的配置。

为了便于后续演示，假设我们在这一步使用不同的邮箱创建了“StarRocks 开发组”和“StarRocks 运维组”两个告警渠道。

4.3  设置通知策略

Grafana 通过“通知策略”来关联 “告警渠道”和“告警规则”。“通知策略” 使用“标签匹配器”为我们提供了一种将不同告警路由到不同接收者的灵活方法， 可以实现运维过程中常规的“告警分组”。

我们先点击：菜单->Alerting 右侧的展开符号->Notification policies ，进入通 知策略配置页面。

进入菜单后，可以看到默认有一个Default policy：

Notification policies 使用的是Tree structure ，Default policy 即表示默认的根 策略，在我们不设置其他策略时，所有的告警规则都会默认匹配至该策略，然后 使用其中配置的Default contact point 默认告警渠道来进行告警。

我们点击Default policy 右侧的省略号->Edit ，编辑Default policy：

Group 分组是Grafana Alerting 中的一个关键概念，它将具有相似性质的告警 实例分类到单个漏斗中，我们本次演示的场景暂时不考虑分组，可以保留默认的分组或者将其中的分组给叉掉：

Group 分组是Grafana Alerting 中的一个关键概念，它将具有相似性质的告警 实例分类到单个漏斗中，我们本次演示的场景暂时不考虑分组，可以保留默认的分组或者将其中的分组给叉掉：

展开 Timing options 窗口， 可以看到有三处时间配置选项 group_wait 、group_interval 和 repeat_interval 。这三个参数的释义描述相对模糊， 先附上官网的参数说明：

Group  wait：The  waiting  time until  the  initial  notification  is  sent  for  a  new  g roup  created by  an  incoming  alert.  Default  30  seconds.
Group  interval：The  waiting  time  to  send  a  batch  of alert  instances  for  existi ng  groups.  This  means  that  notifications  will not be  sent  any  sooner  than  5  mi nutes  (default)  since  the  last batch  of updates  were  delivered,  regardless  of wh ether the  alert  rule  interval  for those  alert  instances  was  lower.  Default  5  minu tes.
Repeat  interval：The  waiting  time  to  resend  an  alert  after  they have  successful ly been  sent.  This  means  notifications  for  firing  alerts  will  be  re-delivered  every  4  hours  (default).  Default  4  hours.

针对 StarRocks 集群，我们可以将这三个时间配置如下图，这样实现的效果 即为：在满足告警条件后的 0s  (group_wait)，会首次发送告警邮件，之后每经 过 1 分钟 (group interval +repeat interval)，会再次发送告警邮件。

说明：上文提到的是“满足告警条件”而非“触发告警阈值”，这是由于为 避免误报， 我们在配置告警规则时， 通常会设置为“触发告警阈值”后持续多长时间才视为“满足告警条件”。

配置完成后点击“Update default policy”完成策略更新。

为了方便演示， 我们再在 Notification policies 页面点击“New nested policy” 按钮创建一个子策略。

子策略中用 Label 表示我们的匹配规则。在子策略中定义的Label，我们可以在后续配置“告警规则”时作为条件进行匹配，例如我们这里配置 Label 为：

在 Contact point 中， 选择告警渠道为“StarRocks 开发组”，这样后续在告警 规则中配置 Label 为“Group=Development_team”的告警项， 就会使用“StarRocks 开发组”这个渠道进行告警。

再下面的几个选项， 我们均使用默认值， 这样简单处理，让子策略继承父策略的 “时间选项”属性。配置完成后点击“Save policy”保存策略：

若大家对通知策略的细节感兴趣， 或者业务中有更复杂的告警场景要求， 可以参考官网文档 notifications 章节：

https://grafana.com/docs/grafana/latest/alerting/fundamentals/notification-policies/not ifications/

4.4  创建告警规则

完成上述准备工作后，就可以开始告警规则的创建。告警规则可在Grafana Dashboard 中配置，使用浏览器访问192. 168. 110.23:9090 ，登陆后可以在页面顶部的搜索栏中快速访问我们前面配置的 Dashboard：

4.4.1 FE/BE 异常监控

对于StarRocks 集群，所有FE 和BE 节点状态需均为alive，任一节点状态 为DEAD 都应触发告警，以便运维或开发人员及时排查异常原因。

为方便演示，我们选用Overview 下的Frontends Status 和Backends Status 指 标项配置对FE 和BE 的状态监控。在Prometheus 中可以配置多套StarRocks 集 群，需注意 Overview 下的这两项是全部集群的而非单套集群的，若需针对单套 集群进行配置，在我们掌握方法后，可以使用Cluster Overview 下的项自行配置。

1 、FE 告警规则配置

对 Frontends Status 配置告警，点击监控项右上角 “三个点”样式的 Menu   菜单按钮， 点击 Edit，在弹出的页面中选择“Alert”菜单， 点击“Create alert rule from this panel”开始创建规则：

整个告警规则的配置需要5 步，我们逐项说明：

1) 规则名称
默认取值为监控项的 title。若集群较多， 也可以添加集群名作为前缀进行区 分，例如：

2) 设置告警规则
这一步操作， 不熟悉 Prometheus 和 Grafana 的同学乍一看会比较懵， 我们先 对原始菜单自上而下做如图处理：

处理完成后的界面为：

接下来我们稍作展开进行解释。

在 Grafana 中配置告警规则通常可分为三步：

①：通过 PromQL 查询获取 Prometheus 中指标项的值，PromQL 是 Prometheus 自己开发的数据查询 DSL 语言，我们在 Dashboard 的json 模板中也有使用到，

每个监控项的 expr 属性即为对应的PromQL。我们可通过点击下图的“Run queries” 按钮来查看查询结果；

② ：对①中的结果数据做函数和模式的处理。通常使用 Last 函数获取最新 的值，使用 Strict 严格模式来保证若非数字数据可以展示为 NaN；

③：对②中的结果设置判断规则。以 FE 为例，FE 状态正常时，②中得到的 结果为 1，若FE 宕掉，则会为0，因此可以设置判断规则为“小于 1”，出现该情况时即会触发告警。

3) 告警规则评估

这里用来配置评估警报规则的频率以及更改其状态的速度 (官网翻译)，通 俗的讲就是在这里配置“多久使用上面的告警规则进行一次检查”，以及“发现 异常后， 这个异常情况持续多久才触发告警(避免单次的抖动引起误报)”。每个 评估组都包含一个独立的评估间隔， 用于确定检查警报规则的频率，这里我们单 独为 StarRocks 生产集群创建新的文件夹 PROD ，在其中创建新的 Evaluation group 为 01：

为该组配置检查周期为每 10 秒一次， 异常持续 30 秒后“满足告警条件”触 发告警：

说明：在前面配置告警渠道章节， 我们提到了 Disable resolved message 选项， 在 集群“对应服务异常恢复”到“发送服务恢复”的邮件的时间受上图 Evaluate every 参数影响，也即 Grafana 进行新的检查发现服务恢复后，就会触发邮件发送。

4) 添加告警说明

通常我们在这里配置告警邮件的内容信息。下图中的Dashboard UID 和Panel ID 分别唯一标识我们的 Dashboard 和监控指标项(可以在监控模板的json 文件中看到)，这里不要手动修改，直接点击“Add annotation”：

在 Choose 下拉框中选择Description ， 自定义添加告警邮件中的描述内容， 例如写为：生产集群 FE 异常，请尽快处理！

5) 匹配通知策略

这里可以与我们 4.3 章节设置的“通知策略”相绑定。在默认什么都不配置 的情况下， 所有告警规则都会匹配到 Default policy，在满足告警条件后， 就会使 用 Default policy 中我们配置的“StarRocks 运维组”告警渠道，向其中配置的邮箱群发告警信息。

若我们想使用前文创建的绑定了“StarRocks 开发组”的子策略，这里的 Label就要和子策略中的对应的上，子策略中 Label 为：

Group=Development_team

Frontends Status 项本次我们就配置对应的 Label  (手动输入后回车)：

配置完成后， 当满足告警条件， 邮件就会发送至“StarRocks 开发组”，Default policy 策略中运维组的同学不会再收到邮件。

全部配置完成后， 点击页面右上方的 Save rule and exit 按钮， 即可保存规则 并退出编辑页面：

2、告警触发测试

我们可以手动停止一个FE 进行告警测试，可以看到Frontends Status 标题右 侧的心形提示符会经历绿、黄、红这三个状态。

绿色：在上次周期检查时，该指标项各实例状态正常，未触发告警。并不保证当 前状态正常，因为检查是周期性的，例如我们上面配置的10s，同时Prometheus 也是15 秒取一个metric 点，所以在服务出现异常后，会有一个时间上的延迟，但通常延迟都不会到分钟级。

黄色：上次周期检查发现该指标项有实例出现了异常， 但异常还未达到上面配置 的“异常持续时间”，不会发送告警， 会继续周期检查，直到异常时间达到了“异常持续时间”。在此期间，若状态恢复，则提示符会变回绿色。

红色： 当黄色异常状态达到“异常持续时间”后， 提示符变为红色， 触发邮件告 警，发送告警邮件。直至异常解除后才恢复绿色。

异常告警邮件示例：

服务恢复邮件示例：

3、手动暂停报警

若异常需要较长时间处理， 或其他原因导致告警持续触发， 为避免一直发送 告警邮件， 临时暂停对此告警规则的评估。

可通过 Dashboard 再次进入该指标项的 Alert 菜单，编辑告警规则：

在Alert evaluation behavior 中打开Pause evaluation 按钮即可：

注意：开启暂停按钮后，也会收到一次服务恢复的邮件提示。

4 、BE 告警规则配置

掌握 FE 的规则配置操作后，BE 的规则配置基本相同， 编辑指标项 Backends
Status，在 Edit rule 页面的主要配置如下：
1) Set an alert rule name：配置为[PROD]Backends Status。
2) Set a query and alert condition：PromSQL 处写为(up{group="be"}) ，其他配置
同 FE，如下图：

3) Alert evaluation behavior：选择上文创建的 PROD 目录和 01 组，“异常持续时间”仍配置为 30s 即可：

4) Add details for your alert rule：Add annotation 后， 选择 Description，输入告警 描述，例如：生产集群 BE 服务异常，请尽快恢复服务。BE 异常后的堆栈信息 会打印在 be.out 中，可根据日志定位原因。

5) Notifications：Labels 配置同 FE。若不配置 Label，使用默认的 Default policy， 告警邮件发送至“运维组”。

4.4.2  查询失败监控

查询失败对应的指标项为 Query Statistic 下的 Query Error，同样编辑该指标 项进入 Alert Rule 配置菜单， 在操作上较之前仍非常接近， 各个配置项的说明如 下：

1) Set an alert rule name：配置为[PROD] Query Error。
2) Set  a  query  and  alert  condition：删除 B  (或者不动它， 都不影响)，在 A 中 取 C 的值，C 中 PromQL 使用原本默认的 rate(starrocks_fe_query_err{job="StarR ocks_Cluster01"}[1m])，它表示每分钟失败的查询条数除以 60s，若一分钟内失败 的查询数超过了 60 次，这个值是可能大于 1 的。此外，“超时”的 SQL 也会被

计入该项。然后在 D 中配置规则为 A IS  ABOVE  0.05 ，如下图：

3) Alert evaluation behavior：选择上文创建的 PROD 目录和 01 组，“异常持续时 间”仍配置为 30s。

4) Add details for your alert rule：Add annotation 后， 选择 Description，输入告警 描述， 例如：查询失败率较高， 需尽快排查资源占用情况或合理配置查询超时时 间 (例如 set global query_timeout=500，单位为秒)。

5) Notifications：Labels 配置同 FE。若不配置 Label，使用默认的 Default policy， 告警邮件发送至“运维组”。

4.4.3  外部感知失败监控

该项主要监控 Schema Change 操作，对应的指标项为 BE tasks 下的 Schema Change，主要监控 Schema Change 失败的速率，发现大于 0 就告警。当触发报警 后通常可调大变更表操作可用的内存上限， 默认为 2G，对应参数为 be.conf 中 memory_limitation_per_thread_for_schema_change=2，可将值调整为 5。各个配置 项的说明如下：

1) Set an alert rule name：配置为[PROD] Schema Change。

2) Set  a  query  and  alert  condition：删除 A  (或者不动它， 都不影响)，在 C 中 取 B 的值， B 中 PromQL 使用原本默认的 irate(starrocks_be_engine_requests_total {job="StarRocks_Cluster01",  type="create_rollup",  status="failed"}[1m]) ，它表示 每分钟失败的 Schema  Change 任务速率，即 1 分钟内失败的任务数除以 60s 的结果。然后，在 D 中配置规则为 C  IS  ABOVE  0 ，如下图：

3) Alert evaluation behavior：选择上文创建的PROD 目录和01 组，“异常持续时 间” 同样可配置为 30s。

4) Add  details  for  your  alert  rule ：Add  annotation 后，选择Description，输入 告警描述，例如：发现变更表任务失败，请尽快排查，通常可调大变更表操作可 用的内存上限，默认为2G，对应参数为be.conf 中memory_limitation_per_thread _for_schema_change=2，可将值调整为5。

5) Notifications：Labels 配置同FE。若不配置Label，使用默认的Default policy， 告警邮件发送至“运维组”。

4.4.4  内部操作失败监控

1 、BE Compaction Score

该指标项对应 Cluster Overview 下的 BE Compaction Score，主要用于监控集 群的 Compaction 压力， 各个配置项的说明如下：

1) Set an alert rule name：配置为[PROD] BE Compaction Score。
2) Set  a  query  and  alert  condition：使用默认值， 只需要修改 C 中规则为 B  IS  ABOVE  800 ，如下图：

3) Alert evaluation behavior：选择上文创建的PROD 目录和01 组，“异常持续时间”同样配置为 30s。

4) Add  details  for  your  alert  rule ：Add  annotation 后，选择Description，输入 告警描述，例如：集群Compaction 压力过大，请排查是否存在高频或高并发的 导入行为，并尽快降低导入频率。若集群CPU、内存和IO 资源充足，可适当加 快集群Compaction 策略。

5) Notifications：Labels 配置同FE。若不配置Label，使用默认的Default policy， 告警邮件发送至“运维组”。

2 、Clone

该指标项对应BE  tasks 中的Clone ，主要指StarRocks 内部副本均衡或副本 修复操作，通常不会失败，各个配置项的说明如下：

1) Set an alert rule name：配置为[PROD] Clone。
2) Set  a  query  and  alert  condition：删除 A  (或者不动它， 都不影响)，在 C 中 取 B 的值， B 中 PromQL 使用原本默认的 irate(starrocks_be_engine_requests_total {job="StarRocks_Cluster01",  type="clone",  status="failed"}[1m])，它表示每分钟失 败的 Clone 任务速率， 即 1 分钟内失败的任务数除以 60s 的结果。然后， 在 D 中配置规则为 C  IS  ABOVE  0 ，如下图：

3) Alert evaluation behavior：选择上文创建的PROD 目录和01 组，“异常持续时 间”同样配置为 30s。

4) Add  details  for  your  alert  rule ：Add  annotation 后，选择Description，输入 告警描述，例如：监测到出现克隆任务失败，请检查集群BE 状态、磁盘状态、网络状态。

5) Notifications：Labels 配置同FE。若不配置Label，使用默认的Default policy， 告警邮件发送至“运维组”。

4.4.5  服务可用性监控

服务可用性监控初步只整理了对 bdb  中元数据日志条数，该项对应 Cluster Overview 下的 Meta Log Count ，各个配置项的说明如下：

1) Set an alert rule name：配置为[PROD] Meta Log Count。
2) Set  a  query  and  alert  condition：使用默认值， 只需要修改 C 中规则为 B  IS  ABOVE  100000，如下图

3) Alert evaluation behavior：选择上文创建的PROD 目录和01 组，“异常持续时 间”同样配置为 30s。

4) Add  details  for  your  alert  rule ：Add  annotation 后，选择Description，输入 告警描述，例如：监测到FE bdb 中元数据条数远大于期望值，这通常代表Che ckpoint 动作失败，请尽快排查fe.conf 中的Xmx 堆内存配置是否合理。

5) Notifications：Labels 配置同FE。若不配置Label，使用默认的Default policy， 告警邮件发送至“运维组”。

4.4.6  机器过载监控项

1 、BE CPU Idle

对应BE 下的BE CPU Idle ，注意Idle 表示空闲，各个配置项的说明如下：

1) Set an alert rule name：配置为[PROD] BE CPU Idle。
2) Set  a  query  and  alert  condition：使用默认值， 只需要修改 C 中规则为 B  IS   BELOW  10 ，如下图：

3) Alert evaluation behavior：选择上文创建的PROD 目录和01 组，“异常持续时 间”同样配置为 30s。

4) Add  details  for  your  alert  rule ：Add  annotation 后，选择Description，输入 告警描述，例如：BE  CPU 存在持续过高的情况，这将严重影响集群中的其他业 务，请尽快排查集群是否异常或是否存在CPU 资源瓶颈。

5) Notifications：Labels 配置同FE。若不配置Label，使用默认的Default policy， 告警邮件发送至“运维组”。

2 、BE Mem

对应 BE 下的 BE Mem ，表示 BE 的内存使用量， 各个配置项的说明如下：

1) Set an alert rule name：配置为[PROD] BE Mem。
2) Set  a  query  and  alert  condition：内存的取值需要根据服务器的实际内存和 m em_limit 做一些粗略处理，例如通过 free  -h 查看当前服务器内存是 61G，因为 F E 和 BE 混部， 我们限制了mem_limit=80%，则 BE 可用的内存实际为 61*0.8≈4 9G，则此处公式可写为： starrocks_be_process_mem_bytes{job="StarRocks_Clust er01"}/(49*1024*1024*1024)，只需要修改 C 中规则为 B  IS  ABOVE  0.9 ，如下图：

3) Alert evaluation behavior：选择上文创建的PROD 目录和01 组，“异常持续时间”同样配置为 30s。

4) Add  details  for  your  alert  rule ：Add  annotation 后，选择Description，输入 告警描述，例如：BE 内存占用已接近BE 可用内存上限，为避免业务失败，请 尽快拓展内存或增加BE 节点。

5) Notifications：Labels 配置同FE。若不配置Label，使用默认的Default policy， 告警邮件发送至“运维组”。

3 、Disks Avail Capacity

对应BE 下的Disk Usage ，该指标表示BE 存储路径所在目录的剩余空间比 例。各个配置项的说明如下：
1) Set an alert rule name：配置为[PROD] Disks Avail Capacity。
2) Set  a  query  and  alert  condition：使用默认值， 只需要修改 C 中规则为 B  IS  
BELOW  0.2 ，如下图：

3) Alert evaluation behavior：选择上文创建的PROD 目录和01 组，“异常持续时 间”同样配置为 30s。

4) Add  details  for  your  alert  rule ：Add  annotation 后，选择Description，输入 告警描述，例如：BE 磁盘可用空间已低于20%，请尽快清理释放磁盘空间或扩 容磁盘。

5) Notifications：Labels 配置同FE。若不配置Label，使用默认的Default policy， 告警邮件发送至“运维组”。

4 、FE JVM Heap Stat

指标项为 Overview 下的 Cluster FE JVM Heap Stat ，在 fe.conf 中我们为 FE 配置了堆内存使用上限值，这个指标可以表示 FE 使用的 JVM  内存占其中的比

例， 各个配置项的说明如下：
1) Set an alert rule name：配置为[PROD] FE JVM Heap Stat。
2) Set  a  query  and  alert  condition：使用默认值， 只需要修改 C 中规则为 B  IS  ABOVE  80 ，如下图：

3) Alert evaluation behavior：选择上文创建的PROD 目录和01 组，“异常持续时 间”同样配置为 30s。

4) Add  details  for  your  alert  rule ：Add  annotation 后，选择Description，输入 告警描述，例如：FE 堆内存使用率过高，请尽快调大fe.conf 中堆内存上限。

5) Notifications：Labels 配置同FE。若不配置Label，使用默认的Default policy， 告警邮件发送至“运维组”。

4.5  查看已创建的规则

在Grafana 中，所有创建的告警规则可以通过菜单->Alerting 右侧的展开按 钮->Alert rules 查看和管理。

展开我们创建的PROD 目录的01 组，可以看到我们配置的所有告警项的状 态和下一轮检查时间，也可以通过这里的编辑按钮对告警规则进行添加或修改：

五、补充说明

5.1  个别指标项值始终为 0

目前监控模板的指标项中，BE IO Util 和Cumulative Compaction Score 会一 直为 0，这是由于当前BE 的Metric 信息中starrocks_be_max_disk_io_util_percent 和starrocks_be_tablet_cumulative_max_compaction_score 这两项始终为0 引起的。 该情况已反馈StarRocks RD，指标项当前先保留。

5.2 Dashboard 无法感知异常

Grafana 页面取值依赖于所在服务器的系统时间，若集群异常后Grafana 页面一直不变，可排查是否由于服务器时钟不一致引起，然后进行集群校时。

5.3  告警分级的实现思路

Grafana 中实现告警分级的方法有比较多，这里补充一种实现比较简单的， 以 Query Error 项为例，我们可以为其创建两个告警规则，设置不同的告警阈值， 例如：
风险： 失败率>0.05 ，提示为风险， 告警发送给开发组；
严重： 失败率>0.20，提示为严重， 告警发送给运维组。因失败率大于 0.2 时自然就大于 0.05，所以此时开发组和运维组都会收到告警通知。

最后，本指南是结合业务对 StarRocks 配置监控告警的归纳整理，让社区的 小伙伴可以不用在网上东拼西凑的找实现方式。若文档中存在描述不正确或不规 范的地方，欢迎社区同学指正。