@rio-cloud/cdk-v2-constructs 6.0.1 → 6.2.1

package/.jsii

@@ -3671,7 +3671,7 @@
   },
   "name": "@rio-cloud/cdk-v2-constructs",
   "readme": {
-    "markdown": "# RIO CDK Constructs\n\nThis package contains CDK2 constructs for RIO teams.\n\n> NPM: `@rio-cloud/cdk-v2-constructs`\n\n## Bootstrapping of CDK project\n\n```\n$ npx cdk init --language typescript\n```\n\n## Installation\n\n```\n$ npm install --save @rio-cloud/cdk-v2-constructs\n```\n\n## See also\n\n * [How to contribute](./CONTRIBUTION.md)\n * [Changelog](./CHANGELOG.md)\n * [brief API description](./API.md)\n\n## Internal documentation for library devs\n[Documentation](./developers-readme.md)\n\n## Constructs overview (Under construction...)\n\n### Watchful\n\nWatchful constructs help generate some default monitors based on the resouces defined in your stack. Eg - 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:\n\n- Application load balancer\n- Cloudfront\n- Documentdb\n- Dynamodb\n- Fargate\n- Lambda\n- RDS\n\nSimply add the following to your CDK stack to get started.\n```\n  import * as rio from '@rio-cloud/cdk-v2-constructs';\n    ...\n    const dw = new rio.watchfulv2.Watchful(this, 'Watchful', {\n      serviceName,\n    });\n    dw.watchScope(this); // Generates alarms for all supported resources\n    ...\n```\n\nThere 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.\n\nThe broad classification of the monitors created by watchful are\n- Log error monitors\n- Metrics Query monitors: Basically everything other than log error monitors\n\nFor 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.\n```\n    ...\n    const dw = new Watchful(stack, 'Watchful2', {\n      logErrorMonitorConfig: {\n        disableAutoClose: true,\n        renotifyInterval: 150,\n        priority: 4,\n      },\n      queryErrorMonitorConfig: {\n        priority: 4\n      }\n    });\n    dw.watchScope(stack);\n```\n\nThere 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.\nEg -\n```\n...\nconst dw = new Watchful(stack, 'Watchful', {});\ndw.overrideAlarmThreshold({\n  monitoredResourceScope: lambdaA,\n  monitorType: MonitorType.ERRORS,\n  threshold: 5,\n});\ndw.watchScope(stack);\n```\n\n### ClassifyPipelineType\n\nThe pipelines can be tagged with key 'pipeline_type' to the following values:\n\n* deploy: To tag the production pipeline releasing the application\n* branch: The branch pipeline. Mostly used to test contributions / renovate updates\n* vulnerability: The vulnerability pipeline\n\nThe 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.\n\nExample:\n\n```typescript\nconst pipeline = new pipelines.CodePipeline(this, 'Pipeline', {\n      ...\n    });\nrio.ClassifyPipelineType.apply(pipeline, rio.RioPipelineType.DEPLOY);\n```\n"
+    "markdown": "# RIO CDK Constructs\n\nThis package contains CDK2 constructs for RIO teams.\n\n> NPM: `@rio-cloud/cdk-v2-constructs`\n\n## Bootstrapping of CDK project\n\n```\n$ npx cdk init --language typescript\n```\n\n## Installation\n\n```\n$ npm install --save @rio-cloud/cdk-v2-constructs\n```\n\n## See also\n\n * [How to contribute](./docs/contribution.md)\n * [Changelog](./docs/changelog.md)\n * [brief API description](./docs/API.md)\n\n## Internal documentation for library devs\n[Documentation](./docs/developers-readme.md)\n\n## Constructs overview (Under construction...)\n\n### Watchful\n\nWatchful 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:\n\n- Application load balancer\n- Cloudfront\n- Documentdb\n- Dynamodb\n- Fargate\n- Lambda\n- RDS\n\nSimply add the following to your CDK stack to get started.\n```\n  import * as rio from '@rio-cloud/cdk-v2-constructs';\n    ...\n    const dw = new rio.watchfulv2.Watchful(this, 'Watchful', {\n      serviceName,\n    });\n    dw.watchScope(this); // Generates alarms for all supported resources\n    ...\n```\n\nThere 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.\n\nThe broad classification of the monitors created by watchful are\n- Log error monitors\n- Metrics Query monitors: Basically everything other than log error monitors\n\nFor 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.\n```\n    ...\n    const dw = new Watchful(stack, 'Watchful2', {\n      logErrorMonitorConfig: {\n        disableAutoClose: true,\n        renotifyInterval: 150,\n        priority: 4,\n      },\n      queryErrorMonitorConfig: {\n        priority: 4\n      }\n    });\n    dw.watchScope(stack);\n```\n\nThere 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.\nE.g. -\n```\n...\nconst dw = new Watchful(stack, 'Watchful', {});\ndw.overrideAlarmThreshold({\n  monitoredResourceScope: lambdaA,\n  monitorType: MonitorType.ERRORS,\n  threshold: 5,\n});\ndw.watchScope(stack);\n```\n\n### ClassifyPipelineType\n\nThe pipelines can be tagged with key 'pipeline_type' to the following values:\n\n* deploy: To tag the production pipeline releasing the application\n* branch: The branch pipeline. Mostly used to test contributions / renovate updates\n* vulnerability: The vulnerability pipeline\n\nThe 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.\n\nExample:\n\n```typescript\nconst pipeline = new pipelines.CodePipeline(this, 'Pipeline', {\n      ...\n    });\nrio.ClassifyPipelineType.apply(pipeline, rio.RioPipelineType.DEPLOY);\n```\n"
   },
   "repository": {
     "type": "git",
@@ -6554,7 +6554,7 @@
         },
         "locationInModule": {
           "filename": "src/kafka/kafka-topic.ts",
-          "line": 229
+          "line": 237
         },
         "parameters": [
           {
@@ -6580,7 +6580,7 @@
       "kind": "class",
       "locationInModule": {
         "filename": "src/kafka/kafka-topic.ts",
-        "line": 227
+        "line": 235
       },
       "name": "KafkaTopic",
       "symbolId": "src/kafka/kafka-topic:KafkaTopic"
@@ -6919,7 +6919,7 @@
         },
         "locationInModule": {
           "filename": "src/kafka/kafka-topic.ts",
-          "line": 252
+          "line": 260
         },
         "parameters": [
           {
@@ -6945,7 +6945,7 @@
       "kind": "class",
       "locationInModule": {
         "filename": "src/kafka/kafka-topic.ts",
-        "line": 250
+        "line": 258
       },
       "name": "KafkaTopicV4",
       "symbolId": "src/kafka/kafka-topic:KafkaTopicV4"
@@ -7085,6 +7085,25 @@
             "fqn": "@rio-cloud/cdk-v2-constructs.kafka.LogCompactionProperties"
           }
         },
+        {
+          "abstract": true,
+          "docs": {
+            "default": "undefined",
+            "remarks": "It could just be enabled, if the topic is compacted and the RecoveryPolicy is 'recoverable'.",
+            "stability": "stable",
+            "summary": "Specify whether the topic should be backed up automatically or not."
+          },
+          "immutable": true,
+          "locationInModule": {
+            "filename": "src/kafka/kafka-topic.ts",
+            "line": 217
+          },
+          "name": "managedBackupEnabled",
+          "optional": true,
+          "type": {
+            "primitive": "boolean"
+          }
+        },
         {
           "abstract": true,
           "docs": {
@@ -15145,7 +15164,7 @@
         },
         "locationInModule": {
           "filename": "src/kafka/kafka-topic.ts",
-          "line": 229
+          "line": 237
         },
         "parameters": [
           {
@@ -15171,7 +15190,7 @@
       "kind": "class",
       "locationInModule": {
         "filename": "src/kafka/kafka-topic.ts",
-        "line": 227
+        "line": 235
       },
       "name": "KafkaTopic",
       "namespace": "kafka",
@@ -15514,7 +15533,7 @@
         },
         "locationInModule": {
           "filename": "src/kafka/kafka-topic.ts",
-          "line": 252
+          "line": 260
         },
         "parameters": [
           {
@@ -15540,7 +15559,7 @@
       "kind": "class",
       "locationInModule": {
         "filename": "src/kafka/kafka-topic.ts",
-        "line": 250
+        "line": 258
       },
       "name": "KafkaTopicV4",
       "namespace": "kafka",
@@ -15682,6 +15701,25 @@
             "fqn": "@rio-cloud/cdk-v2-constructs.kafka.LogCompactionProperties"
           }
         },
+        {
+          "abstract": true,
+          "docs": {
+            "default": "undefined",
+            "remarks": "It could just be enabled, if the topic is compacted and the RecoveryPolicy is 'recoverable'.",
+            "stability": "stable",
+            "summary": "Specify whether the topic should be backed up automatically or not."
+          },
+          "immutable": true,
+          "locationInModule": {
+            "filename": "src/kafka/kafka-topic.ts",
+            "line": 217
+          },
+          "name": "managedBackupEnabled",
+          "optional": true,
+          "type": {
+            "primitive": "boolean"
+          }
+        },
         {
           "abstract": true,
           "docs": {
@@ -16271,5 +16309,5 @@
     }
   },
   "version": "0.0.0",
-  "fingerprint": "kTF6GygMDt60e/vn0s1VKYWl7IqZwwg6gseIISPj7qA="
+  "fingerprint": "vpDlySGr5n//8kkjLy5zFrJZUFzANznNblVJs8b3bl0="
 }