|
| 1 | +--- |
| 2 | +description: SUSE Observability |
| 3 | +--- |
| 4 | + |
| 5 | +# Auto-Instrumenting a NodeJS Lambda |
| 6 | + |
| 7 | +## Introduction |
| 8 | + |
| 9 | +This document guides you through auto-instrumenting NodeJS Lambda functions using OpenTelemetry. Auto-instrumentation simplifies the process of adding observability to your Lambda functions by automatically capturing performance metrics and tracing information. |
| 10 | + |
| 11 | +## Prerequisites |
| 12 | + |
| 13 | +Before you begin, ensure you have the following: |
| 14 | + |
| 15 | +- **AWS Lambda function:** The function you want to instrument. |
| 16 | +- **OpenTelemetry SDK:** Installed in your Lambda function. |
| 17 | +- **OpenTelemetry Collector:** Deployed and configured. |
| 18 | +- **SUSE Observability:** An account with SUSE Observability where you'll send your telemetry data. |
| 19 | +- **Memory:** Enough memory to run the Lambda’s including the instrumentation. |
| 20 | + |
| 21 | +## Values supplied by the environment |
| 22 | + |
| 23 | +OpenTelemetry relies on various configuration values to function correctly. These values control aspects like data collection, exporting, and communication with backend systems. To make your OpenTelemetry deployment flexible and adaptable to different environments, you can provide these settings through environment variables. This approach offers several benefits: |
| 24 | + |
| 25 | +- **Dynamic Configuration:** Easily adjust settings without code changes. |
| 26 | +- **Environment-Specific Settings:** Configure OpenTelemetry differently for development, testing, and production. |
| 27 | +- **Secret Management:** Securely store sensitive information like API keys. |
| 28 | + |
| 29 | +For the OpenTelemetry setup described in this documentation, you'll need to define the following environment variables: |
| 30 | + |
| 31 | +- **`VERBOSITY`:** Controls the level of detail in OpenTelemetry logs. |
| 32 | +- **`OTLP_API_KEY`:** Authenticates your Lambda function to send data to SUSE Observability. |
| 33 | +- **`OTLP_ENDPOINT`:** Specifies the address of your SUSE Observability instance. |
| 34 | +- **`OPENTELEMETRY_COLLECTOR_CONFIG_FILE`:** Points to the configuration file for the OpenTelemetry Collector. |
| 35 | +- **`AWS_LAMBDA_EXEC_WRAPPER`:** Configures the Lambda execution environment to use the OpenTelemetry handler. |
| 36 | +- **`OTLP_INSTR_LAYER_ARN`:** Provides the ARN (Amazon Resource Name) of the OpenTelemetry instrumentation layer, which adds the necessary components for auto-instrumentation. |
| 37 | +- **`OTLP_COLLECTOR_LAYER_ARN`:** Provides the ARN of the OpenTelemetry collector layer, which is responsible for receiving, processing, and exporting telemetry data. |
| 38 | + |
| 39 | +**Important Considerations:** |
| 40 | + |
| 41 | +- **GRPC Endpoint:** The `OTLP_ENDPOINT` should specify the gRPC endpoint of your SUSE Observability instance without any `http` or `https` prefix. Use port 443 for secure communication. |
| 42 | +- **Region-Specific Layers:** Lambda layers are region-bound. Ensure that the ARNs you use for `OTLP_INSTR_LAYER_ARN` and `OTLP_COLLECTOR_LAYER_ARN` match the AWS region where your Lambda function is deployed. |
| 43 | +- **Architecture Matching:** The OpenTelemetry Collector layer is architecture-specific. Choose the correct ARN for your Lambda function's architecture (e.g., `amd64` or `arm64`). |
| 44 | + |
| 45 | +**A complete example: be aware you need to input your own values.** |
| 46 | + |
| 47 | +```yaml |
| 48 | +VERBOSITY: "normal" |
| 49 | +OTLP_API_KEY: "<your api key for sending data to SUSE Observability here>" |
| 50 | +OTLP_ENDPOINT: "<your-dns-name-for-suse-observability-here>:443" |
| 51 | +OPENTELEMETRY_COLLECTOR_CONFIG_FILE: "/var/task/collector.yaml" |
| 52 | +AWS_LAMBDA_EXEC_WRAPPER: "/opt/otel-handler" |
| 53 | +OTLP_INSTR_LAYER_ARN: "arn:aws:lambda:<aws-region>:184161586896:layer:opentelemetry-nodejs-0_11_0:1" |
| 54 | +OTLP_COLLECTOR_LAYER_ARN: "arn:aws:lambda:<aws-region>:184161586896:layer:opentelemetry-collector-<amd64|arm64>-0_12_0:1" |
| 55 | +``` |
| 56 | +
|
| 57 | +## The collector.yaml file |
| 58 | +
|
| 59 | +OTEL collection configuration sets up how the data collected should be distributed. This is done in the collector.yaml file placed in the src directory where the lambda files can be found. Below is an example collector.yaml file. |
| 60 | +
|
| 61 | +```yaml |
| 62 | +# collector.yaml in the root directory |
| 63 | +# Set an environemnt variable 'OPENTELEMETRY_COLLECTOR_CONFIG_FILE' to |
| 64 | +# '/var/task/collector.yaml' |
| 65 | + |
| 66 | +receivers: |
| 67 | + otlp: |
| 68 | + protocols: |
| 69 | + grpc: |
| 70 | + http: |
| 71 | + |
| 72 | +exporters: |
| 73 | + debug: |
| 74 | + verbosity: "${env:VERBOSITY}" |
| 75 | + otlp/stackstate: |
| 76 | + headers: |
| 77 | + Authorization: "SUSEObservability ${env:OTLP_API_KEY}" |
| 78 | + endpoint: "${env:OTLP_ENDPOINT}" |
| 79 | + |
| 80 | +service: |
| 81 | + pipelines: |
| 82 | + traces: |
| 83 | + receivers: [otlp] |
| 84 | + exporters: [debug, otlp/stackstate] |
| 85 | + processors: [] |
| 86 | + metrics: |
| 87 | + receivers: [otlp] |
| 88 | + exporters: [debug, otlp/stackstate] |
| 89 | + processors: [] |
| 90 | +``` |
| 91 | +
|
| 92 | +Be aware this collector is used to send the data over to a next collector which then is used for tail sampling, metric aggregation, etc. before sending data over to SUSE Observability. This second collector also needs to run in the customer's environment. |
| 93 | +
|
| 94 | +Depending on the desired functionality, or based upon factors such as volumes of data being generated by lambdas instrumented in this way, collectors can be set up for batching, tail-sampling, and other pre-processing techniques to reduce the impact on SUSE Observability. |
| 95 | +
|
| 96 | +See this page for [guidance and instruction](../../proxy-collector.md) on how to set up a batching collector that acts as a security proxy for SUSE Observability. |
| 97 | +See this page for [instructions](../../collector.md) on how to set up a collector that does tail-sampling as well. |
| 98 | +For more information about processor configuration on the opentelemetry collector, see the [official documentation](https://github.com/open-telemetry/opentelemetry-collector/blob/main/processor/README.md). |
| 99 | +
|
| 100 | + |
| 101 | +
|
| 102 | +## Package.json |
| 103 | +
|
| 104 | +Make sure to add `"@opentelemetry/auto-instrumentations-node": "^0.55.2",` to `package.json` and execute `npm install` to add the auto-instrumentation client libraries to your NodeJS Lambda. |
| 105 | + |
| 106 | +## Troubleshooting |
| 107 | + |
| 108 | +### Timeouts |
| 109 | + |
| 110 | +If the addition of the OTEL Lambda layers results in lambdas that time out (checking the logs might indicate that the collector was asked to shut down while still busy, e.g. seeing the following log entry): |
| 111 | + |
| 112 | +```json |
| 113 | +{ |
| 114 | + "level": "info", |
| 115 | + "ts": 1736867469.2312617, |
| 116 | + "caller": "internal/retry_sender.go:126", |
| 117 | + "msg": "Exporting failed. Will retry the request after interval.", |
| 118 | + "kind": "exporter", |
| 119 | + "data_type": "traces", |
| 120 | + "name": "otlp/stackstate", |
| 121 | + "error": "rpc error: code = Canceled desc = context canceled", |
| 122 | + "interval": "5.125929689s" |
| 123 | +} |
| 124 | +``` |
| 125 | + |
| 126 | +shortly after receiving the instruction to shut down: |
| 127 | + |
| 128 | +```json |
| 129 | +{ |
| 130 | + "level": "info", |
| 131 | + "ts": 1736867468.4311068, |
| 132 | + "logger": "lifecycle.manager", |
| 133 | + "msg": "Received SHUTDOWN event" |
| 134 | +} |
| 135 | +``` |
| 136 | + |
| 137 | +The above indicates that the allocated resources of the lambda are not sufficient to allow execution of the lambda and the additional strain added by the OTEL instrumentation. To remedy this, the memory allocation and lambda timeout settings can be adjusted as necessary to allow the lambda to finish its work, while also allowing the telemetry collection to succeed. |
| 138 | + |
| 139 | +Try modifying the MemorySize and TimeOut properties of the lambdas that are failing: |
| 140 | + |
| 141 | +```yaml |
| 142 | +MemorySize: 256 |
| 143 | +Timeout: 25 |
| 144 | +``` |
| 145 | + |
| 146 | +Note the default memory allocation is 128MB |
| 147 | + |
| 148 | +Note the memory increment is 128MB |
| 149 | + |
| 150 | +Note Timeout is an integer value denoting seconds. |
| 151 | + |
| 152 | +### Authentication and Source IP Filtering |
| 153 | + |
| 154 | +If you encounter `error 403 Unauthorized` when submitting collector data to your cluster, or to any pre-processing or proxy collector, double-check the source IP address of the VPC NAT gateway matches what is whitelisted by the collector ingress, |
| 155 | +also double check that the chosen authentication mechanism matches source and destination, and also that credentials (secrets, etc.) are set up correctly. |
| 156 | + |
| 157 | +For more information about configuring authentication for the opentelemetry collector, please refer to the [official documentation](https://github.com/open-telemetry/opentelemetry-collector/blob/main/config/configauth/README.md). |
| 158 | + |
| 159 | +## References |
| 160 | + |
| 161 | +Auto-instrumentation docs → [https://opentelemetry.io/docs/faas/lambda-auto-instrument/](https://opentelemetry.io/docs/faas/lambda-auto-instrument/) |
| 162 | + |
| 163 | +Collector docs → [https://opentelemetry.io/docs/faas/lambda-collector/](https://opentelemetry.io/docs/faas/lambda-collector/) |
| 164 | + |
| 165 | +GitHub Releases Page for finding latest ARNs → [https://github.com/open-telemetry/opentelemetry-lambda/releases](https://github.com/open-telemetry/opentelemetry-lambda/releases) |
| 166 | + |
| 167 | +OTLP Exporter Configuration → [https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/](https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/) |
0 commit comments