尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

EMQX 监控增强:理解 `/monitor_current` API 新增的 `rules_matched` 与 `actions_executed` 指标

EMQX 监控增强:理解 `/monitor_current` API 新增的 `rules_matched` 与 `actions_executed` 指标 EMQX 监控增强理解/monitor_currentAPI 新增的rules_matched与actions_executed指标【免费下载链接】emqxThe most scalable and reliable MQTT broker for AI, IoT, IIoT and connected vehicles项目地址: https://gitcode.com/gh_mirrors/em/emqxEMQX 在 Dashboard 监控体系中新增了两个面向规则引擎的实时指标rules_matched规则匹配次数与actions_executed动作执行次数并同时提供它们对应的速率指标*_rate通过GET /monitor_currentHTTP API 即可获取。本文以本次变更记录为线索结合仓库源码详细说明这两个指标的定义、数据来源、采样与速率计算原理以及如何通过 API 与测试用例验证它们。变更概览本次变更记录于 changes/ee/feat-16135.en.md为GET /monitor_currentHTTP API 新增了两个指标及其对应速率rules_matched规则被匹配的次数触发次数。actions_executed动作执行次数即“成功 失败”的总执行次数。两者都同时具备累计计数器值与实时速率值两种形态速率形态即rules_matched_rate与actions_executed_rate。这使运维人员不仅能查看规则引擎的累计工作量还能直接观察到单位时间内的吞吐与压力变化。从实现上看这两个指标属于数据集成Data Integration维度与已有的actions_messages动作处理的消息数指标并列统一由 Dashboard 监控采样模块采集。指标定义与数据来源底层计数器rules.matched与actions.executed/monitor_current返回的指标并不是独立实现的一套数据而是对 EMQX 全局统计计数器counter的再采样。在 emqx_metrics.erl 中规则与动作相关指标被定义为data_integration_metrics/0%% Rule and Action related metrics data_integration_metrics() - [ {counter, rules.matched, ?DESC(rules_matched)}, {counter, actions.executed, ?DESC(actions_executed)}, {counter, actions.messages, ?DESC(actions_messages)} ].这些计数器为counter类型采用累加语义自节点启动或计数器重置以来累计的触发次数。它们的含义分别是rules.matched所有规则被消息匹配命中的累计次数actions.executed所有规则动作被执行的总次数含成功与失败actions.messages动作实际处理的消息累计条数。需要注意的是actions.executed统计的是执行动作的次数而不是处理的消息条数——一条消息触发一个动作记为一次执行而actions.messages才统计该动作处理的消息量两者口径不同。计数器的实际写入位置rules.matched计数器的自增发生在规则引擎运行时。在 emqx_rule_runtime.erl 中每当规则被命中时执行ok emqx_metrics:inc_global(rules.matched),inc_global表示写入的是集群级全局计数器在集群各节点间聚合因此/monitor_current返回的rules_matched在集群视角下是所有节点规则命中次数的总和。采样器rules_matched与actions_executed监控层通过采样器读取上述计数器。在 emqx_dashboard_monitor.erl 中新增的两个指标被纳入标准采样列表stats(rules_matched) - emqx_metrics:val_global(rules.matched); stats(actions_executed) - emqx_metrics:val_global(actions.executed); stats(actions_messages) - emqx_metrics:val_global(actions.messages).随后在 emqx_dashboard.hrl 中它们被声明为delta 型采样项差分采样项并映射出对应的速率键名-define(DELTA_SAMPLER_LIST, [ received, sent, validation_succeeded, validation_failed, transformation_succeeded, transformation_failed, dropped, persisted, rules_matched, actions_executed, actions_messages ]). -define(DELTA_SAMPLER_RATE_MAP, #{ ... rules_matched rules_matched_rate, actions_executed actions_executed_rate, actions_messages actions_messages_rate }).关键点在于rules_matched与actions_executed属于delta差分采样项与received、sent、dropped等消息吞吐指标同级而不是connections、topics这类 gauge瞬时值指标。这意味着监控系统在每个采样周期记录计数器的当前值然后通过相邻两次采样的差值计算速率。/monitor_current的速率计算原理/monitor_current返回的是实时速率快照current rate而非历史曲线。其核心逻辑在 emqx_dashboard_monitor.erl 的handle_call(current_rate, ...)中handle_call(current_rate, _From, State #state{last Last}) - NowTime now_ts(), NowSamplers take_sample(NowTime, Last, read_hwmark), Rate cal_rate(NowSamplers, Last), NonRateValue non_rate_value(), Result1 maps:merge(Rate, NonRateValue), Result format_hwmarks(Result1, NowSamplers), {reply, {ok, Result}, State};其计算过程为采样当前值take_sample/3从emqx_metrics:val_global/1读取rules.matched、actions.executed等计数器的当前累计值计算差值cal_rate/2将本次采样值与上一次采样值相减得到采样间隔内的增量换算速率cal_rate_/2将增量除以时间差向上取整至至少 1 秒得到每秒速率cal_rate_(Key, {Now, Last, TDelta, Res}) - NewValue maps:get(Key, Now), LastValue maps:get(Key, Last, 0), Rate round(max(NewValue - LastValue, 0) * 1000 / max(TDelta, 1000)), RateKey maps:get(Key, ?DELTA_SAMPLER_RATE_MAP), {Now, Last, TDelta, Res#{RateKey Rate}}.从这段实现可以推断两点设计细节速率永远非负使用max(NewValue - LastValue, 0)保证即使节点重启或计数器重置导致差值变小也不会返回负速率时间差至少取 1 秒max(TDelta, 1000)避免除以零或出现不合理的超高瞬时速率。rules_matched_rate与actions_executed_rate正是通过这个通用 delta 计算流水线得出的。采样周期与数据保留采样间隔监控采样由emqx_dashboard_monitor这个gen_server周期性触发。采样间隔可通过配置调整默认 10 秒见 emqx_dashboard_monitor.erlsample_interval() - emqx_conf:get([dashboard, sample_interval], ?DEFAULT_SAMPLE_INTERVAL) * 1000.其中?DEFAULT_SAMPLE_INTERVAL在 emqx_dashboard.hrl 中定义为 10秒测试环境下为 1秒以加速测试。采样定时器会对齐到整秒边界如00:00:00、00:00:10、00:00:20保证集群内所有节点的采样时刻对齐见 emqx_dashboard_monitor.erl 的next_interval/0从而在聚合集群指标时各节点数据点处于同一时间桶。数据保留与降采样历史采样数据保存在 mria 的emqx_dashboard_monitor表中disc_copies磁盘副本默认保留 7 天。为防止数据点过多系统会按数据年龄进行降采样见 emqx_dashboard_monitor.erl数据龄 1 分钟按 1 秒采样 1 小时按 10 秒采样 1 天按 1 分钟采样 3 天按 5 分钟采样 7 天按 10 分钟采样。通过这种分层降采样数据点总数被控制在约 1000 条以内兼顾历史曲线精度与存储开销。API 使用方式与返回结构端点概览相关端点定义在 emqx_dashboard_monitor_api.erl端点说明GET /monitor获取历史采样数据支持latest查询参数单位为秒GET /monitor/nodes/:node获取指定节点的历史采样数据GET /monitor_current获取集群实时速率快照GET /monitor_current/nodes/:node获取指定节点的实时速率快照GET /monitor_current由monitor_current/2处理见 emqx_dashboard_monitor_api.erl未指定节点时对集群所有运行节点做 RPC 采样并合并指定节点时则只返回该节点数据并剔除仅在集群视角有意义的指标。响应字段GET /monitor_current返回的 JSON 对象中与本文主题相关的字段为字段类型含义rules_matchedinteger规则被匹配的累计次数当前速率快照rules_matched_rateinteger规则匹配速率次/秒actions_executedinteger动作执行次数含成功与失败actions_executed_rateinteger动作执行速率次/秒响应中还包含received_msg_rate、sent_msg_rate、connections、topics、node_uptime、license_quota等既有指标以及sessions_hist_hwmark历史水位结构peak_time/peak_value/current_value见 emqx_dashboard_monitor_api.erl。集群与单节点口径差异集群聚合时emqx_dashboard_monitor:merge_cluster_rate/2会将各节点同名字段的数值直接累加见 emqx_dashboard_monitor.erl。但存在少数集群同步指标topics、subscriptions_durable、disconnected_durable_sessions、retained_msg_count、shared_subscriptions、license_quota、sessions_hist_hwmark它们在所有节点上数值一致聚合时采用取值/取最大而非累加避免重复计数。rules_matched与actions_executed属于常规累加指标。此外maybe_reject_cluster_only_metrics/2见 emqx_dashboard_monitor_api.erl会在查询单节点时剔除subscriptions_durable与disconnected_durable_sessions这两个仅在集群视角有意义的指标rules_matched与actions_executed不受影响单节点查询时即为该节点自身的规则命中与动作执行数据。权限要求该 API 归属于?SCOPE_MONITORING监控权限域见 emqx_dashboard_monitor_api.erl调用方需具备监控相关的 API 密钥或 Dashboard 用户权限。测试用例验证仓库测试套件对新增指标与整个/monitor_current行为有完整的覆盖可作为行为契约参考。在 emqx_dashboard_monitor_SUITE.erl 的t_monitor_current_api/1中断言集群视图GET /monitor_current返回的所有 delta 速率键含rules_matched_rate、actions_executed_rate与 gauge 键都存在断言subscriptions_durable、disconnected_durable_sessions等集群同步指标存在断言单节点视图GET /monitor_current/nodes/:node返回的键集合等于gauge delta 速率 − 集群独占指标并且不包含subscriptions_durable与disconnected_durable_sessions。另有针对节点重启场景的回归测试t_monitor_current_node_restarting_apps见 emqx_dashboard_monitor_SUITE.erl确保当节点正在重启应用时GET /monitor_current仍返回 200 而非 500此时监控进程会返回全零速率并合并安全默认值避免 API 崩溃对应 emqx_dashboard_monitor.erl 的异常处理分支。典型应用场景新增指标让规则引擎的可观测性不再局限于消息进出了多少而是深入到数据处理链路规则命中分析通过rules_matched与rules_matched_rate观察规则被触发的频率判断哪些规则处于高负载路径是否存在规则设计过于宽泛导致的重复命中动作执行监控通过actions_executed观察动作如桥接、消息持久化、转发被执行的总次数。由于该指标同时计入成功与失败当actions_executed_rate明显高于对应桥接的成功速率时可以作为动作失败率上升的早期信号容量规划与压测在压测或生产高峰期直接对比rules_matched_rate与actions_executed_rate量化单条消息平均触发多少个动作辅助评估规则引擎瓶颈与集群扩容决策。需要注意的是本文所述行为以当前仓库源码为准rules_matched、actions_executed及其速率指标随/monitor_current的常规路径返回无需额外配置即可生效若需调整采样精度可通过dashboard.sample_interval配置项改变采样周期。【免费下载链接】emqxThe most scalable and reliable MQTT broker for AI, IoT, IIoT and connected vehicles项目地址: https://gitcode.com/gh_mirrors/em/emqx创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表