sloth VS OpenSLO

It’s a CLI that allows developers to embed SLO annotation into GO code as comments and generate Prometheus alert groups when paired with Sloth, https://github.com/slok/sloth.

SLOTH: https://github.com/slok/sloth

Note: Although it’s outside of the scope of this post to dig deep into this topic, in case you’re curious, you can check out what an OpenSLO YAML definition looks like here.

The actual hard part is standardizing all teams on SLI/SLO-based thinking. For that we're looking at tools like Sloth.

Have a look at sloth (https://github.com/slok/sloth) which will help you generate SLOs and error budgets given a PromQL query. This might be easier than trying to calculate it yourself. Plus, it's "metrics as code" and OpenSLO spec compliant.

If you are in k8s and use Prometheus you could take a look at sloth: https://github.com/slok/sloth which can either generate the rules/alerts for you, or can run as an operator and allows you to write SLOs as k8s kinds.

Check out https://github.com/slok/sloth

Are you talking about adopting the open SLO (https://github.com/OpenSLO/OpenSLO) spec? The idea is the yaml that defines SLOs lives along side your application code. Likewise with the markdown files. The idea being as you make changes to your code base you can also control that metrics determine your reliability (yaml) and the reason why those metrics are in place (markdown SLODLC templates - https://www.slodlc.com/templates/SLODLC%20templates).

If you really want to up your SLO game (and you definitely should), you need to define your SLOs as code. This is where OpenSLO comes to the rescue! Originally started up by Nobl9, OpenSLO is an open-source “specification for defining SLOs to enable a common, vendor–agnostic approach to tracking and interfacing with SLOs.” Super dope. Don’t you just love standardization? 💜

[1] url: https://github.com/openslo/openslo