N|Solid for AWS Lambda
N|Solid for AWS Lambda
N|Solid for AWS Lambda is a new solution for monitoring the performance and behavior of serverless functions running on Amazon Web Services (AWS) Lambda. Developers and DevOps teams working on serverless applications can now deploy NodeSource’s enhanced Node.js runtime to capture and analyze highly precise, in-depth and overhead free performance metrics.
N|Solid for AWS Lambda provides low-impact performance monitoring for Lambda functions. Users who install the N|Solid runtime as a Lambda Layer can choose between versions based on the Node.js 8 (Carbon) and 10 (Dubnium) LTS release lines, and it takes just a few minutes to get up and running. In order to get started, you will need:
- A NodeSource Account - you can sign up here. Alternatively you can also use the N|Solid runtime layer without having to sign up for an account here. This does however mean that you will not have access to your performance metrics.
- Access to an AWS Accounts
- Access to the AWS Lambda Suite
- The N|Solid Layer ARN
- Log in to your AWS Account
Visit https://aws.amazon.com/ to log in or sign up.
- Navigate to the Lambda Console
- In your AWS account choose the Create function option.
Select Use custom runtime in function code or layer in the Runtime settings dropdown:
After your function is created, in the function's Designer, there is a box labeled Layers. Click the box, then navigate to the section below labeled Referenced layers. Click the Add a layer button, then select the Provide a layer version ARN option.
In order to proceed, you'll need to get some information associated with your NodeSource Account.
- In a new tab or window, log in to your NodeSource Account
Visit https://accounts.nodesource.com and create a new account or to log in to an existing NodeSource account.
You may see a prompt to Create Organization at this stage. While you may find this helpful if you want to invite colleagues to the platform, it’s not a requirement, and you’ll have the ability to create an Org at any point in the future. Feel free to choose the Go it alone option.
- If you've started a trial, you can proceed with the following steps using either your Personal or Organization workspace.
- Once signed in, you will be redirected to the Download & Setup page.
Select the N|Solid for AWS Lambda installation type.
- The install instructions feature a series of selectors, allowing you to choose your preferred AWS region and Node.js version.
Modifying the selected region or Node.js version will modify the ARN provided to you, so please double-check to ensure you that you’ve chosen the options suitable for you. Copy the provided ARN and return to your Lambda console. Paste the ARN into the Layer version ARN field and click Add layer version.
- After your Lambda function has been created successfully, return to your NodeSource Accounts tab to copy your unique N|Solid license key.
- Return to the AWS Lambda console and click your function name in the Designer section. Find the Environment variables section below and create a new custom variable named
NSOLID_LICENSE_KEY. Paste in your N|Solid license key as the value for this variable.
Adding your N|Solid license key as an environment variable connects performance data from your running Lambda functions to your NodeSource Account.
- After your newly-created function starts running, navigate to https://app.nodesource.com to confirm that data from your Lambda function is being displayed in the dashboard.
Latest Node.js LTS Runtime Layer for AWS Lambda
You can also get started with the N|Solid runtime layer without requiring to authenticate or sign up for an account. N|Solid is a drop-in replacement runtime layer that is available for Node.js LTS releases including Node.js V10. You can use our runtime layer in place of Node.js without signing up for an account, simply visiting https://www.nodesource.com/latest-lambda to obtain the configuration for your AWS Lambda production environment.
Why aren’t my AWS Lambda functions sending data?
A No Functions Connected error likely means that your function was unable to connect to our dashboard, or that it’s connected but the function isn’t currently running. Please revisit the Getting Started instructions above and check your CloudWatch logs for errors. If you’ve verified that your function is running, and you are certain that you followed the steps above, please contact our support team here for further assistance.
I saw Could not verify your NodeSource license key, usage metrics will not be reported. in CloudWatch, what does it mean?
Lambda needs to use a valid NodeSource license key in order to communicate with NodeSource services and report metrics to your dashboard. Ensure that your network policy allows connectivity to our network, and that the NSOLID_LICENSE_KEY environment variable you set in your Lambda function exactly matches the key found in your account or organization profile settings.
Is there any cost to use N|Solid for AWS Lambda?
No. N|Solid for AWS Lambda is a new NodeSource offering, and at time of launch is free to use. We plan to continue improving this product offering, and we may offer paid tiers for access to more advanced features in the future. In the meantime, we hope users take this opportunity to explore our new offering at no cost!
What is this histogram thing, and how do I use it?
The histogram provides a high level overview of your function's invocation performance over time. It represents invocation density for a single function over the most recent period and gives you a visual indicator of its health and usage.
More information on how to interpret Histogram data is available here
What is the expected performance impact of using N|Solid for AWS Lambda?
The N|Solid runtime is built for monitoring applications with a minimal performance impact. Unlike many conventional solutions, the N|Solid agent, which samples performance metrics deep within the runtime itself, reports data via a separate thread. While we constantly evolve our product to decrease overhead, here is what you can expect:
50ms average call time to NodeSource's metrics API. Data reporting takes place outside the Lambda handler, and metrics reported to our API as quickly as possible to reduce execution time. Reporting will not delay the completion of the function from the caller's perspective.
Invocations that produce a CPU profile will consume slightly more CPU and memory than ordinary invocations. Your function configuration needs to allow for this additional memory usage, which should render sampled invocation overhead negligible. CPU profiles are generated for the first invocation each minute and 1% of invocations thereafter.
How long do you keep my data?
Data from Lambda functions will be displayed in the N|Solid console for a maximum of 24 hours. Please contact us if your team needs a longer retention window.
Do you offer a version of the N|Solid runtime corresponding to my current Node.js version?
Users who install the N|Solid Runtime as a Lambda Layer can choose between versions based on the Node.js 10 (Dubnium) and 8 (Carbon) LTS release lines.
How do I keep my runtime version up-to-date?
When a new version of the N|Solid runtime is available, your dashboard will alert you to its availability. To update, you can obtain the newest N|Solid ARN from the N|Solid for AWS Lambda Setup page and simply replace your current runtime Layer with the new one using the AWS Lambda console or the command line.
Monitoring Lambda Performance
Monitoring your Lambda Functions
After you’ve completed the setup steps to install the N|Solid runtime as a Layer on AWS Lambda, performance data will be sent to the NodeSource dashboard. Reported metrics include function-specific execution times, cold start and error metrics, and additional indicators to help users identify and debug anomalous behavior.
The NodeSource Dashboard provides you with a centralized view to monitor the performance of your AWS Lambda functions. Performance data captured from your AWS Lambda functions will be displayed on this screen once you’ve completed the setup and configuration steps.
The left side panel lists all of connected Lambda functions, and can be sorted by function name, invocation rate, execution time, or error percentage. Should you have trouble viewing your functions' metrics, please revisit the install instructions above.
The following high-level metrics are presented alongside each function listed in the left side panel:
- Invk Rate: Number of times the function has been invoked per minute.
- Average Time: Average execution time in milliseconds.
- Error Percentage: Average percentage of functions terminating due to an error.
Click on a function listed in the left side panel to see detailed invocation metrics, including:
- A histogram providing insight into your function’s invocation metrics, observed error states, and cold starts
- A list of each invocation of that function within the selected time period.
The histogram provides a high-level overview of your function's invocation performance over time:
The histogram header component provides aggregate performance statistics and indicators, including:
- Total: Total number of function invocations.
- Invoke Rate: Number of function invocations per minute.
- Average Time: Execution time milliseconds averaged over all function invocations.
- Errors: Number of times a function invocation exited.
- Cold Starts: Number of cold starts that occured when a Lambda function spun up.
Understanding the Histogram Visualization
The histogram visualization presents information about the performance of your Lambda functions.
Invocation buckets are presented in the histogram as shaded rectangles (cells) of varying color density.
- The position of a bucket along the X-Axis indicates the time period in which activity took place.
- The position of a bucket on the Y-Axis indicates the invocation duration in milliseconds.
- A bucket's color density indicates the relative number of invocations which for a given X,Y position.
Each colored bar represents a tracked function execution within the selected time period.
- Red bars indicate an Error. Clicking on the bucket containing the error line allows you to filter the invocation list; you can also sort by error type
- Blue bars indicate a cold start.
You will be shown a list of all invocations that fall into the chosen time period of either 24h, 12h, or 1h, accompanied with extra invocation details. Change the selected time-period at the top of the left-side functions list via the Period selector.
The Invocations list includes the following columns:
- Invoked: Time and date the function was invoked.
- Duration: Duration for which the function ran.
- Version: This displays the Node.js version the function is running on.
- Error: Indicator whether an error has occurred or not.
- Profile: Your N|Solid Runtime Layer which executes your code on AWS Lambda dynamically samples a minimum of 1 invocation / minute and 1% of invocations thereafter.
Items in the Invocations list can be sorted by their respective values for any visible column.
Additionally, you can filter both the invocations list and the histogram visualization for the following attributes:
- Has CPU profile
- Has cold starts
- Has errors
Click on the Error button to see detailed information, including a stack trace if you return an error object
You can view individual CPU profiles by clicking on the view button contained in a sampled functions profile column. Once clicked you will be redirected to a time-domain graph containing a CPU profile.
CPU profiles are visualized with a time domain graph for easier inspection. Clicking on any horizontal bar in the CPU profile stack will let you observe that components in isolation.
Module Risk & Security
The Module’s Tab in N|Solid for AWS Lambda provides users with an up-to-date risk, compliance and security assessment report, which delivers clear indicators of the overall risk level reflected in your serverless functions.
How does it work?
This feature provides you and your teams with actionable insights into the risk levels that are present in your serverless function’s third-party packages.
Important: For this feature to work it is required that a package-lock.json is included in the deployed function code.
NodeSource scores packages on npm on the basis of a number of weighted criteria, which include tests for existing security vulnerabilities, license concerns, code risk and code quality. This information is combined with the packages used by your lambda function to provide a continually-updated understanding of your level of risk exposure (as well as mitigation information) in the Modules Tab.
Module List Tab
To access your function’s list of third-party packages navigate to the ‘Modules’ Tab. This provides a rich Security, Compliance, Package Risk and quality report for every package that is used inside of your serverless function. To evaluate each package, NodeSource utilizes its NCM 2 Certification Pipeline described here.
Each module is subject to a set of indicators which are described below:
Code Risk Indicator
The code risk indicator highlights known code risk levels for each of your modules on a four-level scale. NodeSource tests each package in your serverless function for security vulnerabilities, compliance concerns risk-factors. Each risk factor indicates whether a package's inclusionmay be abnormally risky.
You code risk increases if:
- you have packages being exposed to security vulnerabilities,
- contain licenses which may expose your company legally
- or a combination of other risk factors making your package's usage or installation abnormally risky, outside of purely security. A list of risk factors can be found here.
Code Risk Indicator
||Code Risk Level
||Avoid install without manually inspecting this package's code & scripts.
||Manually inspecting this package's code & scripts before install is recommended.
||Inspecting this package's code before use is recommended.
||This package does something less-than-ideal that could manifest risk in some circumstances.
||NodeSource hasn’t found anything of note.
Security Vulnerability Flag
The security flag indicates the presence of a security vulnerability and its severity.
||Critical severity vulnerability
||High severity vulnerability
||Medium severity vulnerability
||Low severity vulnerability
Compliance Concern Flag
The compliance flag indicates elevated legal and/or security implications. The license score is intended to indicate that a given module has a license which is permissible for use, allows redistribution & modification, and does not require source disclosure. The list of The list of currently acceptable licenses can be found here.
The deprecated flag is used to indicate that a package has been deprecated and may require updating.
Hover-over dependency tooltip indicates which modules in your function’s dependency require said module:
From the Module List View, users will be able to select an individual packages which navigates them to the Module Details view:
This view provides a detailed account of each third-party module in your serverless function:
Module Name and Report Summary: A high level overview that delivers a quick summary of the module’s:
- Risk Score
- Number and severity of security vulnerabilities
- Number of compliance concerns
- Number of Risk Factors identified
- Information about when the package was released
Required By: A detailed list of dependency-paths that indicates which modules in your function’s dependency require said module.
Security Vulnerability Report: A list of known security vulnerabilities.
Compliance Report: A list of known compliance concerns which have been flagged by NodeSource’s criteria for their elevated legal and/or security implications. The license score is intended to indicate that a given module has a license which is permissible for use, allows redistribution & modification, and does not require source disclosure. The list of currently acceptable licenses. For additional information on the compliance section please visit this docs site.
Module Risk: The Risk group contains criteria which are intended to indicate whether a package's usage or installation may be abnormally risky. This group is distinct from the security vulnerability section because it displays risk from sources other than security vulnerabilities, including:
- Packages which include code which could have severe implications if misused.
- Packages which are likely to cease functioning in a future Node.js major upgrade.
- Packages which have poor error handling.
View more information about NodeSource’s risk assessment criteria here.
- Code Quality: The Quality group is for criteria which are intended to indicate whether a package conforms to good open-source practices. Good practice are listed as follows. You can read more about NodeSource’s quality assessment criteria here.
- Readme: Users can access a rendered version of the package’s readme if it is available (see screenshot below).
N|Solid for AWS Lambda’s settings page allows users to set a sample rate to customize how frequently CPU profiles are collected on serverless function executions. You can choose the frequency in which you want to collect the samples in a period of time and the sample probability of the function in percentage.
How does it work?
To minimize monitoring overhead, N|Solid for AWS Lambda samples a subset of all function invocations, instead of sampling every invocation.
The sample rate is determined by sample frequency and sample probability:
Sample frequency: determines the time-intervals in which serverless functions are sampled for a detailed profile. If the sample frequency is set to 10 minutes, N|Solid takes a profile at the beginning of every 10 minute-interval while your function is running. If it runs less often, the sample will be captured on the next invocation following this period.
Sample probability: sets the probability with which a single invocation is sampled for a detailed profile. This is independent of the sample frequency. So, for instance, if your Sample Probability is set to 10%, there is a 10 percent chance that a new function invocation will be sampled. That way, you can ensure that both long- and short-lived functions receive samples independent of how long they live.
For production instances, you might want to choose a lower sample probability to optimize the performance of your serverless application, while for staging or development instances you might lean toward a higher sample frequency and sample probability to help diagnose potential issues before they reach production.
Once adjusted, both sample frequency and sample probability are updated on the function’s next cold start.