Promql is a bit complicated. Is there any way to reduce the difficulty of use？

[Allenzh li]

When create a prometheus alerting rule, the promql is a bit complicated for ordinary users.

Since I want to hide native promql expr and labels, ordinary users only select some metric name or labels in a web page then can create a alerting rule.

Is there any best practice?

Kind regards, 

Allenzh li

[Stuart Clark]

I would be cautious about hiding PromQL. You could create a simple web
page for some types of very basic alerts quite easily, for example a
very simple fixed threshold for a single metric, but in reality those
sort of rules are rarely very common.

One of the big advantages of Prometheus above other systems is the more
expressive query language, which allows for much more useful alerting rules.

Common alerting rules might contain calculations (e.g. a ratio between
metrics), multiple metrics (e.g. comparing a value in two parts of the
system), aggregation (sum or sum_over_time) and rates (increase, rate,
predict_linear). It would be very difficult to represent such queries
via a web page, other than allowing for a text box input.

However, there can be advantages of some extra help via an interface.
Grafana for example allows you to quickly find metrics and gives instant
visualisation as you write your query.

[Allenzh li]

The key problem is that ordinary users need to learn PromQL, even if grafana is provided, the cost of promql learning cannot be reduced.

It is not easy for everyone to learn PromQL.

Kind regards, 

Allenzh li

[Stuart Clark]

On 09/12/2020 08:34, Allenzh li wrote:
> The key problem is that ordinary users need to learn PromQL, even if
> grafana is provided, the cost of promql learning cannot be reduced.
>
> It is not easy for everyone to learn PromQL.

If users need to create/update dashboards or alerts then yes they need
to understand PromQL. They also need to understand the metrics and their
meanings.

I would say this is the case for any database type system, for example
needing to know SQL for MariaDB or KQL for Kibana & Elasticsearch.

For both of those examples tools to allow very simple queries to be
constructed graphically do exist, but you very quickly outgrow them -
all these systems are only fully useful if you are able to use the power
of their different query languages.

The sort of query which can be easily represented on a web page is so
basic that it generally isn't that useful, and trying to represent more
complex queries would quickly become more confusing than seeing the
underlying PromQL. For example how would you visually represent queries
which use sums of rates or join metrics together?

I would suggest as far as query languages go, PromQL isn't that complex.
The basics should be relatively straightforward to learn, with more
complex ideas being things you can add over time to your understanding.
One thing that can be useful for less experienced users are example
queries or cookbooks - often you might find a set of alerts/queries for
dashboards have similarities.

[lizhihua0925]

I agree with you. 

PromQL is a power query language and the web page can’t easily represent the power.

It is also a good idea to provide examples or cookbooks.

Kind regards,
Allenzh li

[Allenzh li]

Just now, I have search some other monitoring systems and find sysdig which have provided a cookbook which how to monitoring kubernetes.

https://sysdig.com/blog/alerting-kubernetes/ 

This is very enlightening to me.

Kind regards, 

Allenzh li