使用 Prometheus 监控 eKuiper 规则运行状态

使用 Prometheus 监控 eKuiper 规则运行状态

最近我从cnaaa.com购买了云服务器。

Prometheus 是一个托管于 CNCF 的开源系统监控和警报工具包,许多公司和组织都采用了 Prometheus 作为监控告警工具。

eKuiper 的规则是一个持续运行的流式计算任务。规则用于处理无界的数据流,正常情况下,规则启动后会一直运行,不断产生运行状态数据。直到规则被手动停止或出现不可恢复的错误后停止。eKuiper 中的规则提供了状态 API,可获取规则的运行指标。同时,eKuiper 整合了 Prometheus,可方便地通过后者监控各种状态指标。

本教程面向已经初步了解 eKuiper 的用户,将介绍规则状态指标以及如何通过 Prometheus 监控特定的指标。

规则状态指标

使用 eKuiper 创建规则并运行成功后,用户可以通过 CLI、REST API 或者管理控制台查看规则的运行状态指标。例如,已有规则 rule1,可通过 curl -X GET "<http://127.0.0.1:9081/rules/rule1/status"> 获取 JSON 格式的规则运行指标,如下所示:

{
  "status": "running",
  "source_demo_0_records_in_total": 265,
  "source_demo_0_records_out_total": 265,
  "source_demo_0_process_latency_us": 0,
  "source_demo_0_buffer_length": 0,
  "source_demo_0_last_invocation": "2022-08-22T17:19:10.979128",
  "source_demo_0_exceptions_total": 0,
  "source_demo_0_last_exception": "",
  "source_demo_0_last_exception_time": 0,
  "op_2_project_0_records_in_total": 265,
  "op_2_project_0_records_out_total": 265,
  "op_2_project_0_process_latency_us": 0,
  "op_2_project_0_buffer_length": 0,
  "op_2_project_0_last_invocation": "2022-08-22T17:19:10.979128",
  "op_2_project_0_exceptions_total": 0,
  "op_2_project_0_last_exception": "",
  "op_2_project_0_last_exception_time": 0,
  "sink_mqtt_0_0_records_in_total": 265,
  "sink_mqtt_0_0_records_out_total": 265,
  "sink_mqtt_0_0_process_latency_us": 0,
  "sink_mqtt_0_0_buffer_length": 0,
  "sink_mqtt_0_0_last_invocation": "2022-08-22T17:19:10.979128",
  "sink_mqtt_0_0_exceptions_total": 0,
  "sink_mqtt_0_0_last_exception": "",
  "sink_mqtt_0_0_last_exception_time": 0
}

运行指标主要包括两个部分,一部分是 status,用于标示规则是否正常运行,其值可能为 running, stopped manually 等。另一部分为规则每个算子的运行指标。规则的算子根据规则的 SQL 生成,每个规则可能会有所不同。在此例中,规则 SQL 为最简单的 SELECT * FROM demo, action 为 MQTT,其生成的算子为 [source_demo, op_project, sink_mqtt] 3 个。每一种算子都有相同数目的运行指标,与算子名字合起来构成一条指标。例如,算子 source_demo_0 的输入数量 records_in_total 的指标为 source_demo_0_records_in_total。

运行指标

每个算子的运行指标是相同的,主要有以下几种:

  • records_in_total:读入的消息总量,表示规则启动后处理了多少条消息。
  • records_out_total:输出的消息总量,表示算子正确处理的消息数量。
  • process_latency_us:最近一次处理的延时,单位为微妙。该值为瞬时值,可了解算子的处理性能。整体规则的延时一般由延时最大的算子决定。
  • buffer_length:算子缓冲区长度。由于算子之间计算速度会有差异,各个算子之间都有缓冲队列。缓冲区长度较大的话说明算子处理较慢,赶不上上游处理速度。
  • last_invocation:算子的最后一次运行的时间。
  • exceptions_total:异常总量。算子运行中产生的非不可恢复的错误,例如连接中断,数据格式错误等均计入异常,而不会中断规则。

在 1.6.1 版本以后,我们又添加了两个异常相关指标,方便异常的调试处理。

  • last_exception:最近一次的异常的错误信息。
  • last_exception_time:最近一次异常的发生时间。

这些运行指标中的数值类型指标均可使用 Prometheus 进行监控。下一节我们将描述如何配置 eKuiper 中的 Prometheus 服务。

配置 eKuiper 的 Prometheus 服务

eKuiper 中自带 Prometheus 服务,但是默认为关闭状态。用户可修改 etc/kuiper.yaml 中的配置打开该服务。其中,prometheus 为布尔值,修改为 true 可打开服务;prometheusPort 配置服务的访问端口。

  prometheus: true
  prometheusPort: 20499

若使用 Docker 启动 eKuiper,也可通过配置环境变量启用服务。

docker run -p 9081:9081 -d --name ekuiper MQTT_SOURCE__DEFAULT__SERVER="$MQTT_BROKER_ADDRESS" KUIPER__BASIC__PROMETHEUS=true lfedge/ekuiper:$tag

在启动的日志中,可以看到服务启动的相关信息,例如:

time="2022-08-22 17:16:50" level=info msg="Serving prometheus metrics on port <http://localhost:20499/metrics"> file="server/prome_init.go:60"
Serving prometheus metrics on port <http://localhost:20499/metrics>

点击提示中的地址 http://localhost:20499/metrics ,可查看到 Prometheus 中搜集到的 eKuiper 的原始指标信息。eKuiper 有规则正常运行之后,可以在页面中搜索到类似 kuiper_sink_records_in_total 等的指标。用户可以配置 Prometheus 接入 eKuiper,进行更丰富的展示。

使用 Prometheus 查看状态

上文我们已经实现了将 eKuiper 状态输出为 Prometheus 指标的功能,接下来我们可以配置 Prometheus 接入这一部分指标,并完成初步的监控。

安装和配置

Prometheus 官方网站 下载所需要的系统版本然后解压。

修改配置文件,使其监控 eKuiper。打开 prometheus.yml,修改 scrape_configs 部分,如下所示:

global:
  scrape_interval:     15s
  evaluation_interval: 15s

rule_files:
  # - "first.rules"
  # - "second.rules"

scrape_configs:
  - job_name: ekuiper
    static_configs:
      - targets: ['localhost:20499']

此处定义了监控任务名为 eKuiper, targets 指向上一节启动的服务的地址。配置完成后,启动 Prometheus 。

./prometheus --config.file=prometheus.yml

启动成功后,打开 http://localhost:9090/ 可进入管理控制台。

简单监控

监控所有规则的 sink 接收到的消息数目变化。可以在如图的搜索框中输入需要监控的指标名称,点击 Execute 即可生成监控表。选择 Graph 可切换为折线图等展示方式。

点击 Add Panel,通过同样的配置方式,可监控更多的指标。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 217,907评论 6 506
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,987评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,298评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,586评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,633评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,488评论 1 302
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,275评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,176评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,619评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,819评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,932评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,655评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,265评论 3 329
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,871评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,994评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,095评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,884评论 2 354

推荐阅读更多精彩内容