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:
| Host | IP | 用户 | 部署服务 |
|---|---|---|---|
| node01 | 192.168.110.101 | root | 1 FE + 1 BE |
| node02 | 192.168.110.102 | root | 1 FE + 1 BE |
| node03 | 192.168.110.103 | root | 1 FE + 1 BE |
说明: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 下载:
bash
[root@manager opt]# wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz
不论采用哪种下载方式,在下载完成后,我们将安装包上传或拷贝至 manager 节点的 /opt 目录下。
2.1.2 Prometheus 配置
-
切换至
/opt目录:bash[root@manager ~]# cd /opt -
解压安装包:
bash[root@manager opt]# tar xvf prometheus-2.45.0.linux-amd64.tar.gz -
为方便后续程序升级,将解压后的目录重命名为
prometheus:bash[root@manager opt]# mv prometheus-2.45.0.linux-amd64 prometheus -
创建数据存放目录:
bash[root@manager opt]# mkdir prometheus/data -
Prometheus 官方只提供了二进制文件 tar 包,为了方便管理,我们可以创建 Prometheus 系统服务启动文件:
bash[root@manager opt]# vim /etc/systemd/system/prometheus.service输入以下内容:
ini[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.yml --storage.tsdb.path=/opt/prometheus/data --storage.tsdb.retention.time=30d --storage.tsdb.retention.size=30GB [Install] WantedBy=multi-user.target保存退出。
说明:当使用其他目录部署时,注意
ExecStart命令中的目录需要同步修改一致。此外,在启动参数中我们还配置了 Prometheus 中数据存储的过期条件为“30 天”或“大于 30GB”,可以按需修改。 -
修改 Prometheus 配置文件
prometheus/prometheus.yml,这个文件中的配置内容对格式要求比较严格,修改时需要特别注意空格和缩进。或者我们可以将原始配置文件重命名,然后粘贴下发需用的内容。修改原配置文件文件名:
bash[root@manager opt]# mv prometheus/prometheus.yml prometheus/prometheus_bak.yml使用 StarRocks 集群信息创建配置文件
prometheus.yml:bash[root@manager opt]# vim prometheus/prometheus.yml输入以下内容:
yamlglobal: 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:8030'] 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:8040'] labels: group: be # 这里配置了 BE 的 group,该 group 中包含了 3 个 BE 节点,需填写各个 BE 对应的 IP 和 http 端口。若部署集群时修改过该端口,这里注意进行调整在配置文件创建完成后,可使用
promtool检查配置文件语法是否合规,例如:bash[root@manager opt]# ./prometheus/promtool check config prometheus/prometheus.yml当看到提示检查通过后,再执行后续操作:
bashSUCCESS: prometheus/prometheus.yml is valid prometheus config file syntax -
启动服务:
bash[root@manager opt]# systemctl daemon-reload [root@manager opt]# systemctl start prometheus.service -
查看服务状态:
bash[root@manager opt]# systemctl status prometheus.service观察
Active: active (running)即为启动成功。Prometheus 默认使用的端口为 9090,也可以使用
netstat命令查看 9090 端口的状态:bash[root@manager opt]# netstat -nltp | grep 9090 -
设置开机启动:
bash[root@manager opt]# systemctl enable prometheus.service其他相关命令:
bash停止服务: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 语句下载:
bash
[root@manager opt]# wget https://dl.grafana.com/enterprise/release/grafana-enterprise-10.0.3-1.x86_64.rpm
2.2.2 Grafana 安装
-
使用 yum 命令安装,方便自动安装依赖:
bash[root@manager opt]# yum -y install grafana-enterprise-10.0.3-1.x86_64.rpm -
启动 Grafana:
bash[root@manager opt]# systemctl start grafana-server.service -
查看状态:
bash[root@manager opt]# systemctl status grafana-server.service同样,
Active: active (running)表示服务已成功启动。Grafana 默认使用的端口为 3000,使用
netstat命令验证端口监听状态:bash[root@manager opt]# netstat -nltp | grep 3000 -
设置开机自启:
bash[root@manager opt]# systemctl enable grafana-server.service -
扩展命令:
bash关闭服务: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 的信息进行配置,需要修改的配置有:
-
Name:数据源的名称,自定义,例如starrocks_monitor
-
URL:Prometheus 的 web 地址,如我们的http://192.168.110.23:9090
-
完成后单击页面最下方的
Save & test,如果显示Successfully queried the Prometheus API,即表示数据源可用:
2.2.5 配置 Dashboard
-
下载模板:StarRocks 2.5 版本监控模板的下载地址为:
http://starrocks-thirdparty.oss-cn-zhangjiakou.aliyuncs.com/StarRocks-Overview-2.5.json浏览器打开下载地址,右键,另存为,在桌面保存即可。这里注意,我们需要将 json 文件下载到“浏览器所在的机器上”,因为 json 模板是需要通过浏览器上传的,所以这里不要下载到 Linux 服务器上,而是需要下载到我们打开 Web 所用的机器上。
-
配置模板:
点击目录 -->
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 配置文件:
bash
[root@manager ~]# vim /usr/share/grafana/conf/defaults.ini
使用我们的 SMTP 信息,修改下文标红字体对应的配置,例如:
ini
###################### 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 服务:
bash
[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 处配置的邮箱。
当邮件收件人为多个时,各个收件人之间可以用英文分号、英文逗号或者回车换行分割。
页面中剩余的配置前期都可先使用默认值,需要稍微注意的是“Single email”和“Disable resolved message”这两个选项:
- “Single email”选项:在勾选后,当目标收件人是多个时,告警邮件会通过一封邮件发出,而不是多封。通常建议勾选。
- “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/contact-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 中的一个关键概念,它将具有相似性质的告警实例分类到单个漏斗中,我们本次演示的场景暂时不考虑分组,可以保留默认的分组或者将其中的分组给叉掉:

展开 Timing options 窗口,可以看到有三处时间配置选项 group_wait、group_interval 和 repeat_interval。这三个参数的释义描述相对模糊,先附上官网的参数说明:
Group wait:The waiting time until the initial notification is sent for a new group created by an incoming alert. Default 30 seconds.
Group interval:The waiting time to send a batch of alert instances for existing groups. This means that notifications will not be sent any sooner than 5 minutes (default) since the last batch of updates were delivered, regardless of whether the alert rule interval for those alert instances was lower. Default 5 minutes.
Repeat interval:The waiting time to resend an alert after they have successfully 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/notifications/
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 步,我们逐项说明:
-
规则名称:默认取值为监控项的
title。若集群较多,也可以添加集群名作为前缀进行区分,例如:
-
设置告警规则:这一步操作,不熟悉 Prometheus 和 Grafana 的同学乍一看会比较懵,我们先对原始菜单自上而下做如图处理:

处理完成后的界面为:

接下来我们稍作展开进行解释。
在 Grafana 中配置告警规则通常可分为三步:
- 通过 PromQL 查询获取 Prometheus 中指标项的值,PromQL 是 Prometheus 自己开发的数据查询 DSL 语言,我们在 Dashboard 的 json 模板中也有使用到,每个监控项的
expr属性即为对应的 PromQL。我们可通过点击下图的“Run queries”按钮来查看查询结果; - 对①中的结果数据做函数和模式的处理。通常使用
Last函数获取最新的值,使用Strict严格模式来保证若非数字数据可以展示为NaN; - 对②中的结果设置判断规则。以 FE 为例,FE 状态正常时,②中得到的结果为 1,若 FE 宕掉,则会为 0,因此可以设置判断规则为“小于 1”,出现该情况时即会触发告警。

- 通过 PromQL 查询获取 Prometheus 中指标项的值,PromQL 是 Prometheus 自己开发的数据查询 DSL 语言,我们在 Dashboard 的 json 模板中也有使用到,每个监控项的
-
告警规则评估:这里用来配置评估警报规则的频率以及更改其状态的速度(官网翻译),通俗的讲就是在这里配置“多久使用上面的告警规则进行一次检查”,以及“发现异常后,这个异常情况持续多久才触发告警(避免单次的抖动引起误报)”。每个评估组都包含一个独立的评估间隔,用于确定检查警报规则的频率,这里我们单独为 StarRocks 生产集群创建新的文件夹
PROD,在其中创建新的Evaluation group为01:
为该组配置检查周期为每 10 秒一次,异常持续 30 秒后“满足告警条件”触发告警:

说明:在前面配置告警渠道章节,我们提到了
Disable resolved message选项,在集群“对应服务异常恢复”到“发送服务恢复”的邮件的时间受上图Evaluate every参数影响,也即 Grafana 进行新的检查发现服务恢复后,就会触发邮件发送。 -
添加告警说明:通常我们在这里配置告警邮件的内容信息。下图中的
Dashboard UID和Panel ID分别唯一标识我们的 Dashboard 和监控指标项(可以在监控模板的 json 文件中看到),这里不要手动修改,直接点击“Add annotation”:
在
Choose下拉框中选择Description,自定义添加告警邮件中的描述内容,例如写为:生产集群 FE 异常,请尽快处理!
-
匹配通知策略:这里可以与我们 4.3 章节设置的“通知策略”相绑定。在默认什么都不配置的情况下,所有告警规则都会匹配到
Default policy,在满足告警条件后,就会使用Default policy中我们配置的“StarRocks 运维组”告警渠道,向其中配置的邮箱群发告警信息。
若我们想使用前文创建的绑定了“StarRocks 开发组”的子策略,这里的
Label就要和子策略中的对应的上,子策略中Label为:Group=Development_teamFrontends Status项本次我们就配置对应的Label(手动输入后回车):
配置完成后,当满足告警条件,邮件就会发送至“StarRocks 开发组”,
Default policy策略中运维组的同学不会再收到邮件。全部配置完成后,点击页面右上方的
Save rule and exit按钮,即可保存规则并退出编辑页面: