Home / Keptn v1 Docs / Release 1.y.z / Reference / Configurations / sli
The sli.yaml file contains definitions of the Service-Level Indicators (SLIs) defined for your Keptn installation. The SLI definition maps a query provided for the observability platform you are using as a data source to a metric value that Keptn uses.
Each SLI is a defined quantitative measure of some aspects of the service level. The query for an SLI is provider/tool-dependent; therefore, each SLI-provider relies on a specific SLI configuration.
Provider-specific SLIs are discussed in the documentation for the integrations of each monitoring platform:
You can also create and add your custom SLI-provider to Keptn. Follow the instructions Custom SLI-Provider.
The SLI configuration contains a list of indicators, each of which always consists of a name and the provider-specific query.
key
value
.You must add the SLI the Keptn service for your monitoring platform to your service, stage, or project.
Important: In the following commands,
the value of the resourceUri
must specify the SLI-provider
that can fetch the declared SLIs.
For Dynatrace, the value of the resourceUri
must be: dynatrace/sli.yaml
.
To add an SLI configuration to a service, use the keptn add-resource command:
keptn add-resource --project=sockshop --stage=staging --service=carts --resource=sli-config.yaml --resourceUri=dynatrace/sli.yaml
To add an SLI configuration to a stage, use the keptn add-resource command:
keptn add-resource --project=sockshop --stage=staging --resource=sli-config.yaml --resourceUri=dynatrace/sli.yaml
Note: This SLI configuration is applied for all services in this stage.
To add an SLI configuration to a project, use the keptn add-resource command:
keptn add-resource --project=sockshop --resource=sli-config.yaml --resourceUri=dynatrace/sli.yaml
Note: This SLI configuration is applied for all services in all stages of this project.
Example of multiple SLI configurations:
Let’s assume we add the following SLI configurations to a project, stage, and service:
spec_version: "1.0"
indicators:
throughput: "query A-1"
error_rate: "query B-1"
response_time_p95: "query C-1"
spec_version: "1.0"
indicators:
response_time_p95: "query C-2"
response_time_p99: "query D-2"
spec_version: "1.0"
indicators:
response_time_p99: "query D-3"
sql-statements: "query E-3"
If an evaluation of a service gets triggered, the following SLI configuration is used:
spec_version: "1.0"
indicators:
throughput: "query A-1" # SLI from project level
error_rate: "query B-1" # SLI from project-level
response_time_p95: "query C-2" # SLI from stage-level overrides SLI from project-level
response_time_p99: "query D-3" # SLI from service-level overrides SLI from stage-level
sql-statements: "query E-3" # SLI from service-level
Different projects, stages, and services within stages can utilize different environments for your SLI. To do this, you create different configuration files for your SLI and have each point to a unique secret that contains the API endpoint for your SLI and a token.
The implementation specifics are different for each SLI provider. As an example, we explain how to do this when using Dynatrace. Consult the documentation for your SLI for the specifics.
Each SLI has a configuration file;
for Dynatrace, it is dynatrace.conf.yaml.
You can create multiple versions of this file to use different environments
for different projects, stages, and services
by locating a version of the file in the appropriate directory in your upstream Git repo.
For example, if your project has the dev
, qa
and prod
stages,
you could create a unique dynatrace.conf.yaml
file in each of these directories on Git.
Within each file, modify the value for the API credentials secret name;
for Dynatrace, this is the dtCreds
field.
The service first looks for a configuration on the service level, then at the stage level, and finally at the project level if no other configurations are found.