-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Round values #198
Comments
I agree with this issue. And we already had this feedback here. Do you have some spare time to address this issue? |
Sure, let me know how and I'll be more than glad to help |
I have no idea how much time it takes to check every query. The last time I went through a large refacto (adding a custom In that case, it may affect only rules using
I just figured out that For percentage rules, we can use I will find some time this week to work on this. You can start with the exporters you know. ;) Basic resource monitoring (88 rules)
Databases and brokers (129 rules)
Reverse proxies and load balancers (43 rules)
Runtimes (3 rules)
Orchestrators (62 rules)
Network and storage (26 rules)
Other (3 rules)
|
I saw there are some round cases in rule config file, for example: |
Hello all,
I just set up some alerts and im pretty happy with the results although some values look kinda off for my human eye when multiple alerts fire up at the same time.
Was thinking if it wouldn't be better to round queries where operators are use and compared to integers.
For example:
round(sum by (name,instance,job) (rate(node_network_receive_bytes_total[2m])) / 1024 / 1024) > 100
108
Instead of:
sum by (name,instance,job) (rate(node_network_receive_bytes_total[2m])) / 1024 / 1024 > 100
108.47109491560195
Are they any pros and cons you can think of?
The text was updated successfully, but these errors were encountered: