> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Serverless Connectors
> Explains Datadog Serverless Connectors for collecting metrics traces logs and profiles from serverless platforms plus instrumentation configuration and secure credential management
This lesson explains Datadog Serverless Connectors: how Datadog integrates with serverless platforms to collect telemetry (metrics, traces, logs, and profiles) from services that do not run on user-visible hosts. Serverless workloads are a central part of modern cloud-native architectures because of cost efficiency, automatic scaling, and simplified operations — but they require different instrumentation approaches than VMs or Kubernetes nodes.
Datadog offers native Serverless Connectors to monitor services such as Azure Functions, Azure App Service, Azure Container Instances, AWS Lambda and Step Functions, AWS Fargate, and Google Cloud Run. For full provider- and runtime-specific instructions, see the official Datadog Serverless documentation: [https://docs.datadoghq.com/serverless/](https://docs.datadoghq.com/serverless/).
## Why Serverless Instrumentation Is Different
Traditional Datadog agents run on hosts or within Kubernetes nodes. Serverless platforms hide the underlying compute, so you must instrument the application code (or attach provider-specific extensions/layers) to emit telemetry directly. Instrumentation varies by cloud provider and runtime; Datadog provides runtime libraries and optional extensions to simplify this work.
## Supported Platforms and Typical Use Cases
| Platform | Typical Datadog Integration | Example |
| ----------------------------: | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| AWS Lambda | Runtime library + optional Lambda extension or layer; CloudWatch Logs subscription or extension for logs | [https://docs.datadoghq.com/serverless/](https://docs.datadoghq.com/serverless/) |
| AWS Fargate | Datadog agent sidecar or built-in integration | [https://docs.datadoghq.com/integrations/](https://docs.datadoghq.com/integrations/) |
| Azure Functions / App Service | Datadog runtime libraries and Azure-specific extensions/integrations | [https://docs.datadoghq.com/serverless/](https://docs.datadoghq.com/serverless/) |
| Google Cloud Run | Runtime libraries + Logging/Trace integration with GCP | [https://docs.datadoghq.com/serverless/](https://docs.datadoghq.com/serverless/) |
| Azure Container Instances | Runtime libraries and Azure integrations | [https://docs.datadoghq.com/serverless/](https://docs.datadoghq.com/serverless/) |
## How Datadog Collects Telemetry from Serverless Functions
Using AWS Lambda as a concrete example helps illustrate the general pattern:
* The Datadog runtime library embedded in the function generates metrics, traces, and profiles.
* Where available, the Datadog Lambda extension or layer can forward those telemetry items more efficiently.
* Logs are typically forwarded from the provider's logging service (e.g., AWS CloudWatch). You can forward logs to Datadog via a CloudWatch Logs subscription, the Datadog CloudWatch integration, or — where supported — the Datadog Lambda extension that tails function logs and ships them directly.
The following diagram shows these flows for an AWS Lambda function: the Datadog library embedded in the function produces metrics/traces/profiles while logs move through CloudWatch or the Datadog extension to Datadog.
## Runtime Libraries
Datadog provides runtime libraries for six common runtimes:
* Python
* Java
* Go (Golang)
* Node.js
* Ruby
* .NET
Add the appropriate library to your function package and follow Datadog’s runtime-specific instrumentation guide for that language. Libraries capture telemetry and, depending on configuration and platform support, forward data via an extension or directly to Datadog’s site.
## Key Configuration Items
Common configuration settings you will need to set (usually via environment variables or a secrets manager):
* Datadog site (for example, `datadoghq.com`, `datadoghq.eu`)
* Datadog API key (authentication/authorization)
* Service name, environment, and version tags (for proper correlation in traces and dashboards)
Never hardcode API keys in source control or commit them to repositories. Use secrets management solutions to inject credentials at runtime.
Do not hardcode API keys in production. Use environment variables populated from a secrets manager or the platform's secure configuration mechanisms to keep credentials safe.
When forwarding logs via CloudWatch or other provider pipelines, ensure the function has the required IAM permissions and that you understand potential cost and retention impacts from log ingestion. Consider sampling and filtering to limit high-cardinality data.
## Example: Read Datadog Configuration from Environment Variables (Python)
This minimal Python snippet demonstrates reading configuration from environment variables instead of hardcoding the API key:
```python theme={null}
import os
from datadog import initialize, statsd
options = {
"api_key": os.environ.get("DD_API_KEY"),
"site": os.environ.get("DD_SITE", "datadoghq.com")
}
initialize(**options)
# Send a simple metric
statsd.increment("my_lambda.invocations")
```
Best practices:
* Store `DD_API_KEY` and other secrets in a secrets manager or encrypted store.
* Use platform-native mechanisms to inject secrets into environment variables (e.g., AWS Secrets Manager, AWS KMS, Azure Key Vault, GCP Secret Manager).
## Instrumentation Checklist (Quick Start)
| Step | Action |
| ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1 | Choose the appropriate Datadog runtime library and any required extension/layer for your platform and runtime. |
| 2 | Add the library/layer to your function/package and follow the runtime-specific instrumentation guide. |
| 3 | Configure the Datadog site and credentials via environment variables or your provider's secret mechanism. |
| 4 | Enable and configure the provider logging integration (e.g., CloudWatch Logs subscription) or use the Datadog extension where available to forward logs. |
| 5 | Verify that metrics, traces, logs, and profiles appear in the Datadog UI and dashboards. |
## Validation and Troubleshooting
* Confirm environment variables are present in deployed functions and not printed in logs.
* Check the Datadog UI for incoming metrics and traces; use logs to debug missing instrumentation.
* Validate CloudWatch Logs subscriptions or extension logs for any forwarding errors.
* Use sampling and rate limits to avoid excessive ingestion costs.
## Links and References
* Datadog Serverless: [https://docs.datadoghq.com/serverless/](https://docs.datadoghq.com/serverless/)
* Datadog CloudWatch integration: [https://docs.datadoghq.com/integrations/amazon\_cloudwatch/](https://docs.datadoghq.com/integrations/amazon_cloudwatch/)
* AWS KMS: [https://aws.amazon.com/kms/](https://aws.amazon.com/kms/)
* AWS Secrets Manager: [https://aws.amazon.com/secrets-manager/](https://aws.amazon.com/secrets-manager/)
* HashiCorp Vault: [https://www.vaultproject.io/](https://www.vaultproject.io/)
That's it for this lesson — you should now understand how Datadog Serverless Connectors collect telemetry from serverless platforms, the common configuration patterns, and the recommended security practices for handling credentials.