# SLO Converter ![crates.io](https://img.shields.io/crates/v/slo-converter.svg) SLO converter is a command line interface that converts [YAML](https://yaml.org/), adhering to the [Figure SLO Schema](TODO), to [HCL](https://www.terraform.io/language/syntax/configuration). ## Usage ``` cargo install slo-converter ``` ``` A command line tool that can convert particular YAML schemas to Terraform HCL while also providing support for mustache templating. Usage: slo-converter [OPTIONS] --env [KEY_VALUES]... Arguments: Path to YAML file [KEY_VALUES]... Key/value pairs delineated with "=" which can render with mustache templating (e.g. k1=v1 k2=v2) Options: --output [default: stdout] [possible values: stdout] --env [possible values: development, figure-pay-test, figure-pay-sandbox, figure-pay-prod, figure-tech, figure-tech-test, pio, pio-test, production] -l, --lint Returns a status code based on input parsing -h, --help Print help -V, --version Print version ``` ``` slo-converter --env figure-pay-test yaml/one-slo.yaml ``` ## Templated Values Mustache style templating is supported for all fields in the yaml file. This is most useful for environment specific tags or alerting channels. Values are passed with the following parameters (see yaml/multiple-slo.yaml for syntax usage): ``` slo-converter --env development yaml/multiple-slo.yaml critical_alert=\@slack-eng-tech warn_alert=\@slack-eng-tech ``` ## Creating SLOs for Figure Products [Notion documentation](https://www.notion.so/figuretech/Service-Level-Objectives-SLOs-9065e6ca3abf4aca880a040c308ceb0e) [Github Action](https://github.com/FigureTechnologies/devops-actions/tree/main/slo-converter-pr) ## Assisting Initial SLO Development There's a few domain specific gotchas. A handy script is provided that can be ran like this. ```bash ./resource_helper.sh service-task development ``` NOTE: This script samples recent traces from Datadog. In order to get the best results, you should run against an environment that receives the most traffic. The output of this script will help inform you if your service is using `netty` vs `tomcat`. This is important because your web service metrics will differ, e.g. `trace.netty.request`, `trace.servlet.request`. It will also help you verify your health check endpoints, as services use differing conventions. ## Further SLO/SLI Resources - https://docs.datadoghq.com/monitors/service_level_objectives/ - https://www.datadoghq.com/blog/slo-monitoring-tracking/ - https://www.datadoghq.com/blog/define-and-manage-slos/