Awesome

Sloth common sli plugins

Introduction

A collection of common Sloth sli plugins ready to be used on Sloth manifests, or used as examples to create your own.

Getting started

One of the Sloth features are the SLI plugins. These can be loaded dynamically when Sloth is executed and the SLO manifests can reference these plugins and pass some options to set an SLI, instead of writing the SLI query.

To use these plugins you could do:

# Get the plugins.
git clone https://github.com/slok/sloth-common-sli-plugins.git

# Load the plugins and use them (Sloth can load plugins from multiple dirs).
sloth generate -p ./sloth-common-sli-plugins -i {MY_SLO_MANIFEST}

Plugins

• CoreDNS
  • 🔌 Availability: Availability for CoreDNS responses.
  • 🔌 Latency: Latency for CoreDNS responses.
• 🔌 Fake: Fakes burn rates with burn rate options.
• HTTP:
  • slok/go-http-metrics
    • 🔌 Availability: Availability SLI based on slok/go-http-metrics HTTP requests.
    • 🔌 Latency: Latency SLI based on slok/go-http-metrics HTTP requests.
• Kubernetes
  • Apiserver
    • 🔌 Availability: Availability SLI based on API HTTP requests.
    • 🔌 Latency: Latency SLI based on API HTTP requests.
  • Kooper
    • 🔌 Availability: Availability event handling.
    • 🔌 Latency: Latency event handling.
    • 🔌 Queue congestion: Event queue congestion.
• Noop: Example/placeholder that doesn't do anything.
• Prometheus
  • Targets
    • 🔌 Availability: Availability of Prometheus registered targets.
  • Rules
    • 🔌 Eval availability: Availability of Prometheus rules evaluation.
• Traefik
  • v1
    • 🔌 Availability: Availability for Traefik V1 serving backends.
    • 🔌 Latency: Latency for Traefik V1 serving backends.
  • v2
    • 🔌 Availability: Availability for Traefik V2 serving services.
    • 🔌 Latency: Latency for Traefik V2 serving services.
• Istio
  • v1
    • 🔌 Availability: Availability plugin for Istio V1 services.
    • 🔌 Latency: Latency plugin for Istio V1 services.

Contributing

You can contribute with new plugins the same way the ones in plugins, the process would be this:

• Create a directory (or/and subdirectories) group in plugins, only if the group would have more than one SLI plugin (e.g app-x, protocol-y, library-z...).
• Create a directory for each plugin: (e.g availability, latency...).
• Create a plugin.go file with the plugin and a plugin_test.go for the unit tests.
• Create an sloth manifest in test/integration to test that sloth can load and use this plugin correctly.
• Add a README.md on the group and/or the plugin dir and reference the plugin in this readme in plugins section. the readme should have for each plugin at least (example):
  • Introduction.
  • Options.
  • Metric requirements.
  • Usage examples.

You can execute these to test it while developing:

• make check
• make test
• make integration-test