Duansg commented on code in PR #3673:
URL: https://github.com/apache/hertzbeat/pull/3673#discussion_r2300242590
##########
hertzbeat-common/src/main/java/org/apache/hertzbeat/common/entity/alerter/AlertDefine.java:
##########
@@ -100,6 +100,11 @@ public class AlertDefine {
@Size(max = 100)
private String datasource;
+ @Schema(title = "Query Expression", example = "SELECT * FROM metrics WHERE
value > 90")
+ @Size(max = 2048)
+ @Column(length = 2048)
+ private String queryExpr;
+
Review Comment:
> Hi Tom, thank you for your review. I believe that a two-stage design,
separating the query and alerting phases, is of paramount importance. If we do
not make this separation, our SQL query syntax will be tightly coupled with the
alerting threshold syntax. This coupling would lead to insurmountable syntax
conflicts when adapting to different SQL dialects, such as those used by
Greptime and other databases.
>
> Furthermore, from a user experience perspective, this two-stage model is
more intuitive in UI design. It perfectly aligns with the user's natural mental
model: first defining "What data do I need?" and then determining "What
conditions should trigger an alert?" This approach is much easier to understand
and operate than one that mixes all the logic together.
>
> Finally, it is worth noting that this two-stage model is widely adopted in
mature industry monitoring platforms, such as Alibaba Cloud's Log Service
(SLS). This further validates the stability and maturity of a decoupled
solution.
I also have a question about this. If there is no prompt for the query
field, do I still need to check the information displayed in the relevant log
to correctly configure the threshold expression?
I use SLS more frequently in my daily work. In most cases, I only need
phrase matching. When I need to format information or process other data, I use
SQL to enhance my writing. The convenience lies in the fact that when I
generate threshold expressions, I can quickly generate the required expressions
through AI-powered query generation, historical queries, and prompts. Could we
also adopt this approach?
Then I looked at the code you discussed for this position. As I understand
it, you should first perform a `QueryExpr` query, then use `expr` to perform
JEXL threshold matching. Wouldn't this be a bit complicated? I'm also concerned
that there might be a performance bottleneck when executing a large number of
complex JEXL expressions.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@hertzbeat.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscr...@hertzbeat.apache.org
For additional commands, e-mail: notifications-h...@hertzbeat.apache.org
