-
Notifications
You must be signed in to change notification settings - Fork 112
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
SLO dependencies / levels / hierarchy #1122
Comments
Generally speaking, Pyrra follows Prometheus' approach using labels instead of using hierarchy. If not, examples would be great. |
Thanks, I'll look into what I can achieve with labels alone. However there will still be the UI part. I like how Pyrra's UI is clean. It gets cluttered though with 10s of services with 10+ of SLOs each. Some form of grouping / filtering would be useful for me. Also - something to consider as inspiration from Prometheus could be alert inhibition. |
I've been thinking about this problem for a while. Defining SLO against services makes sense (eg http request success) but i'd love to create a more As a Senior Developer One idea that came to mind was simply defining SLO's against the Pyrra generated field terms, and then using labels to indicate some sort of 'grouping' attribute as suggested above. Further to @prein 's thoughts, it'd be great if there was a way of indicating 'parent/child' relationships in some capacity such that if an SLO is a compound of other SLO it can be displayed elegantly (or even just have links to eachother) Its not a simple problem to solve, and may be sufficient to give an example of a compound SLO referencing Pyrra metrics? |
Hi, would implementing SLO relations be an idea worth considering?
Where I think would it be useful:
The text was updated successfully, but these errors were encountered: