AWS Lambda Monitoring Integration
With AWS Lambda, you can configure your back-end service and applications as event driven functions and scale automatically based on demand, without the need to provision and manage compute resource. Using Site24x7's AWS Lambda integration you can monitor critical Lambda metrics and function executions logs to optimize execution time and performance.
Additionaly, you can monitor Lambda@Edge and Lambda Extensions with Site24x7.
Setup and configuration
- If you haven't done already, enable site24x7 access to your AWS account via IAM user creation or cross-account IAM role. Learn more.
- In the Integrate AWS Account page, please make sure the checkbox next to the Lambda function listing is selected. Learn more.
Policy and permissions
The following permissions are required by Site24x7 to discover and monitor Lambda functions. Learn more.
- "lambda:ListFunctions",
- "lambda:ListTags",
- "lambda:GetFunctionConfiguration",
- "lambda:GetAccountSettings",
- "logs:DescribeLogStreams",
- "logs:GetLogEvents",
- "lambda:GetPolicy"
Collecting function execution logs.
To help Site24x7 collect and store logs generated by your application code provide the following permissions:
- logs:Describe*: Lists the log streams for the specified log group
- logs:Get* : List log events for a specified log stream.
Before your begin, please make sure the execution role assigned to the Lambda function has the necessary permissions to publish requests and function execution logs to CloudWatch logs.
Polling frequency
Site24x7 queries the CloudWatch API as per the poll frequency set (1 minute to a day), to collect performance metrics for your Lambda function. Learn more.
IT Automations
You can add automations for the AWS services supported by Site24x7. Log in to Site24x7 and go to Admin > IT Automation Templates (+) > Add Automation Templates. Once automations are added, you can schedule them to be executed one after the other.
You can now invoke a Lambda function using Amazon Lambda automations.
Supported performance counters
| Attribute | Description | Statistics | Data type |
|---|---|---|---|
| Invocation Duration | Measures the number of times your code got executed in response to an event source or to an external API request. This metric includes successful, and failed invocations. | Sum and average | Count |
| Invocation Errors | Measures the number of times an invocation failed to execute a Lambda function due to errors in the application code. Invocations returning a 4xx response code are counted towards this performance counter. Invocations that failed due to exceeding concurrency limits or internal service failure (5xx response code) are not included. | Sum and average | Count |
| Execution Duration | Measures the elapsed time from when your serverless application code starts executing as a result of an invocation from an event source to when it stops executing. | Sum and average | Milliseconds |
| Execution Throttles | Measures the number of times Lambda function invocation requests were throttled. This happens when function invocation rate exceeds the concurrency limits. | Sum and average | Count |
| Iterator Age | Measures the age of the last record for each batch of records processed. Applicable only for stream based invocations. | Sum | Count |
| Dead Letter Error | Incremented when Lambda is unable to write the failed event payload to your configured Dead Letter Queues. | Sum | Count |
| Concurrent Executions | The number of function instances that are processing events. | Maximum | Count |
| Post Runtime Execution Duration | The cumulative time spent between the runtime Next API request and the last extension Next API request. | Maximum | Milliseconds |
| URL Request Count | Measures the number of URL function requests. | Sum | Count |
| URL 4xx Count | Measures the number of requests that returns a 4xx HTTP status code error. The 4xx series errors are received in the server response, when there is an error in the client request. | Sum | Count |
| URL 5xx Count | Measures the number of requests that returns a 5xx HTTP status code error. The 5xx series errors indicate server-side errors such as function errors and timeouts. |
Sum | Count |
| URL Request Latency | Measures the time taken by the function URL to receive and respond to a request. | Average | Milliseconds |
Configuration details
| Metadata | Description |
|---|---|
| Runtime | The runtime environment of the application code. |
| Handler | The function that the AWS Lambda service calls to execute your application code. |
| Role ARN | The Amazon Resource Name of the IAM Role assigned at the time of function creation.This defines the permission of the function. |
| Region | The Region where the function gets executed. |
| Amazon Resource name (ARN) | The name of the function. |
| Description | User defined function description. |
| Version | The version of the application code. |
| Last modified time | The time stamp for when the function was last updated. |
| Memory size | The memory size configured for the function. |
| Timeout(secs) | The elapsed time at which the Lambda service should terminate the function. |
| Code Size | Size of the compressed deployment package. |
| Code SHA256 | SHA256 hash of your function deployment package. |
| KMS key ARN | The Amazon Resource Name of the KMS key used to encrypt your functions environment variables. |
| Master ARN | Amazon Resource Name of the master function |
| VPC ID | The VPC ID associated with your Lambda function. |
| Security groups | Security groups associated with your Lambda function. |
Troubleshoot function errors
View logging data in the Site24x7 console for your serverless applications using the following methods
- Select the "Recent logs" tab in the Lambda details page to see recently published code generated logs. Review function duration, memory consumed, event source and errors
- View log prints for outages associated with the "errors" metric threshold violation. Navigate to the outages tab, select an outage pertaining to the "errors" metric violation, click on the
and select "View Logs".
AWS Lambda function URLs integration using Webhooks
Using Webhooks, you can connect your Site24x7 data with multiple applications. In this case, the Hook URL is an AWS Lambda functions URL where specific events generated in Site24x7 such as the change in status of the monitors to trouble or critical, trigger the Webhook. In response to this, a signal to the Lambda Function URL is invoked via an HTTP request.
Any trigger event in Site24x7 will post the event data to the AWS Lambda function URL specified by you. It allows you to streamline and manage your critical Site24x7 alarms, incidents, or messages in any third-party application.
CORS- Cross-origin resource sharing
Cross-Origin Resource Sharing (CORS) is a mechanism that allows a request from one URL to another URL. These requests can be simple, pre-flight, and credential based.
Headers in CORS:
You can add HTTP headers through the Webhooks as below:
- Access-Control-Allow-Origin: Checks whether the response can be shared with requesting code from origin.
- Access-Control-Allow-Credentials: Checks whether the response to the request can be exposed when the credentials flag is true.
Public Endpoint API
Through Site24x7, you can also access public end points with the help of Webhooks.
Integration level
You can choose the desired integration level to either push specific alarms from a monitor or all alarms from your Site24x7 account to the AWS Lambda function URL.
- Integration at the monitor level lets you choose the desired monitor to send out alarms.
- Integration at the tag level lets you choose the desired tag to send alarms from Site24x7 monitors associated with the tag.
- Integration at all monitors level lets you send out all Site24x7 alarms.
Check Webhooks Integration to know more.