Skip to main content
Version: 4.10.0

Serverless

NodeSource offers Serverless support to collect data during a request in serverless settings. This data aids in debugging latency and other issues, making it ideal for those keen on addressing such problems in a serverless context.

AWS Setup

For using AWS resources, you need to configure the AWS SDK credentials. Check the AWS documentation to do this. After following the guide, your AWS CLI should be set up correctly for smooth AWS interactions.

Make sure you have all AWS credentials envs configured in your machine.

Env
AWS_SECRET_ACCESS_KEY
AWS_DEFAULT_REGION
AWS_ACCESS_KEY_ID

Configuration

Using nsolid-serverless, you can create the necessary infra resources and configure your serverless application to send telemetry data to the N|Solid Console.

Install

> npm i -g @nodesource/nsolid-serverless

Cratting basic infra to collect data

The first step is to create a SQS Queue where we will send the telemetry data.

> nsolid-serverless infra --install

Collecting telemetry data

We need to setup some environment variables and layers in your lambdas to send data to our SQS queue created in the previous step.

> nsolid-serverless functions --install

Help

> nsolid-serverless --help

Adding Integration

After all the functions are set up, you need to configure the N|Solid Console. Navigate to Settings > Integration. On the right side, there is a section called AWS SQS INTEGRATION as below:

Click on the New AWS SQS Integration button to add the integration. The following form will be displayed:

Fill in the form with the following information:

Click on the Save Integration button to save the integration.

Monitoring Serverless via N|S Console UI

In the N|Solid Console, go to the the applications dashboard and tab the Functions on the left side.

The dashboard for the functions connected will be displayed as below:

FUNCTION DETAIL VIEW

Select a function from the list to see the details of the function. The detail view will be displayed as below:

The detail view will display the following information:

  • RUNTIME VERSION: The version of the Node.js runtime used by the function.
  • FUNCTION VERSION: The version of the function.
  • ACCOUNT ID: The account ID of the function.
  • ZONE: The zone of the function.
  • ARCHITECTURE: The architecture of the function.
  • ESTIMATED COST: The estimated cost of the function.

Metrics

The metrics tab will display the metrics of the function. The metrics will display the following information:

Telemetry API Metrics

This is the list of metrics we will be generating that come from the Telemetry API. These metrics are real-time and associated to specific functions. Their corresponding aggregations are to be performed in the Telemetry Aggregator.

  • duration: The duration of the function in milliseconds.
  • initDuration: The duration of the function initialization in milliseconds.
  • billedDuration: The duration of the function billed in milliseconds.
  • invocations: The number of invocations of the function.
  • maxMemoryUsed: The maximum memory used by the function in megabytes.
  • errors: The number of errors of the function.
  • responseDuration: The duration of the response of the function in milliseconds.
  • responseLatency: The latency of the response of the function in milliseconds.
  • producedBytes: The number of bytes produced by the function.
  • timeouts: The number of timeouts of the function.
  • estimatedCost: The estimated cost of the function.

Cloudwatch Metrics

These metrics are extracted directly from the Cloudwatch API by the Lambda Metrics Forwarder and are not real-time as the ones from the Telemetry API. The list is:

  • Invocations: The number of invocations of the function.
  • Errors: The number of errors of the function.
  • DeadLetterErrors: The number of dead letter errors of the function.
  • DestinationDeliveryFailures: The number of destination delivery failures of the function.
  • Throttles: The number of throttles of the function.
  • ProvisionedConcurrencyInvocations: The number of provisioned concurrency invocations of the function.
  • ProvisionedConcurrencySpillOverInvocations: The number of provisioned concurrency spill over invocations of the function.
  • ConcurrentExecutions: The number of concurrent executions of the function.
  • ProvisionedConcurrentExecutions: The number of provisioned concurrent executions of the function.
  • ProvisionedConcurrencyUtilization: The utilization of the provisioned concurrency of the function.
  • UnreservedConcurrentExecutions: The number of unreserved concurrent executions of the function.
  • Duration: The duration of the function in milliseconds.
  • PostRuntimeExtensionsDuration: The duration of the post runtime extensions of the function in milliseconds.
  • IteratorAge: The age of the iterator of the function.

Loading Opentelemetry Instrumentation Modules

The NSOLID_INSTRUMENTATION environment variable is used to specify and load the opentelemetry instrumentation modules that you want to utilize within your application. To enable instrumentation for specific modules, follow these steps:

  • For HTTP requests using the http module, set the NSOLID_INSTRUMENTATION environment variable to http.

  • If you're also performing PostgreSQL queries using the pg module, include it in the NSOLID_INSTRUMENTATION environment variable like this: http,pg.

  • Make sure to list all the relevant instrumentation modules required for your application. This will enable tracing and monitoring for the specified modules, providing valuable insights into their performance and behavior.

Tracing

To enable the Tracing using N|Solid, set the env var NSOLID_TRACING_ENABLED=1. By enabling this feature, you can troubleshoot HTTP, DNS and other network request problems that you might encounter using the N|Solid Console.

The view will be shown as below:

Tracing is consists of three key components below:

  • Timeline Graph: a timeline graph of Tracing data showing the density of the number of tracing spans.
  • Filter: a filter input area to filter the results by attributes of the span.
  • Spans(Results): a span is the building block of a trace and is a named, timed operation that represents a piece of the workflow in the distributed system. multiple spans are pieced together to create a trace.

Note: The default behavior only generates traces related to the lambda invocation. If you require tracing for additional operations, set the NSOLID_INSTRUMENTATION environment variable.

Available modules for tracing are as follows:

  • aws: AwsInstrumentation
  • dns: DnsInstrumentation
  • graphql: GraphQLInstrumentation
  • grpc: GrpcInstrumentation
  • http: HttpInstrumentation
  • ioredis: IORedisInstrumentation
  • mongodb: MongoDBInstrumentation
  • mysql: MySQLInstrumentation
  • net: NetInstrumentation
  • pg: PgInstrumentation
  • redis: RedisInstrumentation

Please ensure you have the necessary modules enabled to trace all the operations you require.

Timeline Graph

A timeline graph displays the density of the number of tracing spans. Below is the description of the color of a slot on the timeline graph:

ColorDescription
greeneverything is ok
yellowmaybe you should look at this
reddefinitely you should look at this

Assume that a simple request was made to the “console” service to monitor traces:

As a result, the Console displays the whole “span” information.

Span

A span is the building block of a trace and is a named, timed operation that represents a piece of the workflow in the distributed system. Multiple spans are pieced together to create a trace.

Traces are often viewed as a tree of spans that reflects the time that each span started and completed. It also shows you the relationship between spans. A trace starts with a root span where the request starts. This root span can have one or more child spans, and each one of those child spans can have child spans.

Inspecting Span Details

To inspect the span details of a span, click on the title Service & Operation:

Below are the attributes of the span:

AttributeDescription
idthe id of the application
appthe name of application
hostnamethe name of the host machine
tagsthe tags of the application
span_attributes_http_methodthe http method of span attributes
durationthe duration of the span
span_attributes_http_status_codethe http status code of the span attributes
span_attributes_http_status_textthe http status text of the span attributes
span_attributes_http_urlthe http url of the span attributes
span_endthe end time of the span
span_idthe id of the span
span_namethe name of the span
span_parentIdthe parent ID of the span
span_startthe start time of the span
span_status_codethe status code of the span
span_threadIdthe thread ID of the span
span_traceIdthe trace ID of the span
span_typethe type of the span
resourceSpansan array of resource spans
attributesan array of attributes
keythe key of the attribute
valuethe value of the attribute
stringValuethe string value of the attribute
telemetry.sdk.languagethe language of the telemetry SDK
telemetry.sdk.namethe name of the telemetry SDK
telemetry.sdk.versionthe version of the telemetry SDK
cloud.providerthe cloud provider
cloud.platformthe cloud platform
cloud.regionthe cloud region
faas.namethe name of the function as a service
faas.versionthe version of the function as a service
process.pidthe process ID
process.executable.namethe name of the executable
process.commandthe command
process.command_linethe command line
process.runtime.versionthe version of the runtime
process.runtime.namethe name of the runtime
process.runtime.descriptionthe description of the runtime
droppedAttributesCountthe number of dropped attributes
MessageAttributesthe message attributes
eventTypethe event type
StringValuethe string value
DataTypethe data type
instanceIdthe instance ID
functionArnthe Amazon Resource Name (ARN) of the function

Let's authenticate using the console service, which is going to perform a request to the google-auth-service to authenticate the user.

The graph below represents a “path”, from the console service to the authentication service, N|Solid will monitor the HTTP traces in this distributed system.

As such, graph is showing the whole “path”, starting from the console and finishing with the sms service. This is how distributed tracing works using N|Solid managed systems.

The collected information can be used for debugging latency issues, service monitoring, and more. This is a valuable addition to users for those who are interested in debugging a request latency. Tracing traces of user requests through multiple Node applications, and collecting data that can help find the cause of latency issues, errors, and other problems in a distributed system.

SBOM

The SBOM tab will display the SBOM(Software Bill of Materials) of the function. The SBOM will display the following information:

  • Name: The name of the package.
  • Version: The version of the package.
  • Risk: The level of risk associated with using this package.
  • License: The license under which the package is distributed.
  • Author: The author of the package.
  • Number of CVEs / CWEs: The number of known Common Vulnerabilities and Exposures (CVEs) or Common Weakness Enumerations (CWEs) associated with the package.
  • Path: The path to the package within the application.

Changing Time Range

To change the time range, click the calendar icon above the graphs:

This will show a calendar from which users can select the time range. The timeline graph range is updated every 1 minute, with an option to change the date range every 1 minute. In summary, with NodeSource's Serverless monitoring, users can gain more insight into the performance of their serverless functions and quickly identify and debug any issues.

Uninstall

> nsolid-serverless infra --uninstall