# Query metrics from other data sources You can use CloudWatch to query, visualize, and create alarms for metrics from other data sources. To do so, you connect CloudWatch to the other data sources. This gives you a single, consolidated monitoring experience within the CloudWatch console. You can have a unified view of your infrastructure and application metrics regardless of where the data is stored, helping you identify and resolve issues faster. After you connect to a data source using a CloudWatch wizard, CloudWatch creates an AWS CloudFormation stack that deploys and configures an AWS Lambda function. This Lambda function runs on demand every time you query the data source. The CloudWatch query builder shows you in real time a list of elements that can be queried, such as metrics, tables, fields, or labels. As you make choices, the query builder pre-populates a query in the native language of the selected source. CloudWatch provides guided wizards for you to connect to the following data sources. For these data sources, you provide basic information to identify the data source and credentials. You can also manually create connectors to other data sources by creating your own Lambda functions. + Amazon OpenSearch Service– Derive metrics from your OpenSearch Service logs and traces. + Amazon Managed Service for Prometheus– Query these metrics using PromQL. + Amazon RDS for MySQL – Use SQL to convert data stored in your Amazon RDS tables into metrics. + Amazon RDS for PostgreSQL– Use SQL to convert data stored in your Amazon RDS tables into metrics. + Amazon S3 CSV files– Display metrics data from a CSV file stored in an Amazon S3 bucket. + Microsoft Azure Monitor– Query metrics from your Microsoft Azure Monitor account. + Prometheus– Query these metrics using PromQL. After you create connectors to data sources, see [Creating a graph of metrics from another data source](graph_a_metric.md#create-metric-graph-multidatasource) for information about graphing a metric from a data source. For information about setting an alarm on a metric from a data source, see [Create an alarm based on a connected data source](Create_MultiSource_Alarm.md). **Topics** + [ # Managing access to data sources ](CloudWatch_MultiDataSources_Permissions.md) + [ # Connect to a prebuilt data source with a wizard ](CloudWatch_MultiDataSources-Connect.md) + [ # Create a custom connector to a data source ](CloudWatch_MultiDataSources-Connect-Custom.md) + [ # Use your custom data source ](CloudWatch_MultiDataSources-Custom-Use.md) + [ # Delete a connector to a data source ](CloudWatch_MultiDataSources-Delete.md) # Managing access to data sources CloudWatch uses CloudFormation to create the required resources in your account. We recommend that you use the `cloudformation:TemplateUrl` condition to control access to CloudFormation templates when you grant `CreateStack` permissions to IAM users. **Warning** Any user that you grant data source invoke permission to can query metrics from that data source even if that user does not have direct IAM permissions to the data source. For example, if you grant `lambda:InvokeFunction` permissions on a Amazon Managed Service for Prometheus data source Lambda function to a user, that user will be able to query metrics from the corresponding Amazon Managed Service for Prometheus workspace even if you didn't grant them direct IAM access to that workspace. You can find template URLs for data sources on the **Create stack** page in the CloudWatch Settings Console. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowCloudFormationCreateStack", "Effect": "Allow", "Action": [ "cloudformation:CreateStack" ], "Resource": "*", "Condition": { "StringEquals": { "cloudformation:TemplateUrl": [ "https://s3.us-east-1.amazonaws.com/amzn-s3-demo-bucket/template.json" ] } } } ] } ``` ------ For more information about controlling CloudFormation access, see [Controlling access with AWS Identity and Access Management](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html) # Connect to a prebuilt data source with a wizard This topic provides instructions for using the wizard to connect CloudWatch to the following data sources. + Amazon OpenSearch Service + Amazon Managed Service for Prometheus + Amazon RDS for MySQL + Amazon RDS for PostgreSQL + Amazon S3 CSV files + Microsoft Azure Monitor + Prometheus The subsections in this topic include notes about managing and querying with each of these data sources. **To create a connector to a data source** 1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. In the navigation pane, choose **Settings**. 1. Choose the **Metrics data sources** tab. 1. Choose **Create data source**. 1. Select the source that you want, then choose **Next**. 1. Enter a name for the data source. 1. Enter the other required information, depending on the data source that you chose. This can include credentials to access the data source and data source identifying information such as Prometheus workspace name, database name, or Amazon S3 bucket name. For AWS services, the wizard discovers the resources and populates them into the selection dropdown. For more notes about the data source you are using, see the sections after this procedure. 1. To have CloudWatch connect to the data source in a VPC, choose **Use a VPC** and select the VPC to use. Then select the subnet and security group. 1. Choose **I acknowledge that CloudFormation will create IAM resources**. This resource is the Lambda function execution role. 1. Choose **Create data source**. The new source that you just added doesn't appear until the CloudFormation stack is done creating it. To check progress, you can choose **View the status of my CloudFormation stack**. Or you can choose the refresh icon to update this list. When your new data source appears in this list, it is ready to use. You can choose **Query from CloudWatch metrics** to begin querying with it. For more information, see [Creating a graph of metrics from another data source](graph_a_metric.md#create-metric-graph-multidatasource). ## Amazon Managed Service for Prometheus **Updating the data source configuration** + You can update your data source manually by doing the following: + To update the Amazon Managed Service for Prometheus workspace ID, update the `AMAZON_PROMETHEUS_WORKSPACE_ID` environment variable for the data source connector Lambda function. + To update the VPC configuration, see [Configuring VPC access (console)](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html#vpc-configuring) for more information. **Querying the data source** + When querying Amazon Managed Service for Prometheus, after you select the data source in the **Multi source query** tab and select an Amazon Managed Service for Prometheus connector, you can use the **Query helper** to discover metrics and labels and provide simple PromQL queries. You can also use the PromQL query editor to build a PromQL query. + Multi-line queries are not supported by the CloudWatch data source connectors. Every line feed is replaced with a space when the query is executed, or when you create an alarm or a dashboard widget with the query. In some cases, this might make your query not valid. For example, if your query contains a single line comment it will not be valid. If you try to create a dashboard or alarm with a multi-line query from the command line or Infrastructure as Code, the API will reject the action with a parse error. ## Amazon OpenSearch Service **Creating the data source** If the OpenSearch domain is enabled for FGAC, you must map the execution role of the connector Lambda function to a user in OpenSearch Service. For more information, see the **Mapping users to roles** section in [Managing permissions ](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.html#fgac-access-control) in the OpenSearch Service documentation. If your OpenSearch domain is only accessible within a Virtual Private Cloud (VPC), you need to manually include a new environment variable in the Lambda function called `AMAZON_OPENSEARCH_ENDPOINT`. The value for this variable should be the root domain of the OpenSearch endpoint. You can obtain this root domain by removing `https://` and `.es.amazonaws.com` from the domain endpoint listed in the OpenSearch Service console. For example, if your domain endpoint is `https://sample-domain.us-east-1.es.amazonaws.com`, the root domain would be `sample-domain`. **Updating the data source** + You can update your data source manually by doing the following: + To update the OpenSearch Service domain, update the `AMAZON_OPENSEARCH_DOMAIN_NAME` environment variable for the data source connector Lambda function. + To update the VPC configuration, see [Configuring VPC access (console)](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html#vpc-configuring) for more information. **Querying the data source** + When querying OpenSearch Service, after you select the data source in the **Multi source query** tab, do the following: + Select the Index to query. + Select the Metric name (Any numeric field in the document) and Stat. + Select the Time axis (Any date field in the document). + Select Filters to apply (Any String field in the document). + Choose **Graph query**. ## Amazon RDS for PostgreSQL and Amazon RDS for MySQL **Creating the data source** + If your data source is only accessible in a VPC, you must include the VPC configuration for the connector, as described in [Connect to a prebuilt data source with a wizard](#CloudWatch_MultiDataSources-Connect). If the data source is to connect to the VPC for credentials, the endpoint must be configured in the VPC. For more information, see [Using an AWS Secrets Manager VPC endpoint](https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html). Additionally, you must create a VPC endpoint for the Amazon RDS service. For more information, see [Amazon RDS API and interface VPC endpoints (AWS PrivateLink)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/vpc-interface-endpoints.html). **Updating the data source** + You can update your data source manually by doing the following: + To update the database instance, update the `RDS_INSTANCE` environment variable for the data source connector Lambda function. + To update the username and password used to connect to Amazon RDS, use AWS Secrets Manager. You can find the ARN of the secret used for the data source in the environment variable `RDS_SECRET` on the data source Lambda function. For more information about updating the secret in AWS Secrets Manager, see [Modify an AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_update-secret.html). + To update the VPC configuration, see [Configuring VPC access (console)](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html#vpc-configuring) for more information. **Querying the data source** + When querying Amazon RDS, after you select the data source in the **Multi source query** tab and select an Amazon RDS connector, you can use the database discoverer to view available databases, tables, and columns. You can also use the SQL editor to create an SQL query. You can use the following variables in the query: + `$start.iso` – The start time in ISO date format + `$end.iso` – The end time in ISO date format + `$period` – The selected period in seconds For example, you can query `SELECT value, timestamp FROM table WHERE timestamp BETWEEN $start.iso and $end.iso` + Multi-line queries are not supported by the CloudWatch data source connectors. Every line feed is replaced with a space when the query is executed, or when you create an alarm or a dashboard widget with the query. In some cases, this might make your query not valid. For example, if your query contains a single line comment it will not be valid. If you try to create a dashboard or alarm with a multi-line query from the command line or Infrastructure as Code, the API will reject the action with a parse error. **Note** If no date field is found in the results, the values for each numeric field are summed to single values and plotted across the provided time range. If the timestamps don't align with the selected period in CloudWatch, the data is automatically aggregated using `SUM` and aligned with the period in CloudWatch. ## Amazon S3 CSV files **Querying the data source** + When querying Amazon S3 CSV files, after you select the data source in the **Multi source query** tab and select an Amazon S3 connector, you select the Amazon S3 bucket and key. The CSV file must be formatted in the following ways: + The time stamp must be the first column. + The table must have a header row. The headers are used to name your metrics. The title of the time stamp column will be ignored, only the titles of the metrics columns are used. + The time stamps must be in ISO date format. + The metrics must be numeric fields. ``` Timestamp, Metric-1, Metric-2, ... ``` The following is an example: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_MultiDataSources-Connect.html) **Note** If no timestamp is provided, the values for each metric are summed to single values and plotted across the provided time range. If the timestamps don't align with the selected period in CloudWatch, the data is automatically aggregated using `SUM` and aligned with the period in CloudWatch. ## Microsoft Azure Monitor **Creating the data source** + You must provide your tenant ID, client ID, and client secret to connect to Microsoft Azure Monitor. The credentials will be stored in AWS Secrets Manager. For more information, see [Create a Microsoft Entra application and service principal that can access resources](https://learn.microsoft.com/en-us/entra/identity-platform/howto-create-service-principal-portal) in the Microsoft documentation. **Updating the data source** + You can update your data source manually by doing the following: + To update the tenant ID, client ID, and client secret used to connect to Azure Monitor, you can find the ARN of the secret used for the data source as the `AZURE_CLIENT_SECRET` environment variable on the data source Lambda function. For more information about updating the secret in AWS Secrets Manager, see [Modify an AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_update-secret.html). **Querying the data source** + When querying Azure Monitor, after you select the data source in the **Multi source query** tab and select an Azure Monitor connector, you specify the Azure subscription, and the resource group and resource. You can then select the metric namespace, metric, and aggregation, and filter by dimensions. ## Prometheus **Creating the data source** + You must provide the Prometheus endpoint and the user and password required to query Prometheus. The credentials will be stored in AWS Secrets Manager. + If your data source is only accessible in a VPC, you must include the VPC configuration for the connector, as described in [Connect to a prebuilt data source with a wizard](#CloudWatch_MultiDataSources-Connect). If the data source is to connect to for credentials, the endpoint must be configured in the VPC. For more information, see [Using an AWS Secrets Manager VPC endpoint](https://docs.aws.amazon.com/secretsmanager/latest/userguide/vpc-endpoint-overview.html). **Updating data source configuration** + You can update your data source manually by doing the following: + To update the Prometheus endpoint, specify the new endpoint as the `PROMETHEUS_API_ENDPOINT` environment variable on the data source Lambda function. + To update the username and password used to connect to Prometheus, you can find the ARN of the secret used for the data source as the `PROMETHEUS_API_SECRET` environment variable on the data source Lambda function. For more information about updating the secret in AWS Secrets Manager, see [Modify an AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_update-secret.html). + To update the VPC configuration, see [Configuring VPC access (console)](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html#vpc-configuring) for more information. **Querying the data source** **Important** Prometheus metric types are different than CloudWatch metrics and many metrics available through Prometheus are cumulative by design. When you query Prometheus metrics, CloudWatch doesn't apply any additional transformation to the data: if you specify only the metric name or label, the displayed value will be cumulative. For more information, see [ Metric types](https://prometheus.io/docs/concepts/metric_types/) in the Prometheus documentation. To see Prometheus metrics data as discrete values, like CloudWatch metrics, you need to edit the query before you run it. For example, you might need to add a call to the rate function over your Prometheus metric name. For documentation about the rate function and other Prometheus functions, see [rate()](https://prometheus.io/docs/prometheus/latest/querying/functions/#rate) in the Prometheus documentation. Multi-line queries are not supported by the CloudWatch data source connectors. Every line feed is replaced with a space when the query is executed, or when you create an alarm or a dashboard widget with the query. In some cases, this might make your query not valid. For example, if your query contains a single line comment it will not be valid. If you try to create a dashboard or alarm with a multi-line query from the command line or Infrastructure as Code, the API will reject the action with a parse error. ## Notification of Available Updates From time to time, Amazon might notify you that we recommend that you update your connectors with a newer available version and will provide instructions for how to do so. # Create a custom connector to a data source This topic describes how to connect a custom data source to CloudWatch. You can connect a custom data source to CloudWatch in two ways: + Using a sample template that CloudWatch provides. You can use either JavaScript or Python with this template. These templates include sample Lambda code that will be useful to you when you create your Lambda function. You can then modify the Lambda function from the template to connect to your custom data source. + Creating an AWS Lambda function from scratch that implements the data source connector, the data query, and the preparation of the time series for use by CloudWatch. This function must pre-aggregate or merge datapoints if needed, and also align the period and timestamps to be compatible with CloudWatch. **Contents** + [ ## Use a template ](#CloudWatch_MultiDataSources-Connect-Custom-template) + [ ## Create a custom data source from scratch ](#CloudWatch_MultiDataSources-Connect-Custom-Lambda) + [ ### Step 1: Create the function ](#MultiDataSources-Connect-Custom-Lambda-Function) + [ #### GetMetricData event ](#MultiDataSources-GetMetricData) + [ #### DescribeGetMetricData event ](#MultiDataSources-DescribeGetMetricData) + [ #### Important considerations for CloudWatch alarms ](#MultiDataSources-Connect-Custom-Lambda-Alarms) + [ #### (Optional) Use AWS Secrets Manager to store credentials ](#MultiDataSources-Connect-Custom-Lambda-Secrets) + [ #### (Optional) Connect to a data source in a VPC ](#MultiDataSources-Connect-Custom-Lambda-VPC) + [ ### Step 2: Create a Lambda permissions policy ](#MultiDataSources-Connect-Custom-Lambda-Permissions) + [ ### Step 3: Attach a resource tag to the Lambda function ](#MultiDataSources-Connect-Custom-Lambda-tags) ## Use a template Using a template creates a sample Lambda function, and can help you get your custom connector built faster. These sample functions provide sample code for many common scenarios involved with building a custom connector. You can examine the Lambda code after you create a connector with a template, then modify it to use to connect to your data source. Additionally, if you use the template, CloudWatch takes care of creating the Lambda permissions policy and attaching resource tags to the Lambda function. **To use the template to create a connector to a custom data source** 1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. In the navigation pane, choose **Settings**. 1. Choose the **Metrics data sources** tab. 1. Choose **Create data source**. 1. Choose the radio button for **Custom - getting started template** and then choose **Next**. 1. Enter a name for the data source. 1. Select the one of the listed templates. 1. Select either Node.js or Python. 1. Choose **Create data source**. The new custom source that you just added doesn't appear until the CloudFormation stack finishes creating it. To check progress, you can choose **View the status of my CloudFormation stack**. Or you can choose the refresh icon to update this list. When your new data source appears in this list, it is ready for you to test in the console and modify. 1. (Optional) To query the test data from this source in the console, follow the instructions in [Creating a graph of metrics from another data source](graph_a_metric.md#create-metric-graph-multidatasource). 1. Modify the Lambda function for your needs. 1. In the navigation pane, choose **Settings**. 1. Choose the **Metrics data sources** tab. 1. Choose **View in Lambda console** for the source that you want to modify. You can now modify the function to access your data source. For more information, see [Step 1: Create the function](#MultiDataSources-Connect-Custom-Lambda-Function). **Note** By using the template, when you write your Lambda function you don't need to follow the instructions in [Step 2: Create a Lambda permissions policy](#MultiDataSources-Connect-Custom-Lambda-Permissions) or [Step 3: Attach a resource tag to the Lambda function](#MultiDataSources-Connect-Custom-Lambda-tags). These steps were performed by CloudWatch because you used the template. ## Create a custom data source from scratch Follow the steps in this section to create a Lambda function that connects CloudWatch to a data source. ### Step 1: Create the function A custom data source connector must support `GetMetricData` events from CloudWatch. Optionally, you can also implement a `DescribeGetMetricData` event to provide documentation to users in the CloudWatch console for how to use the connector. The `DescribeGetMetricData` response can also be used to set defaults that are used in the CloudWatch custom query builder. CloudWatch provides code snippets as samples to help you get started. For more information, see the samples repository at [https://github.com/aws-samples/cloudwatch-data-source-samples](https://github.com/aws-samples/cloudwatch-data-source-samples). **Constraints** + The response from Lambda must be smaller than 6 Mb. If the response exceeds 6 Mb, the `GetMetricData` response marks the Lambda function as `InternalError` and no data is returned. + The Lambda function must complete its execution within 10 seconds for visualization and dashboarding purposes, or within 4.5 seconds for alarms usage. If the execution time exceeds that time, the `GetMetricData` response marks the Lambda function as `InternalError` and no data is returned. + The Lambda function must send its output using epoch timestamps in seconds. + If the Lambda function doesn't resample the data and instead returns data that doesn't correspond to the start time and period length that was requested by the CloudWatch user, that data is ignored by CloudWatch. The extra data is discarded from any visualization or alarming. Any data that is not between the start time and end time is also discarded. For example, if a user asks for data from 10:00 to 11:00 with a period of 5 min, then "10:00:00 to 10:04:59" and "10:05:00 to 10:09:59" are the valid time ranges for data to be returned. You must return a time series that includes `10:00 value1`, `10:05 value2`, and so on. If the function returns `10:03 valueX`, for example, it gets dropped because 10:03 does not correspond to the requested start time and period. + Multi-line queries are not supported by the CloudWatch data source connectors. Every line feed is replaced with a space when the query is executed, or when you create an alarm or a dashboard widget with the query. In some cases, this might make your query not valid. #### GetMetricData event **Request payload** The following is an example of a `GetMetricData` request payload sent as input to the Lambda function. ``` { "EventType": "GetMetricData", "GetMetricDataRequest": { "StartTime": 1697060700, "EndTime": 1697061600, "Period": 300, "Arguments": ["serviceregistry_external_http_requests{host_cluster!=\"prod\"}"] } } ``` + **StartTime**– The timestamp specifying the earliest data to return. The **Type** is timestamp epoch seconds. + **EndTime**– The timestamp specifying the latest data to return. The **Type** is timestamp epoch seconds. + **Period**– The number of seconds that each aggregation of the metrics data represents. The minimum is 60 seconds. The **Type** is Seconds. + **Arguments**– An array of arguments to pass to the Lambda metric math expression. For more information about passing arguments, see [How to pass arguments to your Lambda function](CloudWatch_MultiDataSources-Custom-Use.md#MultiDataSources-Connect-Custom-Lambda-arguments). **Response payload** The following is an example of a `GetMetricData` response payload returned by the Lambda function. ``` { "MetricDataResults": [ { "StatusCode": "Complete", "Label": "CPUUtilization", "Timestamps": [ 1697060700, 1697061000, 1697061300 ], "Values": [ 15000, 14000, 16000 ] } ] } ``` The response payload will contain either a `MetricDataResults` field or an `Error` field, but not both. A `MetricDataResults` field is a list of time-series fields of type `MetricDataResult`. Each of those time-series fields can include the following fields. + **StatusCode**– (Optional) `Complete` indicates that all data points in the requested time range were returned. `PartialData` means that an incomplete set of data points were returned. If this is omitted, the default is `Complete`. Valid Values: `Complete` \$1 `InternalError` \$1 `PartialData` \$1 `Forbidden` + **Messages**– Optional list of messages with additional information about the data returned. Type: Array of [MessageData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MessageData.html) objects with `Code` and `Value` strings. + **Label**– The human-readable label associated with the data. Type: String + **Timestamps**– The timestamps for the data points, formatted in epoch time. The number of timestamps always matches the number of values and the value for `Timestamps[x]` is `Values[x`]. Type: Array of timestamps + **Values**– The data point values for the metric, corresponding to `Timestamps`. The number of values always matches the number of timestamps and the value for `Timestamps[x]` is `Values[x`]. Type: Array of doubles For more information about `Error` objects, see the following sections. **Error response formats** You can optionally use the error response to provide more information about errors. We recommend that you return an error with Code Validation when a validation error occurs, such as when a parameter is missing or is the wrong type. The following is an example of the response when the Lambda function wants to raise a `GetMetricData` validation exception. ``` { "Error": { "Code": "Validation", "Value": "Invalid Prometheus cluster" } } ``` The following is an example of the response when the Lambda function indicates that it's unable to return data because of an access issue. The response is translated into a single time series with a status code of `Forbidden`. ``` { "Error": { "Code": "Forbidden", "Value": "Unable to access ..." } } ``` The following is an example of when the Lambda function raises an overall `InternalError` exception, which is translated into a single time series with a status code of `InternalError` and a message. Whenever an error code has a value other than `Validation` or `Forbidden`, CloudWatch assumes that it's a generic internal error. ``` { "Error": { "Code": "PrometheusClusterUnreachable", "Value": "Unable to communicate with the cluster" } } ``` #### DescribeGetMetricData event **Request payload** The following is an example of a `DescribeGetMetricData` request payload. ``` { "EventType": "DescribeGetMetricData" } ``` **Response payload** The following is an example of a `DescribeGetMetricData` response payload. ``` { "Description": "Data source connector", "ArgumentDefaults": [{ Value: "default value" }] } ``` + **Description**– A description of how to use the data source connector. This description will appear in the CloudWatch console. Markdown is supported. Type: String + **ArgumentDefaults**– Optional array of argument default values used pre-populate the custom data source builder. If `[{ Value: "default value 1"}, { Value: 10}]`, is returned, the query builder in the CloudWatch console displays two inputs, the first with “default value 1” and the second with 10. If `ArgumentDefaults` is not provided, a single input is displayed with type default set to `String`. Type: Array of objects containing Value and Type. + **Error**– (Optional) An error field can be included in any response. You can see examples in [GetMetricData event](#MultiDataSources-GetMetricData). #### Important considerations for CloudWatch alarms If you are going to use the data source to set CloudWatch alarms, you should set it up to report data with timestamps every minute to CloudWatch. For more information and other considerations for creating alarms on metrics from connected data sources, see [Create an alarm based on a connected data source](Create_MultiSource_Alarm.md). #### (Optional) Use AWS Secrets Manager to store credentials If your Lambda function needs to use credentials to access the data source, we recommend using AWS Secrets Manager to store these credentials instead of hardcoding them into your Lambda function. For more information about using AWS Secrets Manager with Lambda, see [Use AWS Secrets Manager secrets in AWS Lambda functions](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_lambda.html). #### (Optional) Connect to a data source in a VPC If your data source is in a VPC managed by Amazon Virtual Private Cloud, you must configure your Lambda function to access it. For more information, see [Connecting outbound networking to resources in a VPC](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html). You might also need to configure VPC service endpoints to access services such as AWS Secrets Manager. For more information, see [Access an AWS service using an interface VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#access-service-though-endpoint). ### Step 2: Create a Lambda permissions policy You must use create a policy statement that grants CloudWatch permission to use the Lambda function that you created. You can use the AWS CLI or the Lambda console to create the policy statement. **To use the AWS CLI to create the policy statement** + Enter the following command. Replace *123456789012* with your account ID, replace *my-data-source-function* with the name of your Lambda function, and replace *MyDataSource-DataSourcePermission1234* with an arbitrary unique value. ``` aws lambda add-permission --function-name my-data-source-function --statement-id MyDataSource-DataSourcePermission1234 --action lambda:InvokeFunction --principal lambda.datasource.cloudwatch.amazonaws.com --source-account 123456789012 ``` ### Step 3: Attach a resource tag to the Lambda function The CloudWatch console determines which of your Lambda functions are data source connectors by using a tag. When you create a data source using one of the wizards, the tag is automatically applied by the CloudFormation stack that configures it. When you create a data source yourself, you can use the following tag for your Lambda function. This makes your connector appear in the **Data source** dropdown in the CloudWatch console when you query metrics. + A tag with `cloudwatch:datasource` as the key and `custom` as the value. # Use your custom data source After you create a data source, you can use it to query and visualize data from that source, as well as to set alarms. If you used a template to create your custom data source connector or you added the tag listed in [Step 3: Attach a resource tag to the Lambda function](CloudWatch_MultiDataSources-Connect-Custom.md#MultiDataSources-Connect-Custom-Lambda-tags), you can follow the steps in [Creating a graph of metrics from another data source](graph_a_metric.md#create-metric-graph-multidatasource) to query it. You can also use the metric math function `LAMBDA` to query it, as explained in the following section. For information about creating alarms on metrics from your data source, see [Create an alarm based on a connected data source](Create_MultiSource_Alarm.md). This topic describes how to pass arguments to your Lambda function to your custom data source. ## How to pass arguments to your Lambda function The recommended way for you to pass arguments to your custom data source is to use the query builder in the CloudWatch console when you query the data source. You can also use your Lambda function to retrieve data from your data source by using the new `LAMBDA` expression in CloudWatch metric math. ``` LAMBDA("LambdaFunctionName" [, optional-arg]*) ``` `optional-arg` is up to 20 strings, numbers, or Booleans. For example, `param`, `3.14`, or `true`. **Note** Multi-line strings are not supported by the CloudWatch data source connectors. Every line feed is replaced with a space when the query is executed, or when you create an alarm or a dashboard widget with the query. In some cases, this might make your query not valid. When you use the `LAMBDA` metric math function, you can provide the function name (`"MyFunction"`). If your resource policy allows, you can also use a specific version of the function (`"MyFunction:22"`), or a Lambda function alias (`"MyFunction:MyAlias"`). You can't use `*` The following are some examples of calling the `LAMBDA` function. ``` LAMBDA("AmazonOpenSearchDataSource", "MyDomain", "some-query") ``` ``` LAMBDA("MyCustomDataSource", true, "fuzzy", 99.9) ``` The `LAMBDA` metric math function returns a list of time series that can be returned to the requester or combined with other metric math functions. The following is an example of combining `LAMBDA` with other metric math functions. ``` FILL(LAMBDA("AmazonOpenSearchDataSource", "MyDomain", "some-query"), 0) ``` # Delete a connector to a data source The instructions in this section describe how to delete a connector to a data source. **To delete a connector to a data source** 1. Open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. In the navigation pane, choose **Settings**. 1. Choose the **Metrics data sources** tab. 1. Choose **Manage in CloudFormation** in the row of the data source that you want to delete. You are taken to the CloudFormation console. 1. In the section with the name of your data source, choose **Delete**. 1. In the confirmation pop-up, choose **Delete**.