# CloudWatch integration with X-Ray AWS X-Ray integrates with [CloudWatch Application Signals](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html), CloudWatch RUM, and CloudWatch Synthetics to make it easier to monitor the health of your applications. Enable your application for Application Signals to monitor and troubleshoot the operational health of your services, client pages, Synthetics canaries, and service dependencies. By correlating CloudWatch metrics, logs, and X-Ray traces, the X-Ray trace map provides an end-to-end view of your services to help you quickly pinpoint performance bottlenecks and identify impacted users. With CloudWatch RUM, you can perform real user monitoring to collect and view client-side data about your web application performance from actual user sessions in near-real time. With AWS X-Ray and CloudWatch RUM, you can analyze and debug the request path starting from end users of your application through downstream AWS managed services. This helps you identify latency trends and errors that impact your end users. **Topics** + [CloudWatch RUM and AWS X-Ray](xray-services-RUM.md) + [Debugging CloudWatch synthetics canaries using X-Ray](xray-services-cloudwatch-synthetics.md) # CloudWatch RUM and AWS X-Ray With Amazon CloudWatch RUM, you can perform real user monitoring to collect and view client-side data about your web application performance from actual user sessions in near-real time. With AWS X-Ray and CloudWatch RUM, you can analyze and debug the request path starting from end users of your application through downstream AWS managed services. This helps you identify latency trends and errors that impact your end users. After you turn on X-Ray tracing of user sessions, CloudWatch RUM adds an X-Ray trace header to allowed HTTP requests, and records an X-Ray segment for allowed HTTP requests. You can then see traces and segments from these user sessions in the X-Ray and CloudWatch consoles, including the X-Ray trace map. **Note** CloudWatch RUM doesn't integrate with X-Ray sampling rules. Instead, choose a sampling percentage when you set up your application to use CloudWatch RUM. Traces sent from CloudWatch RUM might incur additional costs. For more information, see [AWS X-Ray pricing](https://aws.amazon.com/xray/pricing/). By default, client-side traces sent from CloudWatch RUM aren't connected to server-side traces. To connect client-side traces with server-side traces, configure the CloudWatch RUM web client to add an X-Ray trace header to these HTTP requests. **Warning** Configuring the CloudWatch RUM web client to add an X-Ray trace header to HTTP requests can cause cross-origin resource sharing (CORS) to fail. To avoid this, add the `X-Amzn-Trace-Id` HTTP header to the list of allowed headers on your downstream service's CORS configuration. If you are using API Gateway as your downstream, see [Enabling CORS for a REST API resource](https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-cors.html). We strongly recommend that you test your application before adding a client-side X-Ray trace header in a production environment. For more information, see the [ CloudWatch RUM web client documentation](https://github.com/aws-observability/aws-rum-web/blob/main/docs/cdn_installation.md#http). For more information about real user monitoring in CloudWatch, see [Use CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html). To set up your application to use CloudWatch RUM, including tracing user sessions with X-Ray, see [Set up an application to use CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM-get-started.html). # Debugging CloudWatch synthetics canaries using X-Ray CloudWatch Synthetics is a fully managed service that enables you to monitor your endpoints and APIs using scripted canaries that run 24 hours per day, once per minute. You can customize canary scripts to check for changes in: + Availability + Latency + Transactions + Broken or dead links + Step-by-step task completions + Page load errors + Load Latencies for UI assets + Complex wizard flows + Checkout flows in your application Canaries follow the same routes and perform the same actions and behaviors as your customers, and continually verify the customer experience. To learn more about setting up Synthetics tests, see [Using Synthetics to Create and Manage Canaries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html). ![\[Example canary node in x-ray trace map.\]](http://docs.aws.amazon.com/xray/latest/devguide/images/synthetics-show-canary-active.png) The following examples show common use cases for debugging issues that your Synthetics canaries raise. Each example demonstrates a key strategy for debugging using either the trace map or the X-Ray Analytics console. For more information about how to read and interact with the trace map, see [Viewing the Service Map](https://docs.aws.amazon.com/xray/latest/devguide/xray-console.html#xray-console-servicemap). For more information about how to read and interact with the X-Ray Analytics console, see [Interacting with the AWS X-Ray Analytics Console](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-analytics.html). **Topics** + [View canaries with increased error reporting in the trace map](#xray-services-cloudwatch-synthetics-workflows-which-canary) + [Use trace details maps for individual traces to view each request in detail](#xray-services-cloudwatch-synthetics-workflows-trace-map) + [Determine the root cause of ongoing failures in upstream and downstream services](#xray-services-cloudwatch-synthetics-workflows-root-cause) + [Identify performance bottlenecks and trends](#xray-services-cloudwatch-synthetics-workflows-bottlenecks) + [Compare latency and error or fault rates before and after changes](#xray-services-cloudwatch-synthetics-workflows-latency) + [Determine the required canary coverage for all APIs and URLs](#xray-services-cloudwatch-synthetics-workflows-impact) + [Use groups to focus on synthetics tests](#xray-services-cloudwatch-synthetics-groups) ## View canaries with increased error reporting in the trace map To see which canaries have an increase in errors, faults, throttling rates, or slow response times within your X-Ray trace map, you can highlight Synthetics canary client nodes using the `Client::Synthetic` [filter](xray-console-filters.md). Clicking a node displays the response time distribution of the entire request. Clicking an edge between two nodes shows details about the requests that traveled that connection. You can also view "remote" inferred nodes for related downstream services in your trace map. When you click the Synthetics node, there is a **View in Synthetics** button on side panel which redirects you to the Synthetics console where you can check the canary details. ![\[Example canary node in x-ray trace map with service details.\]](http://docs.aws.amazon.com/xray/latest/devguide/images/synthetics-canary-servicedetail.png) ## Use trace details maps for individual traces to view each request in detail To determine which service results in the most latency or is causing an error, invoke the trace details map by selecting the trace in the trace map. Individual trace details maps display the end-to-end path of a single request. Use this to understand the services invoked, and visualize the upstream and downstream services. ![\[Example canary node in x-ray trace details map.\]](http://docs.aws.amazon.com/xray/latest/devguide/images/synthetics-canary-tracemap.png) ## Determine the root cause of ongoing failures in upstream and downstream services Once you receive a CloudWatch alarm for failures in a Synthetics canary, use the statistical modeling on trace data in X-Ray to determine the probable root cause of the issue within the X-Ray Analytics console. In the Analytics console, the **Response Time Root Cause** table shows recorded entity paths. X-Ray determines which path in your trace is the most likely cause for the response time. The format indicates a hierarchy of entities that are encountered, ending in a response time root cause. The following example shows that the Synthetics test for API “XXX” running on API Gateway is failing due to a throughput capacity exception from the Amazon DynamoDB table. ![\[Example canary node in x-ray trace map.\]](http://docs.aws.amazon.com/xray/latest/devguide/images/synthetics-canary-active-select.png) ![\[Example canary node root cause.\]](http://docs.aws.amazon.com/xray/latest/devguide/images/synthetics-canary-rootcause.png) ![\[Example annotation filter indicating the canary node.\]](http://docs.aws.amazon.com/xray/latest/devguide/images/synthetics-canary-showannot.png) ## Identify performance bottlenecks and trends You can view trends in the performance of your endpoint over time using continuous traffic from your Synthetics canaries to populate a trace details map over a period of time. ![\[Example annotation filter indicating the canary node.\]](http://docs.aws.amazon.com/xray/latest/devguide/images/synthetics-canary-distribution.png) ## Compare latency and error or fault rates before and after changes Pinpoint the time a change occurred to correlate that change to an increase in issues caught by your canaries. Use the X-Ray Analytics console to define the before and after time ranges as different trace sets, creating a visual differentiation in the response time distribution. ![\[Example annotation filter indicating the canary node.\]](http://docs.aws.amazon.com/xray/latest/devguide/images/synthetics-canary-compare.png) ## Determine the required canary coverage for all APIs and URLs Use X-Ray Analytics to compare the experience of canaries with the users. The UI below shows a blue trend line for canaries and a green line for the users. You can also identify that two out of the three URLs don’t have canary tests. ![\[Example annotation filter indicating the canary node.\]](http://docs.aws.amazon.com/xray/latest/devguide/images/synthetics-canary-vs-customer.png) ## Use groups to focus on synthetics tests You can create an X-Ray group using a filter expression to focus on a certain set of workflows, such as a Synthetics tests for application “www” running on AWS Elastic Beanstalk. Use the [complex keywords](xray-console-filters.md#console-filters-complex) `service()` and `edge()` to filter through services and edges. **Example Group filter expression** ``` "edge(id(name: "www", type: "client::Synthetics"), id(name: "www", type: "AWS::ElasticBeanstalk::Environment"))" ``` ![\[Example nodes for Elastic Beanstalk www.\]](http://docs.aws.amazon.com/xray/latest/devguide/images/synthetics-canary-active-www.png)