Monitor the operational health of your applications with Application Signals - Amazon CloudWatch

Monitor the operational health of your applications with Application Signals

Use Application Signals within the CloudWatch console to monitor and troubleshoot the operational health of your applications:

  • Monitor your application services — As part of daily operational monitoring, use the Services page to see a summary of all your services. See services with the highest fault rate or latency, and see which services have unhealthy service level indicators (SLIs). Select a service to open the Service detail page and see detailed metrics, service operations, Synthetics canaries, and client requests. This can help you troubleshoot and identify the root cause of operational issues.

  • Inspect your application topology — Use the Service Map to understand and monitor your application topology over time, including the relationships between clients, Synthetics canaries, services, and dependencies. Instantly see service level indicator (SLI) health and view key metrics such as call volume, fault rate, and latency. Drill down to see more detailed information in the Service detail page.

Explore an example scenario that demonstrates how these pages can be used to quickly troubleshoot an operational service health issue, from initial detection to identifying root cause.

How Application Signals enables operational health monitoring

After you enable your application for Application Signals, your application services, APIs, and their dependencies are automatically discovered and displayed in the Services, Service detail, and Service Map pages. Application Signals collects information from multiple sources to enable service discovery and operational health monitoring:

  • AWS Distro for OpenTelemetry (ADOT) — As part of enabling Application Signals, OpenTelemetry Java and Python auto-instrumentation libraries are configured to emit metrics and traces that are collected by the CloudWatch agent. The metrics and traces are used to enable discovery of services, operations, dependencies, and other service information.

  • Service-level objectives (SLOs) — After you create service level objectives for your services, the Services, Service detail, and Service Map pages display service level indicator (SLI) health. SLIs can monitor latency, availability, and other operational metrics.

  • CloudWatch Synthetics canaries — When you configure X-Ray tracing on your canaries, calls to your services from your canary scripts are associated with your service and displayed within the Service detail page.

  • CloudWatch Real user monitoring (RUM) — When X-Ray tracing is enabled on your CloudWatch RUM web client, requests to your services are automatically associated and displayed within the service detail page.

  • AWS Service Catalog AppRegistry — Application Signals auto-discovers AWS resources within your account and allows you to group them into logical applications created in AppRegistry. The application name displayed in the Services page is based on the underlying compute resource that your services are running on.

Note

Application Signals displays your services and operations based on metrics and traces emitted within the current time filter that you chose. (By default, this is the past three hours.) If there is no activity within the current time filter for a service, operation, dependency, Synthetics canary, or client page, it won't be displayed.

Currently, up to 1,000 services can be displayed. Discovery of your services and service topology might be delayed up to 10 minutes. Evaluation of your service level indicator (SLI) health might be delayed up to 15 minutes.