Skip to content
This repository has been archived by the owner on Jan 12, 2024. It is now read-only.

Commit

Permalink
Merge branch 'patch/refactor-documentation' of github.com:keptn-contr…
Browse files Browse the repository at this point in the history
…ib/dynatrace-service into patch/refactor-documentation

Signed-off-by: Arthur Pitman <[email protected]>

; Conflicts:
;	documentation/slis-via-files.md
  • Loading branch information
arthurpitman committed Dec 21, 2021
2 parents d1feaa9 + e86b7cc commit d4e5e40
Show file tree
Hide file tree
Showing 7 changed files with 15 additions and 15 deletions.
8 changes: 3 additions & 5 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,13 +12,13 @@

## Overview

The dynatrace-service allows you to integrate Dynatrace monitoring in your Keptn workflow. It provides the following capabilities:
The dynatrace-service allows you to integrate Dynatrace monitoring in your Keptn sequences. It provides the following capabilities:

- [**SLI-provider**](documentation/sli-provider.md): To support the evaluation of the quality gates, the dynatrace-service can be configured to retrieve SLIs for a Keptn project, stage or service.

- [**Forwarding deployment and test events from Keptn to Dynatrace**](documentation/event-forwarding-to-dynatrace.md): The dynatrace-service can forward events such as deployment or test start/stop events to Dynatrace along with attach rules to ensure that the correct monitored entities are associated with the event.
- [**Forwarding deployment and test events from Keptn to Dynatrace**](documentation/event-forwarding-to-dynatrace.md): The dynatrace-service can forward events such as deployment or test start/stop events to Dynatrace using attach rules to ensure that the correct monitored entities are associated with the event.

- [**Forwarding problem notifications from Dynatrace to Keptn**](documentation/problem-forwarding-to-keptn.md): The dynatrace-service can support auto-remediation by forwarding problem notifications from Dynatrace to a Keptn environment and ensuring that the `sh.keptn.events.problem` event is mapped to the correct project, service and stage.
- [**Forwarding problem notifications from Dynatrace to Keptn**](documentation/problem-forwarding-to-keptn.md): The dynatrace-service can support triggering remediation sequences by forwarding problem notifications from Dynatrace to a Keptn environment and ensuring that the `sh.keptn.events.problem` event is mapped to the correct project, service and stage.

- [**Automatic onboarding of monitored service entities**](documentation/auto-service-onboarding.md): The dynatrace-service can be configured to periodically check for new service entities detected by Dynatrace and automatically import these into Keptn.

Expand Down Expand Up @@ -50,5 +50,3 @@ If you are planning to upgrade to dynatrace-service version `0.18.0` or newer fr
- [Upgrading the dynatrace-service](documentation/other-topics.md#upgrading-the-dynatrace-service)
- [Uninstalling the dynatrace-service](documentation/other-topics.md#uninstalling-the-dynatrace-service)
- [Developing the dynatrace-service](documentation/other-topics.md#developing-the-dynatrace-service)


2 changes: 1 addition & 1 deletion documentation/auto-tenant-configuration.md
Original file line number Diff line number Diff line change
Expand Up @@ -113,4 +113,4 @@ When `dynatraceService.config.generateDashboards` is set to `true`, the dynatrac

## Metric events

When `dynatraceService.config.generateMetricEvents` is set to `true`, the dynatrace-service tries to create custom alerts for each service on each stage in the project based on the associated SLIs and SLOs.
When `dynatraceService.config.generateMetricEvents` is set to `true`, the dynatrace-service tries to create custom alerts for each service on each stage in the project based on the associated SLIs and SLOs.
4 changes: 2 additions & 2 deletions documentation/feature-overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ The dynatrace-service supports the following use cases:

- [**Forwarding events from Keptn to Dynatrace**](event-forwarding-to-dynatrace.md): The dynatrace-service can forward events such as remediation, deployment, test start/stop, evaluation or release events to Dynatrace along with attach rules to ensure that the correct monitored entities are associated with the event.

- [**Forwarding problem notifications from Dynatrace to Keptn**](problem-forwarding-to-keptn.md): The dynatrace-service can support auto-remediation by forwarding problem notifications from Dynatrace to a Keptn environment and ensuring that the `sh.keptn.events.problem` event is mapped to the correct project, service and stage.
- [**Forwarding problem notifications from Dynatrace to Keptn**](problem-forwarding-to-keptn.md): The dynatrace-service can support triggering remediation sequences by forwarding problem notifications from Dynatrace to a Keptn environment and ensuring that the `sh.keptn.events.problem` event is mapped to the correct project, service and stage.

- [**Automatic onboarding of monitored service entities**](auto-service-onboarding.md): The dynatrace-service can be configured to periodically check for new service entities detected by Dynatrace and automatically import these into Keptn.

Expand All @@ -27,4 +27,4 @@ The dynatrace-service listens for the following events:
- `sh.keptn.event.release.finished`
- `sh.keptn.events.problem`
- `sh.keptn.event.monitoring.configure`
- `sh.keptn.event.project.create.finished`
- `sh.keptn.event.project.create.finished`
5 changes: 4 additions & 1 deletion documentation/project-setup.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
# Set up a Keptn project to use Dynatrace monitoring

To use the dynatrace-service in a new or existing Keptn project, create a Kubernetes secret for accessing a Dynatrace tenant, add a dynatrace-service configuration file (`dynatrace/dynatrace.conf.yaml`) to the project's Git repository, and execute `keptn configure monitoring` using the Keptn CLI.
Those steps are described in detail below.


## Prerequisite: Keptn project
Expand Down Expand Up @@ -64,13 +65,15 @@ After clicking **Add Secret** you should see an updated list of secrets includin

## 2. Create a dynatrace-service configuration file (`dynatrace/dynatrace.conf.yaml`)

To utilize the dynatrace-service with your Keptn project, add a configuration file (located at `dynatrace/dynatrace.conf.yaml`) to project's Git repository. At a minimum, this YAML file instructs the dynatrace-service about which Dynatrace credentials secret to use, but depending on the use-case, specifies how to retrieve SLIs, and optionally, which attach rules to add to a Dynatrace tenant. See [Configuring the dynatrace-service with `dynatrace/dynatrace.conf.yaml`](dynatrace-conf-yaml-file.md) for details. The [minimum configuration](assets/dynatrace.conf.yaml) is:
To utilize the dynatrace-service with your Keptn project, add a configuration file (located at `dynatrace/dynatrace.conf.yaml`) to project's Git repository. At a minimum, this YAML file instructs the dynatrace-service about which Dynatrace credentials secret to use, but depending on the use-case, specifies how to retrieve SLIs, and optionally, which attach rules to use for identifying the entity monitored by Dynatrace. See [Configuring the dynatrace-service with `dynatrace/dynatrace.conf.yaml`](dynatrace-conf-yaml-file.md) for details. The [minimum configuration](assets/dynatrace.conf.yaml) is:

```yaml
spec_version: '0.1.0'
dtCreds: dynatrace
```

In case you have access to the Git repository containing the configuration of your Keptn project, add the file in the master/main branch and execute a Git add, commit, and push.
If you do not have direct access to the Git repository (e.g. if you did not set an upstream yet), you can also use the [`keptn add resource` command](https://keptn.sh/docs/0.11.x/reference/cli/commands/keptn_add-resource/).

## 3. Configure Dynatrace as the monitoring provider

Expand Down
5 changes: 2 additions & 3 deletions documentation/sli-provider.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,12 +5,12 @@ The dynatrace-service can support the evaluation of the quality gates by retriev
- [SLIs via a combination of `dynatrace/sli.yaml` files located on the Keptn service, stage and project](slis-via-files.md), or
- [SLI and SLOs based on a Dynatrace dashboard](slis-via-dashboard.md).

The mode selected by the dynatrace-service depends on the value of the `dashboard` key in the `dynatrace/dynatrace.conf.yaml` used for a particular event as outlined in [Dashboard SLI-mode configuration (`dashboard`)`](dynatrace-conf-yaml-file.md#dashboard-sli-mode-configuration-dashboard)
The mode selected by the dynatrace-service depends on the value of the `dashboard` key in the `dynatrace/dynatrace.conf.yaml` used for a particular event as outlined in [Dashboard SLI-mode configuration (`dashboard`)](dynatrace-conf-yaml-file.md#dashboard-sli-mode-configuration-dashboard)


## SLI evaluation in auto-remediation workflows

As part of its auto-remediation workflow, Keptn also evaluates SLOs after executing the remediation action. By default, the auto-remediation workflow can be terminated if and only if the problem has been closed in Dynatrace.
As part of its auto-remediation sequence, Keptn also evaluates SLOs after executing the remediation action. By default, the auto-remediation workflow can be terminated if and only if the problem has been closed in Dynatrace.

To support this, the dynatrace-service will automatically query the status of the problem that originally triggered the workflow using Dynatrace's Problem API v2. It will then append an SLI `problem_open` with the value `0` (=problem no longer open) or `1` (=problem still open). Furthermore, a default key SLO is added with a pass criteria of `<=0` ensuring that the evaluation will only succeed if the problem is closed:

Expand All @@ -31,4 +31,3 @@ Alternatively, if you'd like to add a custom SLO definition, simply override the
## Known Limitations

- The Dynatrace Metrics API provides data with the "eventual consistency" approach. Therefore, the metrics data retrieved can be incomplete or even contain inconsistencies for timeframes within two hours of the current time. Usually, it takes a minute to catch up, but in extreme situations this might not be enough. The dynatrace-service tries to mitigate this issue by delaying SLI retrieval by up to 120 seconds in situations where the evaluation end time is close to the current time.

4 changes: 2 additions & 2 deletions documentation/slis-via-dashboard.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ The dynatrace-service can dynamically create SLIs and SLOs from a Dynatrace dash
- `query`: the dynatrace-service will use the first dashboard found with a name beginning with `KQG;project=<project>;service=<service>;stage=<stage>`, where `<project>`, `<service>` and `<stage>` are taken from the `sh.keptn.event.get-sli.triggered` event. To further customize the name, append any additional description as `;<custom-description>` after the stage.
- `<dashboard-uuid>`: set the `dashboard` property to the UUID of a specific dashboard to use it.

In response to a `sh.keptn.event.get-sli.triggered` event, the dynatrace-service will transform each supported tile into Dynatrace API queries. An SLI is created for each result together with a corresponding SLO. The SLOs are then stored in an `slo.yaml` file in the appropriate service and stage of the Keptn project, and values of the SLIs are queried and returned in the `sh.keptn.event.get-sli.finished` event.
In response to a `sh.keptn.event.get-sli.triggered` event, the dynatrace-service will transform each supported tile into Dynatrace API queries. An SLI is created for each result together with a corresponding SLO. The SLOs are then stored in an `slo.yaml` in the appropriate service and stage of the Keptn project, and values of the SLIs are queried and returned in the `sh.keptn.event.get-sli.finished` event.


## Defining SLIs and SLOs
Expand All @@ -18,7 +18,7 @@ The base name of the SLI as well as the properties of the SLO must be set by app
| `pass` | Add `<value>` as a pass criterion to the SLO | No | `pass=<200` |
| `warning` | Add `<value>` as a warning criterion to the SLO | No | `warning=<300` |
| `key` | Mark SLI as a key SLI | No | `key=true` |
| `weight` | Set the weight of the SLO to `<value>` | No | `weight=2.2` |
| `weight` | Set the weight of the SLO to `<value>` | No | `weight=2` |

Consult [the Keptn documentation](https://keptn.sh/docs/0.11.x/quality_gates/slo/#objectives) for more details on configuring objectives.

Expand Down
2 changes: 1 addition & 1 deletion documentation/slis-via-files.md
Original file line number Diff line number Diff line change
Expand Up @@ -159,4 +159,4 @@ The following example demonstrates how to specify that a metric's unit is micros
```yaml
indicators:
teststep_rt_Basic_Check: "MV2;MicroSecond;metricSelector=calc:service.teststepresponsetime:merge(\"dt.entity.service\"):avg:names:filter(eq(\"Test Step\",\"Basic Check\"))&entitySelector=type(SERVICE)"
```
```

0 comments on commit d4e5e40

Please sign in to comment.