recruitmenthaa.blogg.se - Sli file format

See the example below (for a single indicator because of brevity): sli.yaml (v2.0) The current format could easily be rewritten with the new format, although not adding too much value in this way. Each SLI provider can then specify the structure for these queries on their own. This means we can have total flexibility for all queries, as they can be either a simple string or they can be an object with at least one property. "description": "This object defines the structure for SLI provider specific queries", "description": "This object defines the structure for Service Level Indicators", how Kubernetes defines CRDs).īelow you will see the JSON Schema for the SLI file (The units are copied/pasted from Dynatrace Help pages - maybe not all of them should be taken or even others added? Please also note the two units: NotApplicable and Unspecified). We would propose a new format that allows more flexibility on the SLI provider side:īecause we are relying on Dynatrace APIs for all queries, there is no need to make this more extensible as necessary (e.g. Response_time_p95: "metricSelector=builtin::merge(\"dt.rvice\"):percentile(95)&entitySelector=type(SERVICE),tag(keptn_managed),tag(keptn_service:$SERVICE)" Response_time_p90: "metricSelector=builtin::merge(\"dt.rvice\"):percentile(90)&entitySelector=type(SERVICE),tag(keptn_managed),tag(keptn_service:$SERVICE)" Response_time_p50: "metricSelector=builtin::merge(\"dt.rvice\"):percentile(50)&entitySelector=type(SERVICE),tag(keptn_managed),tag(keptn_service:$SERVICE)" Throughput: "metricSelector=builtin::merge(\"dt.rvice\"):sum&entitySelector=type(SERVICE),tag(keptn_managed),tag(keptn_service:$SERVICE)"Įrror_rate: "metricSelector=builtin::merge(\"dt.rvice\"):avg&entitySelector=type(SERVICE),tag(keptn_managed),tag(keptn_service:$SERVICE)"

indicators is a map of SLI name to provider specific query, both strings.

spec_version is a string that is set to 1.0 and.

The current (1.0) Keptn Service Level Indicator specification is defined as outlined below:

securityProblemSelector (mandatory, String)Īpproach 1: Using a structured object instead of a magic string.

api/v2/securityProblems query parameters:

nextPageKey and pageSize (will not be used).

fields (will be set internally, if at all).

sort (will be set internally, if at all).

This behaviour is necessary for Dashboards, but only queries that produce a single result are allowed for SLI files - which is not the case at the moment! Problem V2

DIMENSION (name of the dimension, that will be matched on the header of the row).

TILE_TYPE (can have values of SINGLE_VALUE, PIE_CHART, COLUMN_CHART, TABLE, determines the position of the value in the row).

endTimestamp (will be set internally from event data)Īdditional Dynatrace Service Parameters from magic strings:.

startTimestamp (will be set internally from event data).

pageOffset and pageSize (will not be used).

addDeepLinkFields (will be set to false internally).explain (will be set to false internally).api/v1/userSessionQueryLanguage/table query parameters: to (will be set internally from event data).from (will be set internally from event data).resolution (will be set to Inf by dynatrace-service).These are the endpoints that are currently supported, but others will/might be added in the future.

MV2 Microsecond metricSelector=., that are used for encoding the final query. Also we want to move away from magic string prefixes e.g. Because with the current format we cannot make sure, that we correctly parse and/or URL encode the user defined queries.