KeptnMetricsProvider
A KeptnMetricsProvider
resource defines an instance of a data provider
(such as Prometheus, Thanos, Cortex, Dynatrace, or Datadog)
that is used by one or more KeptnMetric resources.
One Keptn application can perform
traces, evaluations, and analyses based on metrics
from more than one data provider
and, beginning with the API version v1alpha3,
can use more than one instance of each data provider.
To implement this, create a KeptnMetricsProvider
resource
for each instance of each data provider being used,
then reference the appropriate provider
for each metric definition by its name.
Yaml Synopsis
apiVersion: metrics.keptn.sh/v1
kind: KeptnMetricsProvider
metadata:
name: <data-source-instance-name>
namespace: <namespace>
spec:
type: cortex | datadog | dql | dynatrace | prometheus | thanos
targetServer: "<data-source-url>"
secretKeyRef:
name: <secret-name>
key: <secret-key-that-holds-token>
optional: true | false
Fields
-
apiVersion -- API version being used.
-
kind -- Resource type. Must be set to KeptnMetricsProvider
-
metadata
-
name -- Unique name of this provider, used to reference the provider for the KeptnEvaluationDefinition and KeptnMetric resources. Names must comply with the Kubernetes Object Names and IDs specification.
For example, you might define
dev-prometheus
for the Prometheus instance that monitors the development deployment, andqa-prometheus
for the Prometheus instance that monitors the Prometheus instance that monitors the QA deployment, andprod-dynatrace
for the Dynatrace instance that monitors the production deployment. -
namespace -- Namespace where this provider is used.
-
-
spec
- type (required) -- The type of data provider for this instance
- targetServer (required) -- URL of the data provider, enclosed in double quotes
- secretKeyRef
- name: -- Name of the Secret used by the provider
- key: -- Key of the Secret from which to select
- optional -- Specify whether the Secret or its key must be defined
Usage
A KeptnMetricsProvider resource must be located in the same namespace as the KeptnMetric resources that are associated with it. KeptnMetric resources are used to generate metrics for the cluster and are used as the SLI (Service Level Indicator) for the KeptnEvaluationDefinition and AnalysisValueTemplate resources.
KeptnEvaluationDefinition
resources can reference metrics
from any namespace.
This means that you can create KeptnMetricsProvider
and KeptnMetric
resources
in a centralized namespace (e.g. in keptn-system
)
and access those metrics in evaluations
on all namespaces in the cluster.
Metrics providers may require authentication data.
These can be stored in a Secret and referenced in the KeptnMetricsProvider
.
Those Secret resources need to be configured differently for each metrics provider.
The Secret holding the data must have a specific structure
and contain the required data fields.
For detailed information please look at the Examples section.
Examples
An example of Prometheus, Thanos or Cortex as a metrics provider with a Secret holding the authentication data looks like the following:
apiVersion: metrics.keptn.sh/v1
kind: KeptnMetricsProvider
metadata:
name: prometheus-provider
namespace: podtato-kubectl
spec:
type: prometheus
targetServer: "<prometheus-url>"
secretKeyRef:
name: prometheus-secret
---
apiVersion: v1
kind: Secret
metadata:
name: prometheus-secret
data:
password: password
user: user
type: Opaque
Note Setting the
.spec.secretKeyRef.key
field inKeptnMetricsProvider
is not necessary, asuser
andpassword
key names are required to be present in the linked Secret. Setting this field won't have any effect.
An example of Datadog as a metrics provider with a Secret holding the authentication data looks like the following:
apiVersion: metrics.keptn.sh/v1
kind: KeptnMetricsProvider
metadata:
name: datadog-provider
namespace: podtato-kubectl
spec:
type: datadog
targetServer: "<datadog-url>"
secretKeyRef:
name: datadog-secret
---
apiVersion: v1
kind: Secret
metadata:
name: datadog-secret
data:
DD_CLIENT_API_KEY: api-key
DD_CLIENT_APP_KEY: app-key
type: Opaque
Note Setting the
.spec.secretKeyRef.key
field inKeptnMetricsProvider
is not necessary, asDD_CLIENT_API_KEY
andDD_CLIENT_API_KEY
key names must be present in the linked Secret. Setting this field has no effect.
An example of Dynatrace as a metrics provider with a Secret holding the authentication data looks like the following:
apiVersion: metrics.keptn.sh/v1
kind: KeptnMetricsProvider
metadata:
name: dynatrace-provider
namespace: podtato-kubectl
spec:
type: dynatrace | dql
targetServer: "<dynatrace-tenant-url>"
secretKeyRef:
name: dt-api-token
key: myCustomTokenKey
---
apiVersion: v1
kind: Secret
metadata:
name: dt-api-token
data:
myCustomTokenKey: my-token
type: Opaque
Note When using Dynatrace as metrics provider you can define the key name of your DT token stored in a secret, which is not possible for Datadog, Prometheus, Cortex or Thanos. For this example
myCustomTokenKey
was used.
Files
API Reference:
Differences between versions
For the v1alpha2
API version,
Keptn did not support
using more than one instance of a particular data provider
in the same namespace.
In other words, one namespace could support one instance each
of Prometheus, Dynatrace, and Datadog
but could not support, for example, two instances of Prometheus.
The synopsis in those older API versions
only specified the metadata.name
field
that identified the data provider (prometheus
, dynatrace
, or dql
):
apiVersion: metrics.keptn.sh/v1alpha2
kind: KeptnMetricsProvider
metadata:
name: prometheus | dynatrace |dql
namespace: <namespace>
spec:
targetServer: "<data-provider-url>"
secretKeyRef:
name: dt-api-token
key: DT_TOKEN
Also note that, for the v1alpha1 and v1alpha2 API versions,
KeptnMetricsProvider
only specifies the provider
for the KeptnMetric
resource.
Beginning with v1alpha3
API version,
KeptnMetricsProvider
is also used to specify the provider
for the KeptnEvaluationDefinition resource.