npm package: @rio-cloud/cdk-v2-constructs
Description: CDK constructs to build RIO flavored CI/CD pipeline in AWS.
Author: TB Digital Services GmbH
Latest version: 8.0.0

# RIO CDK Constructs

This package contains CDK2 constructs for RIO teams.

> NPM: `@rio-cloud/cdk-v2-constructs`

## Bootstrapping of CDK project

```
$ npx cdk init --language typescript
```

## Installation

```
$ npm install --save @rio-cloud/cdk-v2-constructs
```

## See also

 * [How to contribute](./docs/contribution.md)
 * [Changelog](./docs/changelog.md)
 * [brief API description](./docs/API.md)

## Internal documentation for library devs
[Documentation](./docs/developers-readme.md)

## Constructs overview (Under construction...)

### Watchful

Watchful constructs help generate some default monitors based on the resources defined in your stack. E.g. - If your stack contains a lambda function, and you configure watchful construct, then it will create out of box metric monitors for Throttling, Lambda error and Log error monitors. The ever-growing list of resources that watchful creates monitors for as of today are:

- Application load balancer
- Cloudfront
- Documentdb
- Dynamodb
- Fargate
- Lambda
- RDS

Simply add the following to your CDK stack to get started.
```
  import * as rio from '@rio-cloud/cdk-v2-constructs';
    ...
    const dw = new rio.watchfulv2.Watchful(this, 'Watchful', {
      serviceName,
    });
    dw.watchScope(this); // Generates alarms for all supported resources
    ...
```

There are options to override some defaults too. Please be aware that the library is very opinionated and is written with the most general use cases in mind. It is necessary to keep the use of the library simple enough, which means that there is only limited flexibility regarding the configuration options. Having said that, feel free to reach out to team CLAID over slack #rio-platform-support in case of feature requests.

The broad classification of the monitors created by watchful are
- Log error monitors
- Metrics Query monitors: Basically everything other than log error monitors

For Metrics query monitors, you can configure the priority (defaults as 3). For log error monitors, you can configure priority, renotification interval and can configure if the auto close of the monitor is disabled.
```
    ...
    const dw = new Watchful(stack, 'Watchful2', { 
      logErrorMonitorConfig: {
        disableAutoClose: true, 
        renotifyInterval: 150,
        priority: 4,
      },
      queryErrorMonitorConfig: {
        priority: 4
      }
    });
    dw.watchScope(stack);
```

There is an `overrideAlarmThreshold` method which can be used to override the default watchful thresholds. Please make sure to use the method before the `watchscope` function.
E.g. -
```
...
const dw = new Watchful(stack, 'Watchful', {});
dw.overrideAlarmThreshold({
  monitoredResourceScope: lambdaA,
  monitorType: MonitorType.ERRORS,
  threshold: 5,
});
dw.watchScope(stack);
```

### ClassifyPipelineType

The pipelines can be tagged with key 'pipeline_type' to the following values:

* deploy: To tag the production pipeline releasing the application
* branch: The branch pipeline. Mostly used to test contributions / renovate updates
* vulnerability: The vulnerability pipeline

The construct `ClassifyPipelineType` can be used to tag the pipeline accordingly. This tag is also picked up by the Datadog pipeline metric used to monitor the pipelines. It is added as a tag to the metric. This gives you more flexibility with managing the monitors also. E.g. some teams don't want to get alerted for branch pipelines. You can then leverage this metric tag to filter the pipelines.

Example:

```typescript
const pipeline = new pipelines.CodePipeline(this, 'Pipeline', {
      ...
    });
rio.ClassifyPipelineType.apply(pipeline, rio.RioPipelineType.DEPLOY);
```