This is a (Bug Report / Feature Proposal)

Description

For bug reports:

• What went wrong?
  When using the plugin to update the Evaluation Period it automatically set the Datapoints To Alarm equal to the value for the Evaluation Period.
• What did you expect should have happened?
  I would have expected the Datapoints To Alarm value to remain 1 unless otherwise specified.
• What was the config you used?
  In serverless.yml I had the functionErrors section with the following values:

functionErrors:
        period: 60
        evaluationPeriods: 5
        threshold: 1

• What stacktrace or error message from your provider did you see?
  There were no errors, however this change would never trigger any alarms with a DatapointsToAlarm value also equal to 5.

For feature proposals:

• What is the use case that should be solved. The more detail you describe this in the easier it is to understand for us.
  The value datapointsToAlarm needs to be added to the definition.js and index.js where the alarm is created.
• If there is additional config how would it look
  Tests and Readme would also need updates with the new alarm value.

Similar or dependent issues:

• N/A

Additional Data

• Serverless Framework Version: 1.26.1
• Stack Trace:
• Provider Error messages:

This is a new request to support the alerts for the SQS queue depth. We currently have SQS alerts that we currently configure separately. But, it will be great if we can utilize this plugin for all the alerts like SQS, DynamoDB etc..

Is it possible to support description? (I couldn't see it and setting it causes an error)

Thanks

This is a Bug Report

Description

Dashboard are created but they are using invalid metrics.

For bug reports:

• What went wrong?
  I added dashboards but the dashboards have the wrong metrics.

• What did you expect should have happened?
  The dashboards should be populated with the correct metrics, but no metrics are populated in any of the widgets.
  The actual metric detail is this
  Lambda•Invocations•FunctionName: my-function-name
  the expected metric detail is
  Lambda•Invocations•FunctionName: My-Function-Name•Resource:

For example

• What was the config you used?

alerts:
    dashboards: true

    topics:
      alarm: ${self:provider.environment.MARBOT_ALERT_ARN}
      insufficientData: ${self:provider.environment.MARBOT_ALERT_ARN}

    definitions:  # these defaults are merged with your definitions
      functionInvocations:
        period: 300 # override period
      functionDuration:
        statistic: Maximum
        threshold: 845

    alarms:
      - functionThrottles
      - functionErrors
      - functionInvocations
      - functionDuration```
* What stacktrace or error message from your provider did you see?
There was no error, so I do not see anything special in the log.

is to understand for us.
* If there is additional config how would it look

Similar or dependent issues:
* #12345

## Additional Data

* ***Serverless Framework Version***:
* ***Stack Trace***:
* ***Provider Error messages***:

This is a Feature Proposal

Description

CloudFormation now supports ExtendedStatistic. Would be great to have it in here http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cw-alarm.html#cfn-cloudwatch-alarms-extendedstatistic

Will avoid loading it when a different provider is used

This is a Bug Report

Description

I accidentally configured the plugin incorrectly and instead of failing gracefully, a cloudformation upload was attempted and failed spectacularly.

For bug reports:

• What went wrong?

• What did you expect should have happened?
  An error message saying the config was invalid should be printed

• What was the config you used?

+    alerts: {
+        alarms: [
+          'functionThrottles',
+          'functionErrors',
+          'functionInvocations',
+          'functionDuration',
+        ],
+        dashboards: true,
+        topics: '${self:custom.service}-${self:custom.stage}-alerts-alarm',
+   }

(note that topics should have alarm nested underneath but it doesn't.

• What stacktrace or error message from your provider did you see?
  Many AWS::SNS::Topic objects were attempted to be created, it looks like one per alarm if it were operating correctly. It then fails to create these topics saying they "already exist":

  Serverless Error ---------------------------------------

  An error occurred: AwsAlerts43 - r already exists in stack arn:aws:cloudformation:us-west-2:12345678910:stack/servicename-my-api-my-env/5c073420-d0c9-11e8-9030-0254f5c7f298.

Additional Data

• Serverless Framework Version:
  1.32.0
• Stack Trace:
• Provider Error messages:

Feature Proposal

Description

In case of listening to the sns topic and generating alerts to different medias.
there is no way of passing additional attribute on the alert object (beside the built-in ones)

for example :

alerts:
stages:
- live
topics:
alarm:
topic: bla-bla
definitions:
errorsAlarm:
namespace: 'AWS/Lambda'
metric: Errors
threshold: 1
statistic: Maximum
period: 300
evaluationPeriods: 1
comparisonOperator: GreaterThanOrEqualToThreshold
custom_attribute = "custom_data"

if it's impossible from aws reasons,
another idea will be to allow adding dimensions to the metric through the plugin :

alerts:
stages:
- live
topics:
alarm:
topic: bla-bla
definitions:
errorsAlarm:
namespace: 'AWS/Lambda'
metric: Errors
metric_dimenstions: {
custom_attribute : "custom_data"
}
threshold: 1
statistic: Maximum
period: 300
evaluationPeriods: 1
comparisonOperator: GreaterThanOrEqualToThreshold

This is a Feature Proposal

Description

Add an option to blacklist a function alarm for a given handler.

Use case

I want to add a function level alarm with a given config to all my defined lambdas except one.
So far as a I can tell, there's no way to remove an alarm defined in the global alerts.function section from each lambda, only override it's properties.

This arose from using https://github.com/FidelLimited/serverless-plugin-warmup which adds an additional lambda function and handler definition. When alerts.function is defined, the alarms then get added to this warmup lambda. We don't wish to track the duration of this lambda execution currently. I can easily see it applying to other lambdas though.

The current workaround would be to manually add the desired alarm to every lambda definition. In our case we currently have a deployment with 25 lambdas so this is a bit cumbersome.

This is a Bug Report

Description

https://github.com/serverless/serverless/releases/tag/v1.22.0 breaks the plugin and no SNS Topics or alarms are created.

# serverless.yml
service: test-alarms

provider:
  name: aws
  runtime: nodejs6.10
  region: us-west-2

custom:
  alerts:
    topics:
      alarm:
        topic: ${self:service}-${opt:stage}-alerts-alarm
    definitions:  # these defaults are merged with your definitions
      functionErrors:
        period: 300 # override period
    global:
      - functionErrors

plugins:
  - serverless-plugin-aws-alerts

functions:
  foo:
    handler: handler.hello

1.21

➜ SLS_DEBUG=true sls deploy --stage dev -v
Serverless: Invoke deploy
Serverless: Invoke package
Serverless: Invoke aws:common:validate
Serverless: Invoke aws:common:cleanupTempDir
Serverless: Packaging service...
Serverless: Excluding development dependencies...
Serverless: Invoke aws:package:finalize
Serverless: Invoke aws:common:moveArtifactsToPackage
Serverless: Invoke aws:common:validate
Serverless: Invoke aws:deploy:deploy
Serverless: Uploading CloudFormation file to S3...
Serverless: Uploading artifacts...
Serverless: Uploading service .zip file to S3 (739.23 KB)...
Serverless: Validating template...
Serverless: Creating Stack...
Serverless: Checking Stack create progress...
CloudFormation - CREATE_IN_PROGRESS - AWS::CloudFormation::Stack - test-alarms-dev
CloudFormation - CREATE_IN_PROGRESS - AWS::IAM::Role - IamRoleLambdaExecution
CloudFormation - CREATE_IN_PROGRESS - AWS::SNS::Topic - AwsAlertsAlarm
CloudFormation - CREATE_IN_PROGRESS - AWS::Logs::LogGroup - FooLogGroup
CloudFormation - CREATE_IN_PROGRESS - AWS::IAM::Role - IamRoleLambdaExecution
CloudFormation - CREATE_IN_PROGRESS - AWS::Logs::LogGroup - FooLogGroup
CloudFormation - CREATE_IN_PROGRESS - AWS::SNS::Topic - AwsAlertsAlarm
CloudFormation - CREATE_COMPLETE - AWS::Logs::LogGroup - FooLogGroup
CloudFormation - CREATE_COMPLETE - AWS::SNS::Topic - AwsAlertsAlarm
CloudFormation - CREATE_COMPLETE - AWS::IAM::Role - IamRoleLambdaExecution
CloudFormation - CREATE_IN_PROGRESS - AWS::Lambda::Function - FooLambdaFunction
CloudFormation - CREATE_IN_PROGRESS - AWS::Lambda::Function - FooLambdaFunction
CloudFormation - CREATE_COMPLETE - AWS::Lambda::Function - FooLambdaFunction
CloudFormation - CREATE_IN_PROGRESS - AWS::Lambda::Version - FooLambdaVersionihMEZjTgeDMZHIc7f7hOwofPmKWM8HB1QA1PqZEW0w
CloudFormation - CREATE_IN_PROGRESS - AWS::CloudWatch::Alarm - FooFunctionErrorsAlarm
CloudFormation - CREATE_IN_PROGRESS - AWS::Lambda::Version - FooLambdaVersionihMEZjTgeDMZHIc7f7hOwofPmKWM8HB1QA1PqZEW0w
CloudFormation - CREATE_COMPLETE - AWS::Lambda::Version - FooLambdaVersionihMEZjTgeDMZHIc7f7hOwofPmKWM8HB1QA1PqZEW0w
CloudFormation - CREATE_IN_PROGRESS - AWS::CloudWatch::Alarm - FooFunctionErrorsAlarm
CloudFormation - CREATE_COMPLETE - AWS::CloudWatch::Alarm - FooFunctionErrorsAlarm
CloudFormation - CREATE_COMPLETE - AWS::CloudFormation::Stack - test-alarms-dev
Serverless: Stack create finished...
Serverless: Invoke aws:info
Service Information
service: test-alarms
stage: dev
region: us-west-2
stack: test-alarms-dev
api keys:
  None
endpoints:
  None
functions:
  foo: test-alarms-dev-foo

Stack Outputs
FooLambdaFunctionQualifiedArn: arn:aws:lambda:us-west-2:***:function:test-alarms-dev-foo:7
ServerlessDeploymentBucketName: serverless-deployments-us-west-2-***

Serverless: Invoke aws:deploy:finalize

1.22

➜ SLS_DEBUG=true sls deploy --stage dev -v
Serverless: Load command run
Serverless: Load command config
Serverless: Load command config:credentials
Serverless: Load command create
Serverless: Load command install
Serverless: Load command package
Serverless: Load command deploy
Serverless: Load command deploy:function
Serverless: Load command deploy:list
Serverless: Load command deploy:list:functions
Serverless: Load command invoke
Serverless: Load command invoke:local
Serverless: Load command info
Serverless: Load command logs
Serverless: Load command login
Serverless: Load command logout
Serverless: Load command metrics
Serverless: Load command remove
Serverless: Load command rollback
Serverless: Load command rollback:function
Serverless: Load command slstats
Serverless: Load command plugin
Serverless: Load command plugin
Serverless: Load command plugin:install
Serverless: Load command plugin
Serverless: Load command plugin:uninstall
Serverless: Load command plugin
Serverless: Load command plugin:list
Serverless: Load command plugin
Serverless: Load command plugin:search
Serverless: Load command emit
Serverless: Load command config
Serverless: Load command config:credentials
Serverless: Load command rollback
Serverless: Load command rollback:function
Serverless: Invoke deploy
Serverless: Invoke package
Serverless: Invoke aws:common:validate
Serverless: Invoke aws:common:cleanupTempDir
Serverless: Packaging service...
Serverless: Excluding development dependencies...
Serverless: Invoke aws:package:finalize
Serverless: Invoke aws:common:moveArtifactsToPackage
Serverless: Invoke aws:common:validate
Serverless: Invoke aws:deploy:deploy
Serverless: Uploading CloudFormation file to S3...
Serverless: Uploading artifacts...
Serverless: Uploading service .zip file to S3 (739.23 KB)...
Serverless: Validating template...
Serverless: Creating Stack...
Serverless: Checking Stack create progress...
CloudFormation - CREATE_IN_PROGRESS - AWS::CloudFormation::Stack - test-alarms-dev
CloudFormation - CREATE_IN_PROGRESS - AWS::IAM::Role - IamRoleLambdaExecution
CloudFormation - CREATE_IN_PROGRESS - AWS::Logs::LogGroup - FooLogGroup
CloudFormation - CREATE_IN_PROGRESS - AWS::Logs::LogGroup - FooLogGroup
CloudFormation - CREATE_COMPLETE - AWS::Logs::LogGroup - FooLogGroup
CloudFormation - CREATE_IN_PROGRESS - AWS::IAM::Role - IamRoleLambdaExecution
CloudFormation - CREATE_COMPLETE - AWS::IAM::Role - IamRoleLambdaExecution
CloudFormation - CREATE_IN_PROGRESS - AWS::Lambda::Function - FooLambdaFunction
CloudFormation - CREATE_IN_PROGRESS - AWS::Lambda::Function - FooLambdaFunction
CloudFormation - CREATE_COMPLETE - AWS::Lambda::Function - FooLambdaFunction
CloudFormation - CREATE_IN_PROGRESS - AWS::Lambda::Version - FooLambdaVersion2sn0kDVxPENRDhQe3NNGZ5MYq8x9ZkRsOgxMd0UdiM
CloudFormation - CREATE_IN_PROGRESS - AWS::Lambda::Version - FooLambdaVersion2sn0kDVxPENRDhQe3NNGZ5MYq8x9ZkRsOgxMd0UdiM
CloudFormation - CREATE_COMPLETE - AWS::Lambda::Version - FooLambdaVersion2sn0kDVxPENRDhQe3NNGZ5MYq8x9ZkRsOgxMd0UdiM
CloudFormation - CREATE_COMPLETE - AWS::CloudFormation::Stack - test-alarms-dev
Serverless: Stack create finished...
Serverless: Invoke aws:info
Service Information
service: test-alarms
stage: dev
region: us-west-2
stack: test-alarms-dev
api keys:
  None
endpoints:
  None
functions:
  foo: test-alarms-dev-foo

Stack Outputs
FooLambdaFunctionQualifiedArn: arn:aws:lambda:us-west-2:***:function:test-alarms-dev-foo:8
ServerlessDeploymentBucketName: serverless-deployments-us-west-2-***

Serverless: Invoke aws:deploy:finalize

This is a Feature Proposal

Description

For feature proposals:

• What is the use case that should be solved. The more detail you describe this in the easier it is to understand for us.

Aside from using arn's, add support to import CloudFormation exports as alarm actions for easy reference.

• If there is additional config how would it look

custom:
  alerts:
    topics:
      alarm:
        topic:
          Fn::ImportValue: ServiceMonitoring:monitoring-${opt:stage, 'dev'}

Similar or dependent issues:

• #14 includes arn support

Additional Data

• Serverless Framework Version: 1.32.0
• Stack Trace: N/A
• Provider Error messages: N/A

This is a Bug Report

Description

For bug reports:

• What went wrong?

Email address is listed multiple times within the actions of the alarm in CloudWatch (i.e "Send message to topic "service-stage-alerts-alarm" ([email protected])" is listed 2+ times for "ALARM", "OK", and "INSUFFICENT DATA")

This seems to occur when the alarms are removed and then re-added or the service is removed and then re-deployed.

When I go to the SNS topic, it only shows one email address subscribed.

• What did you expect should have happened?

Email address should only appear once.

• What was the config you used?

custom:
  alerts:
    email: [email protected]
    topics:
      ok:
        topic: ${self:service}-${self:provider.stage}-alerts-ok
        notifications:
        - protocol: email
          endpoint: ${self:custom.alerts.email}
      alarm:
        topic: ${self:service}-${self:provider.stage}-alerts-alarm
        notifications:
        - protocol: email
          endpoint: ${self:custom.alerts.email}
      insufficientData:
        topic: ${self:service}-${self:provider.stage}-alerts-insufficientData
        notifications:
        - protocol: email
          endpoint: ${self:custom.alerts.email}

• What stacktrace or error message from your provider did you see?

None

Additional Data

• Serverless Framework Version: 1.32.0
• Stack Trace: None
• Provider Error messages: None

This is a (Bug Report / Feature Proposal)

This is a question

Description

Is it possible to use this module to write arbitrary alarms for other namespaces based on metrics amazon automatically stores i.e. for kinesis and dynamodb as long as the resource is defined in the serverless.yml file

For bug reports:

• What went wrong?
• What did you expect should have happened?
• What was the config you used?
• What stacktrace or error message from your provider did you see?

For feature proposals:

• What is the use case that should be solved. The more detail you describe this in the easier it is to understand for us.
• If there is additional config how would it look

Similar or dependent issues:

• #12345

Additional Data

• Serverless Framework Version:
• Stack Trace:
• Provider Error messages:

This is a Bug Report

Description

For bug reports:

• What went wrong?

if you want a notification to call a lambda, the topic doesn't have permission to invoke it

• What did you expect should have happened?

Topic should be able to invoke the lambda defined in notification

• What was the config you used?

custom:
    notifications:
      - protocol: email
        endpoint: [email protected]
      - protocol: lambda
        endpoint:
          Fn::Join:
            - ":"
            - - "arn:aws:lambda"
              - Ref: "AWS::Region"
              - Ref: "AWS::AccountId"
              - "function"
              - ${self:service}-${self:provider.stage}-snsToSlack

• What stacktrace or error message from your provider did you see?

No error

For feature proposals:

• What is the use case that should be solved. The more detail you describe this in the easier it is to understand for us.
• If there is additional config how would it look

Similar or dependent issues:

Additional Data

• Serverless Framework Version: 1.25
• Stack Trace:
• Provider Error messages:

Subscribing a lambda to a topic isn't enough to make it invokable. Topic must also have permission to call lambda. Here are some readings that helped me to figure out the problem
https://iangilham.com/2016/03/22/Sns-trigger-lambda-via-cloudformation.html (Permission for the Topic to invoke the Lambda),
https://aws.amazon.com/blogs/mobile/invoking-aws-lambda-functions-via-amazon-sns/ (Preparing the Lambda function for invocation)

I was going to make a PR, instead I ended up adding events to my lambda as so:

  snsToSlack:
    handler: snsToSlack.handler
    runtime: nodejs6.10
    package:
      include:
        - snsToSlack.js
    events:
      - sns:
          topicName: ${self:custom.prefix}-alerts-ok
          arn:
            Fn::Join:
              - ":"
              - - "arn:aws:sns"
                - Ref: "AWS::Region"
                - Ref: "AWS::AccountId"
                - ${self:custom.prefix}-alerts-ok

      - sns:
          topicName: ${self:custom.prefix}-alerts-alarm
          arn:
            Fn::Join:
              - ":"
              - - "arn:aws:sns"
                - Ref: "AWS::Region"
                - Ref: "AWS::AccountId"
                - ${self:custom.prefix}-alerts-alarm

See this blog post

In readme functionDuration's default statistic is "Maximum", however in definitions.js it is "Average", and when apply all defaults when deploying lambda, the alert's statistic is "Average", so probably the readme is not correct

Hi - it's been a few days since this was merged into master. Would love it if this feature was released. Is there anything blocking it?

Use jest instead of mocha, chai, sinon and istanbul

This is a Feature Proposal

Description

With this plugin the number of resources in the generated cloudformation template in one of the projects I'm in goes from less than 200 to 322.

It would be great if there was an option to output these resources to another template that could be deployed separately. Or perhaps some other solution.

Additional Data

CloudWatch alarms support the ability to specify actions to take on missing data. See the announcement. This would be very useful for functions that are not triggered often.

Need to check for cloudformation support.

This is a Bug Report

Description

So this feature was introduced with #77 but it doesn't work with the suggested configuration:

topics:
  alarm:
    topic:
      Fn::ImportValue: "exported-topic"

Serverless breaks with the following error: TypeError : topic.indexOf is not a function
I did some digging in the code and found the reason:

An ugly workaround for this one is:

topics:
  alarm:
    Fn::ImportValue: true # or something else it doesn't matter
    topic:
      Fn::ImportValue: "exported-topic"

Additional Data

• Serverless Framework Version: 1.43.0

We don't need to create alerts for all stages. We should specify an array of stages that this plugin is enabled for.

npm WARN [email protected] requires a peer of serverless@^1.12.0 but none is installed. You must install peer dependencies yourself.

• [email protected]
  added 2 packages from 3 contributors in 3.001s

:~$ sls --version
1.35.1

I'm getting a this.providerNaming.getLogGroupName is not a function on deployment. There is something wrong with my setup?

service: gdw-pump-webhook

provider:
  name: aws
  runtime: python2.7
  memorySize: 128
  timeout: 10
  region: ${env:AWS_DEFAULT_REGION}
  deploymentBucket: com.zx-ventures.${env:AWS_DEFAULT_REGION}.serverless.deploys
  iamRoleStatements:
    - Effect: Allow
      Action:
        - kinesis:GetRecords
        - kinesis:GetShardIterator
        - kinesis:PutRecord
        - kinesis:PutRecords
        - kinesis:DescribeStream
        - kinesis:ListStreams
        - firehose:DeleteDeliveryStream
        - firehose:PutRecord
        - firehose:PutRecordBatch
        - firehose:UpdateDestination
        - logs:CreateLogGroup
        - logs:CreateLogStream
        - logs:PutLogEvents
      Resource: '*'
  stackPolicy:
    - Effect: Allow
      Principal: "*"
      Action: "Update:*"
      Resource: "*"
    - Effect: Deny
      Principal: "*"
      Action:
        - Update:Replace
        - Update:Delete
      Condition:
        StringEquals:
          ResourceType:
            - AWS::S3::Bucket

package:
  exclude:
    - tmp/**
    - .git/**
    - .env/**
    - tests/**
    - .cache/**
    - README.md
    - requirements.txt
    - .coveragerc
    - .gitignore
    - .travis.yml
    - htmlcov/**
    - coverage.xml
    - .coverage

custom:
  alerts:
    topics:
      ok: ${self:service}-${opt:stage}-alerts-ok
      alarm: ${self:service}-${opt:stage}-alerts-alarm
      insufficientData: ${self:service}-${opt:stage}-alerts-insufficientData
    function:
      - functionInvocations
      - functionDuration
      - name: functionExceptions
        metric: Exceptions
        threshold: 1
        statistic: Sum
        period: 60
        evaluationPeriods: 1
        comparisonOperator: GreaterThanThreshold
        pattern: \"[ERROR]\"

plugins:
  - serverless-plugin-aws-alerts

functions:
  OrderLinePump:
    handler: lib.machinery.pump
    environment:
      REGION_NAME: ${env:AWS_DEFAULT_REGION}
      STREAM_NAME: ${self:resources.Resources.OrderLineInputStream.Properties.Name}
    events:
      - http:
          path: notification
          method: post
          private: true
          cors: true

  OrderLineValidatedPipe:
    handler: lib.machinery.lake_pipe
    environment:
      REGION_NAME: ${env:AWS_DEFAULT_REGION}
      STREAM_NAME: ${self:resources.Resources.OrderLineFirehoseDeliveryStream.Properties.DeliveryStreamName}
    events:
      - stream:
          arn: arn:aws:kinesis:${env:AWS_DEFAULT_REGION}:${env:AWS_ACCOUNT_ID}:stream/${self:resources.Resources.OrderLineInputStream.Properties.Name}
          batchSize: 5
          startingPosition: LATEST
          enabled: true
...

Add notification configuration for SNS topics that are created by the plugin.

I am trying to capture internal errors. So is it possible to send the log messages along with the alarm? The logs can be marked by a particular string like '500 Error'.

I'm getting The CloudFormation template is invalid: Template format error: Unresolved resource dependencies [AwsAlertsAlarm] in the Resources block of the template

I've got all the config as per the guide but it doesn't seem to create any sns topic resource?

Below is my config. I had a look at S3 Cloudformation template but I couldn't see any resource of AwsAlertsAlarm which is the reason why this is failing

service: testing-backend

provider:
  name: aws
  region: us-east-1
  runtime: nodejs6.10

plugins:
  - serverless-aws-alias
  - serverless-plugin-aws-alerts

custom:
  alerts:
    topics:
      alarm:
        topic: ${self:service}-${opt:stage}-alerts-alarm
        notifications:
          - protocol: email
            endpoint: [email protected]
    definitions:
      geneticErrors:
        metric: GenericErrors
        threshold: 0
        statistic: Minimum
        period: 60
        evaluationPeriods: 1
        comparisonOperator: GreaterThanThreshold
        treatMissingData: notBreaching
        pattern: 'Error'
    alarms:
      - functionErrors
      - functionThrottles
      - geneticErrors

functions:
  test:
    handler: lambda.next

This is a Feature Proposal

Description

For bug reports:

• What went wrong?
• What did you expect should have happened?
• What was the config you used?
• What stacktrace or error message from your provider did you see?

For feature proposals:

• What is the use case that should be solved. The more detail you describe this in the easier it is to understand for us.
  Today this plugin supports creating SNS topics per alarm state or using an existing SNS topic as the action for the alarms created.

I would prefer not to have to create separate SNS topics for each alarm state but instead I would like to have the plugin create a single SNS topic that is the action for Ok,Alarm and Insufficient. In my use case where the alerting endpoint is a pagerduty end point having 2 or 3 topic that hit the send endpoint is redundant

• If there is additional config how would it look
  serveless.yml could look something like this

  alerts:
    stages:
      - beta
    topic: ${self:service}-${opt:stage}-alerts
    notifications:
      - protocol: https
        endpoint:

Similar or dependent issues:

• #12345

Additional Data

• Serverless Framework Version:
• Stack Trace:
• Provider Error messages:

This is a Feature Proposal

Description

For feature proposals:

• I just got an email regarding the new policies for dashboards, we will need to redeploy our serverless with this changes and would be nice update this plugin.

Attachments

Hello,

We are contacting you to let you know that the Amazon CloudWatch Dashboards[1] will be migrating to a new IAM permission policy on April 1, 2018. The new permission policy enables you to restrict and allow access to your dashboards with finer control. You may need to update your current CloudWatch IAM policy for users in your account to continue using dashboards when we migrate to the new permission policy. Please visit the CloudWatch console in any region before April 1, 2018 to check your current permissions and see if any updates are needed.

Today, CloudWatch Dashboards use the permissions to PutMetricData and GetMetricData APIs (actions) in an IAM policy for read and write access. A user with PutMetricData permission is allowed to create and delete dashboards while a user with GetMetricData permission is allowed to view individual dashboards as well as the list of dashboards. As you may know, we recently launched four new APIs for Dashboards[2] – PutDashboard, DeleteDashboards, GetDashboard, and ListDashboards – to dynamically build and maintain your dashboards. Starting April 1, 2018, CloudWatch Dashboards will migrate to using the permissions to these four APIs for read and write access. The new permission policy provides you with an improved access control to your dashboards. After the migration you can, for example, restrict a user from deleting any dashboards while having the access to create or view dashboards.

Please note that if all users in your account have been assigned the “AdministratorAccess” policy, or the “CloudWatchFullAccess” policy or any similar policies that guarantees full access to CloudWatch then you do not need to make any changes. However, if any user in your account does not have such policies that user will not be able to perform part or all the actions available for CloudWatch Dashboards after April 1, 2018. To maintain the current dashboards access control and experience for such users you need to update their IAM policy before April 1, 2018. For example, the IAM policy of a user with GetMetricData permission should be updated to allow GetDashboard and ListDashboards actions. To learn more about this permission policy migration and what updates are needed, please visit here[3]. You will also see this message as a notification in CloudWatch console when you visit next time and an option to check your current dashboards permissions from CloudWatch.

If you have any questions, please contact AWS Support[4].

[1] https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html
[2] https://aws.amazon.com/blogs/aws/new-api-cloudformation-support-for-amazon-cloudwatch-dashboards/
[3] https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/dashboard-permissions-update.html
[4] https://aws.amazon.com/support

This is a Feature Proposal

Description

Currently API name is hard-coded in each file under src/dashboards/widgets/api-gw/. We are using a different naming convention for our API Gateway APIs, and this breaks the dashboards for our alarms. Would it be possible to provide this as a config parameter under the dashboards key?

Additional Data

Add alerts for DynamoDB to monitor capacity usage.

Below errorr occurred when I ran serveless cmd, any clues please? thank you.
./node_modules/.bin/serverless package --package ./build

nodejs version - v12
serverless version - 1.50.2
serverless-plugin-aws-alerts version - v1.4

Configuration:
alerts:
dashboards: true
topics:
alarm:
topic: ${self:service}-${self:custom.stage}-alarm
notifications:
- protocol: ${self:custom.${self:custom.stage}-alarm-notification-protocol}
endpoint: ${self:custom.${self:custom.stage}-alarm-notification-endpoint}
events:
definitions:
CustomAlarm:
description: Health Monitor'
namespace: "AWS/Lambda"
metric: Exceptions
threshold: 3
statistic: Sum
period: 900
evaluationPeriods: 1
comparisonOperator: GreaterThanOrEqualToThreshold
pattern: '{$.state = "Error*"}'
CustomAPIAlarm:
description: 'API Health Monitor'
namespace: "AWS/Lambda"
metric: APICriticalExceptions
threshold: 3
statistic: Sum
period: 900
evaluationPeriods: 1
comparisonOperator: GreaterThanOrEqualToThreshold
pattern: ''
alarms:
- CustomAPIAlarm
- CustomAlarm

The error detail can be found as following:
**TypeError: Cannot convert undefined or null to object** at Function.keys (<anonymous>) at Object.keys.forEach (/codebuild/output/src932548716/src/node_modules/serverless-plugin-aws-alerts/src/index.js:216:14) at Array.forEach (<anonymous>) at AlertsPlugin.compileAlertTopics (/codebuild/output/src932548716/src/node_modules/serverless-plugin-aws-alerts/src/index.js:212:34) at AlertsPlugin.compile (/codebuild/output/src932548716/src/node_modules/serverless-plugin-aws-alerts/src/index.js:356:30) at BbPromise.reduce (/codebuild/output/src932548716/src/node_modules/serverless/lib/classes/PluginManager.js:505:55) at tryCatcher (/codebuild/output/src932548716/src/node_modules/serverless/node_modules/bluebird/js/release/util.js:16:23) at Object.gotValue (/codebuild/output/src932548716/src/node_modules/serverless/node_modules/bluebird/js/release/reduce.js:157:18) at Object.gotAccum (/codebuild/output/src932548716/src/node_modules/serverless/node_modules/bluebird/js/release/reduce.js:144:25) at Object.tryCatcher (/codebuild/output/src932548716/src/node_modules/serverless/node_modules/bluebird/js/release/util.js:16:23) at Promise._settlePromiseFromHandler (/codebuild/output/src932548716/src/node_modules/serverless/node_modules/bluebird/js/release/promise.js:517:31) at Promise._settlePromise (/codebuild/output/src932548716/src/node_modules/serverless/node_modules/bluebird/js/release/promise.js:574:18) at Promise._settlePromise0 (/codebuild/output/src932548716/src/node_modules/serverless/node_modules/bluebird/js/release/promise.js:619:10) at Promise._settlePromises (/codebuild/output/src932548716/src/node_modules/serverless/node_modules/bluebird/js/release/promise.js:699:18) at _drainQueueStep (/codebuild/output/src932548716/src/node_modules/serverless/node_modules/bluebird/js/release/async.js:138:12) at _drainQueue (/codebuild/output/src932548716/src/node_modules/serverless/node_modules/bluebird/js/release/async.js:131:9) at Async._drainQueues (/codebuild/output/src932548716/src/node_modules/serverless/node_modules/bluebird/js/release/async.js:147:5) at Immediate.Async.drainQueues (/codebuild/output/src932548716/src/node_modules/serverless/node_modules/bluebird/js/release/async.js:17:14) at runCallback (timers.js:810:20) at tryOnImmediate (timers.js:768:5) at processImmediate [as _immediateCallback] (timers.js:745:5)

(Support is being added in a PR in a fork already)

This is a Bug Report

Description

I am trying to configure a metric filter alarm with a given filter pattern for the function under my service,

custom:
  alerts:
    topics:
      alarm: 
        topic: arn:aws:sns:eu-west-1:704255512929:CloudWatch-ErrorLogs
    function:
      - name: AnAlarm
        metric: AnError
        treatMissingData: notBreaching
        threshold: 0
        statistic: Sum
        period: 60
        evaluationPeriods: 1
        comparisonOperator: GreaterThanThreshold
        pattern: '[ERROR]'

I was expecting this to create a single metric filter (ERROR) linked a single alarm that is then linked to an SNS Topic (CloudWatch-ErrorLogs), however what is actually happening is 2 metric filters are being created, one with a suffix ALERT and another with a suffix OK.
Both of these are then linked to the same metric and the same alert.

From reviewing the code it appears there is code specific to create 2 metric filters, one for the Alert and one for the OK and I wondered why this was the case?
Would it be possible to support a way of configuring it to exclude the OK metric filters?

Additional Data

• Serverless Framework Version: 1.26.0:

This is a Question / Feature Proposal

Description

For bug reports:

• What went wrong?
• What did you expect should have happened?
• What was the config you used?
• What stacktrace or error message from your provider did you see?

For feature proposals:

• What is the use case that should be solved. The more detail you describe this in the easier it is to understand for us.
  Is it possible to create an alarm with math expressions? For example I would like to have a health percentage (100 - 100 * errors / invocations). Is this possible already to define somehow?

This is a Feature Proposal

Description

Being able to reference a topic created by a CloudFormation template.

custom: 
  alerts:
    topics:
      ok:
        Ref: SNSTopic
      alarm:
        Ref: SNSTopic
      insufficientData:
        Ref: SNSTopic

resources:
  Resources:
    SNSTopic:
      Type: AWS::SNS::Topic
      Properties:
        DisplayName: ${self:service}-${opt:stage}
        Subscription:
          - Endpoint: https://api.opsgenie.com/v1/json/cloudwatch?apiKey=${ssm:/opsgenie/${opt:stage}/api_key}
            Protocol: HTTPS

In some cases, I just want to Ref my SNS topic as I might also be using that ARN somewhere else in my stack.

I have a PR, ready and tested.

Thanks
Julien

The following code doesn't work
notifications: - protocol: email endpoint: - [email protected] - [email protected]

Endpoint takes only string and not a list. How can I send alarm to both of them?

There are so many great questions, bug reports, and pull requests outstanding on this plugin. Is it still actively supported?

What I want to do is to send emails for all alarms to address [email protected] except for functionDuration which needs to send email to a different address [email protected].

Is there a way to do it?

This is a Feature Proposal

Description

I collect metric data on types of transactions. The types are separated by name and version. These are defined as dimensions on the metric.

I want to alarm on if a particular name/version combination occurs. This seems to be possible through the aws cloudwatch cli. I see references to the dimensions flag in your code, but I can't locate any documentation on it being exposed through the plugin or how to use it if it is.

Currently, alarm has invalid dimension. so alarm won't trigger even alarm was created successfully.

This is our example serverless.yml:

# (truncated)

plugins:
  - serverless-plugin-aws-alerts
functions:
  hello:
    handler: handlers.hello
    alarms:
      - functionErrors

custom:
  alerts:
    definitions:
      functionErrors:
        namespace: 'AWS/Lambda'
        metric: Errors
        threshold: 1
        statistic: Minimum
        period: 600
        evaluationPeriods: 1
        comparisonOperator: GreaterThanThreshold

# (truncated)

Generated CloudFormation content:

{
  "Resources": {
    "ValidateFunctionErrorsAlarm": {
      "Type": "AWS::CloudWatch::Alarm",
      "Properties": {
        "Namespace": "AWS/Lambda",
        "MetricName": "Errors",
        "Threshold": 1,
        "Statistic": "Minimum",
        "Period": 600,
        "EvaluationPeriods": 1,
        "ComparisonOperator": "GreaterThanThreshold",
        "OKActions": [],
        "AlarmActions": [],
        "InsufficientDataActions": [],
        "Dimensions": [
          {
            "Name": "HelloLambdaFunctionName",
            "Value": {
              "Ref": "HelloLambdaFunction"
            }
          }
        ]
      }
    }
  }
}

I think value of Dimensions[0].Name should be use 'FunctionName', not ${ref}Name.

I am trying to use the plugin to create a custom metric and an alarm based on that metric. Deploy goes with no error but none of those gets created. sls deploy --verbose does not produce anything related to it.
This is my serverless.yml

...
plugins:
  - serverless-plugin-aws-alerts

custom:
  alerts:
    function:
      - name: Error500Alarm
        metric: Error500
        threshold: 0
        statistic: Minimum
        period: 60
        evaluationPeriods: 1
        comparisonOperator: GreaterThanThreshold
        pattern: 'METRIC Error500'

functions:
  products:
    handler: functions/product/product_lambda.router
    vpc: ${file(../params.yml):${self:custom.stage}.VPC}
    alarms:
      - Error500Alarm
    events:
...

I have probably misunderstood your description and must be doing something wrong, but googling nor reading issues here did not help.

• Serverless Framework Version: 1.8.0

Thank you

It would be awesome to add some niceties which are missing from the cloudwatch offering such as ability to fetch specific log lines matching the pattern and dump to a new topic or to generate the log stream link like this repo:

https://github.com/RoundingWellOS/cloudWatchLogsSlackNotification

I installed the plugin, added some of your defaults to me serverless.yml file, deployed and everything went fine. I pull in my SNS topics from a SSM Parameter store and realized I must have left a space at the end of the paramter. So the alarms deployed, but the SNS topic was invalid. I updated the parameter store, redeployed the entire service and the SNS topic was still referencing the invalid topic in the alarm.

Is there a way to re-deploy the cloudwatch alarms without having to remove and re-deploy the service?

environment:
    commonSNS: ${ssm:commonSNS}

custom:
  enabled:
    dev: false
    prod: true
  
  alerts:
    stages:
      - dev

    dashboards: true

    topics:
      alarm: ${ssm:jiraSNS}
    alarms:
      - functionThrottles
      - functionErrors
      - functionInvocations
      - functionDuration

plugins:
  - serverless-plugin-aws-alerts

Thats the relevant portion of my serverless file. The ${ssm:jiraSNS} parameter was the one that must have had a space at the end of the string, which I removed and was hoping would get picked up when I deployed the service again.

This is a Bug Report

Description

I am trying to reference a SNS Topic that already exists using AWS Pseudo Parameters e.g.

custom:
  alerts:
    topics:
      alarm: 
        topic:
          Fn::Join:
            - ""
            - - "arn:aws:sns:"
              - Ref: "AWS::Region"
              - ":"
              - Ref: "AWS::AccountId"
              - ":CloudWatch-ErrorLogs"
    function:
      - name: SomeAlarm
        description: Some Alarm Description
        metric: SomeMetric
        treatMissingData: notBreaching
        threshold: 0
        statistic: Sum
        period: 60
        evaluationPeriods: 1
        comparisonOperator: GreaterThanThreshold
        pattern: '[ERROR]'

However this results in the following error;

Type Error ---------------------------------------------

topic.indexOf is not a function

 For debugging logs, run again after setting the "SLS_DEBUG=*" environment variable.

Get Support --------------------------------------------
Docs: docs.serverless.com
Bugs: github.com/serverless/serverless/issues
Forums: forum.serverless.com
Chat: gitter.im/serverless/serverless

Your Environment Information -----------------------------
OS: linux
Node Version: 9.4.0
Serverless Version: 1.26.0

Does the plugin not support using AWS Pseudo Parameters or am I just doing something wrong?
Also, I haven't tried it yet but would CloudFormation References work (E.g. ${cf:x.y})?

Additional Data

I also tried using variable resolution instead, so creating a custom variable which the topic then references;

custom:
  sns: 
    Fn::Join:
      - ""
      - - "arn:aws:sns:"
        - Ref: "AWS::Region"
        - ":"
        - Ref: "AWS::AccountId"
        - ":CloudWatch-ErrorLogs"  
  alerts:
    topics:
      alarm: 
        topic: ${self:custom.sns}

However that produced the same result.

• Serverless Framework Version: 1.26.0:

Would be great to be able to add alarms to functions that have http events for things like high 4xx, 5xx, latency etc.

In cloudwatch while creating an alarm, you can specify that insufficient_data state be treated as good and not send an alarm.

I would like to make this setting for the alarm:
https://imagebin.ca/v/3QUAG0PBtGM3

How can I do this?

Add an example project for an example on how it should work and testing.

We should add an editorconfig to provide consistent code formatting.

We have a scenario where we want all "normal" alerts to go to 1 email inbox and then when things go really wrong, we want an alert to a different email address (using an email -> sms gateway).

Example of what I am thinking:

custom:
notifications:

• protocol: email
  endpoint: [email protected]
  codeRedNotifications:
• protocol: email
  endpoint: [email protected]

topics:
alarm:
topic: ${self:service}-${opt:stage, self:provider.stage}-alerts-alarm
notifications: ${self:custom.notifications}
codeRed:
topic: ${self:service}-${opt:stage, self:provider.stage}-alerts-alarm-code-red
notifications: ${self:custom.codeRedNotifications}

function:
namespace: 'AWS/Lambda'
metric: Errors
threshold: 1
statistic: Sum
period: 300
evaluationPeriods: 1
comparisonOperator: GreaterThanOrEqualToThreshold

functionCodeRed:
namespace: 'AWS/Lambda'
metric: Errors
threshold: 5
statistic: Sum
period: 300
evaluationPeriods: 1
comparisonOperator: GreaterThanOrEqualToThreshold
topic: codeRed