Hermann  Frami

Hermann Frami

1654440960

Serverless Plugin Git Variables

serverless-plugin-git-variables 

Expose git variables (HEAD description, branch name, short commit hash, message, git tags, and if the local repo has changed files) to your serverless services. Moreover, it adds GIT related environment variables and tags (GIT_COMMIT_SHORT, GIT_COMMIT_LONG, GIT_BRANCH, GIT_IS_DIRTY, GIT_REPOSITORY, GIT_TAGS) for each defined function in the serverless file. You can disable this by adding the following custom variable in your serverless.yml file:

custom:
  exportGitVariables: false

If you only want to add a specific subset of variables/tags, you can define a whitelist:

custom:
  gitVariablesEnvWhitelist: ['GIT_COMMIT_SHORT', 'GIT_TAGS']
  gitVariablesTagsWhitelist: ['GIT_REPOSITORY', 'GIT_COMMIT_LONG']

If you have multiple git tags, you'll run into issues when adding them as AWS tags, so you'll need to exclude them from the whitelist.

Usage


custom:
  gitDescription: ${git:repository} - ${git:branch} - ${git:tags}

functions:
  processEventBatch:
    name: ${self:provider.stage}-${self:service}-process-event-batch
    description: ${self:custom.gitDescription}

  processEventBatch2:
    name: ${self:provider.stage}-${self:service}-process-event-batch-2
    description: ${self:custom.gitDescription}

plugins:
  - serverless-plugin-git-variables

resources:
  Description: >
    ${self:service} ${git:branch}:${git:sha1}
    https://github.com/jacob-meacham/serverless-plugin-git-variables
    ${git:message}

Available variables

  • git:repository - name of the git repository
  • git:sha1 - hash of the current commit
  • git:branch - name of the current branch
  • git:isDirty - true if the workspace is currently dirty
  • git:describe / git:describeLight - see below
  • git:user - The user's name
  • git:email - The user's email
  • git:tags - The tag pointing to the current commit
  • git:message - Full git commit message
  • git:messageSubject - Only the suject of the message, as git log -1 --pretty=%s
  • git:messageBody - Only the body of the message, as git log -1 --pretty=%b

describe and describeLight

The describe (${git:describe}) and the describeLight (${git:describeLight}) variables are both used to return the most recent tag of the repo. However the difference is that whilst describe evaluates to git describe --always, the describeLight variable evaluates to git describe --always --tags. --always will ensure that if no tags are present, the commit hash is shown as a fallback option. (See git describe documentation for more information).

Annotated tags are shown by both describe and describeLight, only describeLight will show lightweight tags (such as those generated when using GitHub's releases feature).

For more information on annotated and lightweight tags go to the git documentation on tagging.

tags

The tags (${git:tags}) is used to get info about which git tags (separated by ::) are pointing to current commit and if none it will show commit ID as fallback.

Version History

  • 5.2.0
    • Support for Serverless v2/v3. Switch to github actions
  • 5.1.0
    • Add messageSubject/messageBody (Thanks @vhenzl)
  • 5.0.1
    • Fix module export (Thanks @nason)
  • 5.0.0
    • Rely on a more modern version of Node, which allows removal of runtime dependencies
  • 4.1.0
    • Fix sporadic failure with git write-tree (Thanks to @navrkald and @james-hu)
  • 4.0.0
    • Change tags separator from ',' to '::' to conform to the AWS tag regex
  • 3.5.0
    • Add ability to specify whitelist of variables to set on the environment or in tags
  • 3.4.0
    • Add user name / email (Thanks to @JordanReiter)
    • Add git tag information (Thanks to @navrkald)
  • 3.3.3
    • Update dependencies thanks to dependabot
  • 3.3.2
    • Fixed issue with sporadic command failures (Thanks to @iamakulov)
  • 3.3.1
    • Changed approach for finding repository name, to fix plugin on Windows
  • 3.3.0
    • Added repository name (Thanks to @iDVB)
  • 3.2.0
    • Added a describeLight git variable, which allows use of lightweight tags (Thanks to @domroutley)
  • 3.1.1
    • Fix issue that occurs if a function has no environment specified (Thanks to @arnaudh-nutonomy)
  • 3.1.0
    • Plugin now also adds environment variables that are accessible at runtime (Thanks to @chechu)
  • 3.0.0
    • Add support for long commit hash (Thanks to @e-e-e)
    • backwards incompatible change: git describe now uses --always, so if there are not tags it returns a hash instead of failing (Thanks to @e-e-e)
  • 2.1.1
    • Fix packaging issue
  • 2.1.0
    • Add support for git message (Thanks to @campadrenalin)
  • 2.0.0
    • support Serverless >= 1.16.0
  • 1.0.1
    • list babel-runtime as a dependency
  • 1.0.0
    • Initial release

Author: jacob-meacham
Source Code: https://github.com/jacob-meacham/serverless-plugin-git-variables 
License: MIT license

#serverless #git #plugin #aws 

What is GEEK

Buddha Community

Serverless Plugin Git Variables
Hermann  Frami

Hermann Frami

1654440960

Serverless Plugin Git Variables

serverless-plugin-git-variables 

Expose git variables (HEAD description, branch name, short commit hash, message, git tags, and if the local repo has changed files) to your serverless services. Moreover, it adds GIT related environment variables and tags (GIT_COMMIT_SHORT, GIT_COMMIT_LONG, GIT_BRANCH, GIT_IS_DIRTY, GIT_REPOSITORY, GIT_TAGS) for each defined function in the serverless file. You can disable this by adding the following custom variable in your serverless.yml file:

custom:
  exportGitVariables: false

If you only want to add a specific subset of variables/tags, you can define a whitelist:

custom:
  gitVariablesEnvWhitelist: ['GIT_COMMIT_SHORT', 'GIT_TAGS']
  gitVariablesTagsWhitelist: ['GIT_REPOSITORY', 'GIT_COMMIT_LONG']

If you have multiple git tags, you'll run into issues when adding them as AWS tags, so you'll need to exclude them from the whitelist.

Usage


custom:
  gitDescription: ${git:repository} - ${git:branch} - ${git:tags}

functions:
  processEventBatch:
    name: ${self:provider.stage}-${self:service}-process-event-batch
    description: ${self:custom.gitDescription}

  processEventBatch2:
    name: ${self:provider.stage}-${self:service}-process-event-batch-2
    description: ${self:custom.gitDescription}

plugins:
  - serverless-plugin-git-variables

resources:
  Description: >
    ${self:service} ${git:branch}:${git:sha1}
    https://github.com/jacob-meacham/serverless-plugin-git-variables
    ${git:message}

Available variables

  • git:repository - name of the git repository
  • git:sha1 - hash of the current commit
  • git:branch - name of the current branch
  • git:isDirty - true if the workspace is currently dirty
  • git:describe / git:describeLight - see below
  • git:user - The user's name
  • git:email - The user's email
  • git:tags - The tag pointing to the current commit
  • git:message - Full git commit message
  • git:messageSubject - Only the suject of the message, as git log -1 --pretty=%s
  • git:messageBody - Only the body of the message, as git log -1 --pretty=%b

describe and describeLight

The describe (${git:describe}) and the describeLight (${git:describeLight}) variables are both used to return the most recent tag of the repo. However the difference is that whilst describe evaluates to git describe --always, the describeLight variable evaluates to git describe --always --tags. --always will ensure that if no tags are present, the commit hash is shown as a fallback option. (See git describe documentation for more information).

Annotated tags are shown by both describe and describeLight, only describeLight will show lightweight tags (such as those generated when using GitHub's releases feature).

For more information on annotated and lightweight tags go to the git documentation on tagging.

tags

The tags (${git:tags}) is used to get info about which git tags (separated by ::) are pointing to current commit and if none it will show commit ID as fallback.

Version History

  • 5.2.0
    • Support for Serverless v2/v3. Switch to github actions
  • 5.1.0
    • Add messageSubject/messageBody (Thanks @vhenzl)
  • 5.0.1
    • Fix module export (Thanks @nason)
  • 5.0.0
    • Rely on a more modern version of Node, which allows removal of runtime dependencies
  • 4.1.0
    • Fix sporadic failure with git write-tree (Thanks to @navrkald and @james-hu)
  • 4.0.0
    • Change tags separator from ',' to '::' to conform to the AWS tag regex
  • 3.5.0
    • Add ability to specify whitelist of variables to set on the environment or in tags
  • 3.4.0
    • Add user name / email (Thanks to @JordanReiter)
    • Add git tag information (Thanks to @navrkald)
  • 3.3.3
    • Update dependencies thanks to dependabot
  • 3.3.2
    • Fixed issue with sporadic command failures (Thanks to @iamakulov)
  • 3.3.1
    • Changed approach for finding repository name, to fix plugin on Windows
  • 3.3.0
    • Added repository name (Thanks to @iDVB)
  • 3.2.0
    • Added a describeLight git variable, which allows use of lightweight tags (Thanks to @domroutley)
  • 3.1.1
    • Fix issue that occurs if a function has no environment specified (Thanks to @arnaudh-nutonomy)
  • 3.1.0
    • Plugin now also adds environment variables that are accessible at runtime (Thanks to @chechu)
  • 3.0.0
    • Add support for long commit hash (Thanks to @e-e-e)
    • backwards incompatible change: git describe now uses --always, so if there are not tags it returns a hash instead of failing (Thanks to @e-e-e)
  • 2.1.1
    • Fix packaging issue
  • 2.1.0
    • Add support for git message (Thanks to @campadrenalin)
  • 2.0.0
    • support Serverless >= 1.16.0
  • 1.0.1
    • list babel-runtime as a dependency
  • 1.0.0
    • Initial release

Author: jacob-meacham
Source Code: https://github.com/jacob-meacham/serverless-plugin-git-variables 
License: MIT license

#serverless #git #plugin #aws 

Hermann  Frami

Hermann Frami

1655426640

Serverless Plugin for Microservice Code Management and Deployment

Serverless M

Serverless M (or Serverless Modular) is a plugin for the serverless framework. This plugins helps you in managing multiple serverless projects with a single serverless.yml file. This plugin gives you a super charged CLI options that you can use to create new features, build them in a single file and deploy them all in parallel

splash.gif

Currently this plugin is tested for the below stack only

  • AWS
  • NodeJS λ
  • Rest API (You can use other events as well)

Prerequisites

Make sure you have the serverless CLI installed

# Install serverless globally
$ npm install serverless -g

Getting Started

To start the serverless modular project locally you can either start with es5 or es6 templates or add it as a plugin

ES6 Template install

# Step 1. Download the template
$ sls create --template-url https://github.com/aa2kb/serverless-modular/tree/master/template/modular-es6 --path myModularService

# Step 2. Change directory
$ cd myModularService

# Step 3. Create a package.json file
$ npm init

# Step 3. Install dependencies
$ npm i serverless-modular serverless-webpack webpack --save-dev

ES5 Template install

# Step 1. Download the template
$ sls create --template-url https://github.com/aa2kb/serverless-modular/tree/master/template/modular-es5 --path myModularService

# Step 2. Change directory
$ cd myModularService

# Step 3. Create a package.json file
$ npm init

# Step 3. Install dependencies
$ npm i serverless-modular --save-dev

If you dont want to use the templates above you can just add in your existing project

Adding it as plugin

plugins:
  - serverless-modular

Now you are all done to start building your serverless modular functions

API Reference

The serverless CLI can be accessed by

# Serverless Modular CLI
$ serverless modular

# shorthand
$ sls m

Serverless Modular CLI is based on 4 main commands

  • sls m init
  • sls m feature
  • sls m function
  • sls m build
  • sls m deploy

init command

sls m init

The serverless init command helps in creating a basic .gitignore that is useful for serverless modular.

The basic .gitignore for serverless modular looks like this

#node_modules
node_modules

#sm main functions
sm.functions.yml

#serverless file generated by build
src/**/serverless.yml

#main serverless directories generated for sls deploy
.serverless

#feature serverless directories generated sls deploy
src/**/.serverless

#serverless logs file generated for main sls deploy
.sm.log

#serverless logs file generated for feature sls deploy
src/**/.sm.log

#Webpack config copied in each feature
src/**/webpack.config.js

feature command

The feature command helps in building new features for your project

options (feature Command)

This command comes with three options

--name: Specify the name you want for your feature

--remove: set value to true if you want to remove the feature

--basePath: Specify the basepath you want for your feature, this base path should be unique for all features. helps in running offline with offline plugin and for API Gateway

optionsshortcutrequiredvaluesdefault value
--name-nstringN/A
--remove-rtrue, falsefalse
--basePath-pstringsame as name

Examples (feature Command)

Creating a basic feature

# Creating a jedi feature
$ sls m feature -n jedi

Creating a feature with different base path

# A feature with different base path
$ sls m feature -n jedi -p tatooine

Deleting a feature

# Anakin is going to delete the jedi feature
$ sls m feature -n jedi -r true

function command

The function command helps in adding new function to a feature

options (function Command)

This command comes with four options

--name: Specify the name you want for your function

--feature: Specify the name of the existing feature

--path: Specify the path for HTTP endpoint helps in running offline with offline plugin and for API Gateway

--method: Specify the path for HTTP method helps in running offline with offline plugin and for API Gateway

optionsshortcutrequiredvaluesdefault value
--name-nstringN/A
--feature-fstringN/A
--path-pstringsame as name
--method-mstring'GET'

Examples (function Command)

Creating a basic function

# Creating a cloak function for jedi feature
$ sls m function -n cloak -f jedi

Creating a basic function with different path and method

# Creating a cloak function for jedi feature with custom path and HTTP method
$ sls m function -n cloak -f jedi -p powers -m POST

build command

The build command helps in building the project for local or global scope

options (build Command)

This command comes with four options

--scope: Specify the scope of the build, use this with "--feature" tag

--feature: Specify the name of the existing feature you want to build

optionsshortcutrequiredvaluesdefault value
--scope-sstringlocal
--feature-fstringN/A

Saving build Config in serverless.yml

You can also save config in serverless.yml file

custom:
  smConfig:
    build:
      scope: local

Examples (build Command)

all feature build (local scope)

# Building all local features
$ sls m build

Single feature build (local scope)

# Building a single feature
$ sls m build -f jedi -s local

All features build global scope

# Building all features with global scope
$ sls m build -s global

deploy command

The deploy command helps in deploying serverless projects to AWS (it uses sls deploy command)

options (deploy Command)

This command comes with four options

--sm-parallel: Specify if you want to deploy parallel (will only run in parallel when doing multiple deployments)

--sm-scope: Specify if you want to deploy local features or global

--sm-features: Specify the local features you want to deploy (comma separated if multiple)

optionsshortcutrequiredvaluesdefault value
--sm-paralleltrue, falsetrue
--sm-scopelocal, globallocal
--sm-featuresstringN/A
--sm-ignore-buildstringfalse

Saving deploy Config in serverless.yml

You can also save config in serverless.yml file

custom:
  smConfig:
    deploy:
      scope: local
      parallel: true
      ignoreBuild: true

Examples (deploy Command)

Deploy all features locally

# deploy all local features
$ sls m deploy

Deploy all features globally

# deploy all global features
$ sls m deploy --sm-scope global

Deploy single feature

# deploy all global features
$ sls m deploy --sm-features jedi

Deploy Multiple features

# deploy all global features
$ sls m deploy --sm-features jedi,sith,dark_side

Deploy Multiple features in sequence

# deploy all global features
$ sls m deploy  --sm-features jedi,sith,dark_side --sm-parallel false

Author: aa2kb
Source Code: https://github.com/aa2kb/serverless-modular 
License: MIT license

#serverless #aws #node #lambda 

Madyson  Reilly

Madyson Reilly

1604109000

Best Practices for Using Git

Git has become ubiquitous as the preferred version control system (VCS) used by developers. Using Git adds immense value especially for engineering teams where several developers work together since it becomes critical to have a system of integrating everyone’s code reliably.

But with every powerful tool, especially one that involves collaboration with others, it is better to establish conventions to follow lest we shoot ourselves in the foot.

At DeepSource, we’ve put together some guiding principles for our own team that make working with a VCS like Git easier. Here are 5 simple rules you can follow:

1. Make Clean, Single-Purpose Commits

Oftentimes programmers working on something get sidetracked into doing too many things when working on one particular thing — like when you are trying to fix one particular bug and you spot another one, and you can’t resist the urge to fix that as well. And another one. Soon, it snowballs and you end up with so many changes all going together in one commit.

This is problematic, and it is better to keep commits as small and focused as possible for many reasons, including:

  • It makes it easier for other people in the team to look at your change, making code reviews more efficient.
  • If the commit has to be rolled back completely, it’s far easier to do so.
  • It’s straightforward to track these changes with your ticketing system.

Additionally, it helps you mentally parse changes you’ve made using git log.

#open source #git #git basics #git tools #git best practices #git tutorials #git commit

7 Best Practices in GIT for Your Code Quality

There is no doubt that Git plays a significant role in software development. It allows developers to work on the same code base at the same time. Still, developers struggle for code quality. Why? They fail to follow git best practices. In this post, I will explain seven core best practices of Git and a Bonus Section.

1. Atomic Commit

Committing something to Git means that you have changed your code and want to save these changes as a new trusted version.

Version control systems will not limit you in how you commit your code.

  • You can commit 1000 changes in one single commit.
  • Commit all the dll and other dependencies
  • Or you can check in broken code to your repository.

But is it good? Not quite.

Because you are compromising code quality, and it will take more time to review codeSo overall, team productivity will be reduced. The best practice is to make an atomic commit.

When you do an atomic commit, you’re committing only one change. It might be across multiple files, but it’s one single change.

2. Clarity About What You Can (& Can’t) Commit

Many developers make some changes, then commit, then push. And I have seen many repositories with unwanted files like dll, pdf, etc.

You can ask two questions to yourself, before check-in your code into the repository

  1. Are you suppose to check-in all these files?
  2. Are they part of your source code?

You can simply use the .gitignore file to avoid unwanted files in the repository. If you are working on more then one repo, it’s easy to use a global .gitignore file (without adding or pushing). And .gitignore file adds clarity and helps you to keep your code clean. What you can commit, and it will automatically ignore the unwanted files like autogenerated files like .dll and .class, etc.

#git basics #git command #git ignore #git best practices #git tutorial for beginners #git tutorials

Hermann  Frami

Hermann Frami

1653578100

Serverless Plugin Datadog

Datadog recommends the Serverless Framework Plugin for developers using the Serverless Framework to deploy their serverless applications. The plugin automatically enables instrumentation for applications to collect metrics, traces, and logs by:

  • Installing the Datadog Lambda library to your Lambda functions as a Lambda layer.
  • Installing the Datadog Lambda Extension to your Lambda functions as a Lambda layer (addExtension) or subscribing the Datadog Forwarder to your Lambda functions' log groups (forwarderArn).
  • Making the required configuration changes, such as adding environment variables or additional tracing layers, to your Lambda functions.

Getting started

To quickly get started, follow the installation instructions for Python, Node.js, Ruby, Java, Go, or .NET and view your function's enhanced metrics, traces, and logs in Datadog.

After installation is complete, configure the advanced options to suit your monitoring needs.

Upgrade

Each version of the plugin is published with a specific set of versions of the Datadog Lambda layers. To pick up new features and bug fixes provided by the latest versions of Datadog Lambda layers, upgrade the serverless framework plugin. Test the new version before applying it on your production applications.

Configuration parameters

To further configure your plugin, use the following custom parameters in your serverless.yml:

ParameterDescription
siteSet which Datadog site to send data to, such as datadoghq.com (default), datadoghq.eu, us3.datadoghq.com, us5.datadoghq.com, or ddog-gov.com. This parameter is required when collecting telemtry using the Datadog Lambda Extension.
apiKey[Datadog API key][7]. This parameter is required when collecting telemetry using the Datadog Lambda Extension. Alternatively, you can also set the DATADOG_API_KEY environment variable in your deployment environment.
appKeyDatadog app key. Only needed when the monitors field is defined. Alternatively, you can also set the DATADOG_APP_KEY environment variable in your deployment environment.
apiKeySecretArnAn alternative to using the apiKey field. The ARN of the secret that is storing the Datadog API key in AWS Secrets Manager. Remember to add the secretsmanager:GetSecretValue permission to the Lambda execution role.
apiKMSKeyAn alternative to using the apiKey field. Datadog API key encrypted using KMS. Remember to add the kms:Decrypt permission to the Lambda execution role.
envWhen set along with addExtension, a DD_ENV environment variable is added to all Lambda functions with the provided value. Otherwise, an env tag is added to all Lambda functions with the provided value. Defaults to the stage value of the serverless deployment.
serviceWhen set along with addExtension, a DD_SERVICE environment variable is added to all Lambda functions with the provided value. Otherwise, a service tag is added to all Lambda functions with the provided value. Defaults to the service value of the serverless project.
versionWhen set along with addExtension, a DD_VERSION environment variable is added to all Lambda functions with the provided value. When set along with forwarderArn, a version tag is added to all Lambda functions with the provided value.
tagsA comma separated list of key:value pairs as a single string. When set along with extensionLayerVersion, a DD_TAGS environment variable is added to all Lambda functions with the provided value. When set along with forwarderArn, the plugin parses the string and sets each key:value pair as a tag on all Lambda functions.
enableXrayTracingSet true to enable X-Ray tracing on the Lambda functions and API Gateway integrations. Defaults to false.
enableDDTracingEnable Datadog tracing on the Lambda function. Defaults to true.
enableDDLogsEnable Datadog log collection using the Lambda Extension. Defaults to true. Note: This setting has no effect on logs sent by the Datadog Forwarder.
monitorsWhen defined, the Datadog plugin configures monitors for the deployed function. Requires setting DATADOG_API_KEY and DATADOG_APP_KEY in your environment. To learn how to define monitors, see To Enable and Configure a Recommended Serverless Monitor.
captureLambdaPayload[Captures incoming and outgoing AWS Lambda payloads][17] in the Datadog APM spans for Lambda invocations. Defaults to false.
enableSourceCodeIntegrationEnable [Datadog source code integration][18] for the function. Defaults to true.
subscribeToApiGatewayLogsEnable automatic subscription of the Datadog Forwarder to API Gateway log groups. Requires setting forwarderArn. Defaults to true.
subscribeToHttpApiLogsEnable automatic subscription of the Datadog Forwarder to HTTP API log groups. Requires setting forwarderArn. Defaults to true.
subscribeToWebsocketLogsEnable automatic subscription of the Datadog Forwarder to WebSocket log groups. Requires setting forwarderArn. Defaults to true.
forwarderArnThe ARN of the Datadog Forwarder to be subscribed to the Lambda or API Gateway log groups.
addLayersWhether to install the Datadog Lambda library as a layer. Defaults to true. Set to false when you plan to package the Datadog Lambda library to your function's deployment package on your own so that you can install a specific version of the Datadog Lambda library ([Python][8] or [Node.js][9]).
addExtensionWhether to install the Datadog Lambda Extension as a layer. Defaults to true. When enabled, it's required to set the apiKey and site.
excludeWhen set, this plugin ignores all specified functions. Use this parameter if you have any functions that should not include Datadog functionality. Defaults to [].
enabledWhen set to false, the Datadog plugin stays inactive. Defaults to true. You can control this option using an environment variable. For example, use enabled: ${strToBool(${env:DD_PLUGIN_ENABLED, true})} to activate/deactivate the plugin during deployment. Alternatively, you can also use the value passed in through --stage to control this option—see example.
customHandlerWhen set, the specified handler is set as the handler for all the functions.
failOnErrorWhen set, this plugin throws an error if any custom Datadog monitors fail to create or update. This occurs after deploy, but will cause the result of serverless deploy to return a nonzero exit code (to fail user CI). Defaults to false.
integrationTestingSet true when running integration tests. This bypasses the validation of the Forwarder ARN and the addition of Datadog Monitor output links. Defaults to false.
logLevelThe log level, set to DEBUG for extended logging.

To use any of these parameters, add a custom > datadog section to your serverless.yml similar to this example:

custom:
  datadog:
    apiKeySecretArn: "{Datadog_API_Key_Secret_ARN}"
    enableXrayTracing: false
    enableDDTracing: true
    enableDDLogs: true
    subscribeToAccessLogs: true
    forwarderArn: arn:aws:lambda:us-east-1:000000000000:function:datadog-forwarder
    exclude:
      - dd-excluded-function

Webpack

If you are using a bundler, such as webpack, see Serverless Tracing and Webpack.

TypeScript

You may encounter the error of missing type definitions. To resolve the error, add datadog-lambda-js and dd-trace to the devDependencies list of your project's package.json.

If you are using serverless-typescript, make sure that serverless-datadog is above the serverless-typescript entry in your serverless.yml. The plugin will automatically detect .ts files.

plugins:
  - serverless-plugin-datadog
  - serverless-typescript

Disable Plugin for Particular Environment

If you'd like to turn off the plugin based on the environment (passed via --stage), you can use something similar to the example below.

provider:
  stage: ${self:opt.stage, 'dev'}

custom:
  staged: ${self:custom.stageVars.${self:provider.stage}, {}}

  stageVars:
    dev:
      dd_enabled: false

  datadog:
    enabled: ${self:custom.staged.dd_enabled, true}

Serverless Monitors

There are seven recommended monitors with default values pre-configured.

MonitorMetricsThresholdServerless Monitor ID
High Error Rateaws.lambda.errors/aws.lambda.invocations>= 10%high_error_rate
Timeoutaws.lambda.duration.max/aws.lambda.timeout>= 1timeout
Out of Memoryaws.lambda.enhanced.out_of_memory> 0out_of_memory
High Iterator Ageaws.lambda.iterator_age.maximum>= 24 hrshigh_iterator_age
High Cold Start Rateaws.lambda.enhanced.invocations(cold_start:true)/
aws.lambda.enhanced.invocations
>= 20%high_cold_start_rate
High Throttlesaws.lambda.throttles/aws.lambda.invocations>= 20%high_throttles
Increased Costaws.lambda.enhanced.estimated_cost↑20%increased_cost

To Enable and Configure a Recommended Serverless Monitor

To create a recommended monitor, you must use its respective serverless monitor ID. Note that you must also set the DATADOG_API_KEY and DATADOG_APP_KEY in your environment.

If you’d like to further configure the parameters for a recommended monitor, you can directly define the parameter values below the serverless monitor ID. Parameters not specified under a recommended monitor will use the default recommended value. The query parameter for recommended monitors cannot be directly modified and will default to using the query valued as defined above; however, you may change the threshold value in query by re-defining it within the options parameter. To delete a monitor, remove the monitor from the serverless.yml template. For further documentation on how to define monitor parameters, see the Datadog Monitors API.

Monitor creation occurs after the function is deployed. In the event that a monitor is unsuccessfully created, the function will still be successfully deployed.

To create a recommended monitor with the default values

Define the appropriate serverless monitor ID without specifying any parameter values

custom:
  datadog:
    addLayers: true
    monitors:
      - high_error_rate:

To configure a recommended monitor

custom:
  datadog:
    addLayers: true
    monitors:
      - high_error_rate:
          name: "High Error Rate with Modified Warning Threshold"
          message: "More than 10% of the function’s invocations were errors in the selected time range. Notify @data.dog@datadoghq.com @slack-serverless-monitors"
          tags: ["modified_error_rate", "serverless", "error_rate"]
          require_full_window: true
          priority: 2
          options:
            include_tags: true
            notify_audit: true
            thresholds:
              ok: 0.025
              warning: 0.05

To delete a monitor

Removing the serverless monitor ID and its parameters will delete the monitor.

To Enable and Configure a Custom Monitor

To define a custom monitor, you must define a unique serverless monitor ID string in addition to passing in the API key and Application key, DATADOG_API_KEY and DATADOG_APP_KEY, in your environment. The query parameter is required but every other parameter is optional. Define a unique serverless monitor ID string and specify the necessary parameters below. For further documentation on monitor parameters, see the Datadog Monitors API.

custom:
  datadog:
    addLayers: true
    monitors:
      - custom_monitor_id:
          name: "Custom Monitor"
          query: "max(next_1w):forecast(avg:system.load.1{*}, 'linear', 1, interval='60m', history='1w', model='default') >= 3"
          message: "Custom message for custom monitor. Notify @data.dog@datadoghq.com @slack-serverless-monitors"
          tags: ["custom_monitor", "serverless"]
          priority: 3
          options:
            enable_logs_sample: true
            require_full_window: true
            include_tags: false
            notify_audit: true
            notify_no_data: false
            thresholds:
              ok: 1
              warning: 2

Breaking Changes

v5.0.0

  • When used in conjunction with the Datadog Extension, this plugin sets service and env tags through environment variables instead of Lambda resource tags.
  • The enableTags parameter was replaced by the new service, env parameters.

v4.0.0

  • The Datadog Lambda Extension is now the default mechanism for transmitting telemetry to Datadog.

Opening Issues

If you encounter a bug with this package, let us know by filing an issue! Before opening a new issue, please search the existing issues to avoid duplicates.

When opening an issue, include your Serverless Framework version, Python/Node.js version, and stack trace if available. Also, please include the steps to reproduce when appropriate.

You can also open an issue for a feature request.

Contributing

If you find an issue with this package and have a fix, open a pull request following the procedures.

Community

For product feedback and questions, join the #serverless channel in the Datadog community on Slack.

Author: DataDog
Source Code: https://github.com/DataDog/serverless-plugin-datadog 
License: View license

#serverless #datadog #plugin