New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(resource): ask for metrics only when needed #10359
Conversation
a71ce2e
to
e70deae
Compare
@@ -990,7 +988,7 @@ do_bpapi_call(Node, Call, Args) -> | |||
do_bpapi_call_vsn(SupportedVersion, Call, Args) -> | |||
case lists:member(SupportedVersion, supported_versions(Call)) of | |||
true -> | |||
apply(emqx_bridge_proto_v3, Call, Args); | |||
apply(emqx_bridge_proto_v4, Call, Args); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: isn't this a kind of evading from some of the bpapi checks? 馃
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What scenario do you have in mind? I believe that piece of logic always (silently) assumed that the type (i.e. signature) of an existing RPC does not change across protocol versions. Which in general is not true, but I'm not aware of bpapi checks for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean, dialyzer won't check that Args
type matches the bpapi's wrapper type; only that bpapi's wrapper declared type matches the type of the corresponding remote call.
Co-Authored-By: ieQu1 <99872536+ieQu1@users.noreply.github.com>
2b6e4cd
to
d5ae5eb
Compare
@@ -37,7 +37,6 @@ | |||
list_all/0, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curiosity: list_all/0
still collects the metrics, and it seems to be used only by emqx_resource:list_instances_verbose
, which in turn seems to be for debugging purposes. Maybe we can remove data_record_to_external_map_with_metrics
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm all for it. Just to be clear: do you mean drop metrics from list_instances_verbose/0
output altogether? Or keep the behavior, change the place where metrics are collected?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the latter would be better, so we could drop the ..._map_with_metrics
fn and use the same API to collect metrics when calling this debug function. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think mostly the same, did that in 9c9f39d.
@@ -990,7 +988,7 @@ do_bpapi_call(Node, Call, Args) -> | |||
do_bpapi_call_vsn(SupportedVersion, Call, Args) -> | |||
case lists:member(SupportedVersion, supported_versions(Call)) of | |||
true -> | |||
apply(emqx_bridge_proto_v3, Call, Args); | |||
apply(emqx_bridge_proto_v4, Call, Args); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean, dialyzer won't check that Args
type matches the bpapi's wrapper type; only that bpapi's wrapper declared type matches the type of the corresponding remote call.
Things got much more readable when they got separated. Do I understand correctly that cluster calls in bridge API ware needed only for metrics? |
I wouldn't say so, pretty much all RPCs in |
Now `emqx_resource:list_instances_verbose/0` will populate the metrics for each instance, for the sake of simplicity.
72bcf7c
to
9c9f39d
Compare
Followup to EMQX-9136, EMQX-8375.
Followup to #10123 (comment).
Summary
馃 Generated by Copilot at a71ce2e
This pull request refactors the resource metrics management in the
emqx_resource
app and introduces a new version of the bridge protocol,emqx_bridge_proto_v4
, in theemqx_bridge
app. The new protocol improves the efficiency and scalability of bridge metrics retrieval and separates them from the bridge status and configuration data. The pull request also updates theemqx_authn
andemqx_authz
apps to use the new protocol and modifies some test cases accordingly.PR Checklist
Please convert it to a draft if any of the following conditions are not met. Reviewers may skip over until all the items are checked:
changes/{ce,ee}/(feat|perf|fix)-<PR-id>.en.md
filesFor internal contributor: there is a jira ticket to track this changeIf there should be document changes, a PR to emqx-docs.git is sent, or a jira ticket is created to follow up