Announcing five new capabilities in application performance monitoring (APM) in Amazon CloudWatch Application Signals

4 minute read
Content level: Intermediate

announce 5 new capabilities in application performance monitoring (APM) in Amazon CloudWatch Application Signals

We are thrilled to announce 5 new capabilities in application performance monitoring (APM) in Amazon CloudWatch Application Signals - making it simpler to get started, supporting Python language for APM, and much more. Please see below for a quick summary of the new capabilities, available in all AWS Regions where Application Signals is available in Public Preview.

  1. Monitor Python services using Application Signals: CloudWatch Application Signals expands support for Python applications to auto-collect essential application golden signals (latency, throughput, errors/faults, availability) and traces via OpenTelemetry-based auto-instrumentation. Whether your Python applications are hosted in Amazon EKS, EC2, on-premise, or ECS, you can leverage application signals to gain valuable insights into their performance.Learn more about Python Support.
  2. ** Monitor Amazon EKS Workloads via Console in a few clicks: **We're thrilled to announce that you can now easily enable application performance monitoring for your workloads hosted in Amazon EKS directly from the AWS console, with no need to modify your code base. The console option provides a straightforward way to kickstart application monitoring in just a few clicks, allowing you to conveniently activate monitoring from a centralized page on CloudWatch Application Signals. With this offering, you now have two options to enable Application Signals: the streamlined console option for quick setup, or by annotating manifest files of your workloads. Get started by visiting the "Enable CloudWatch Application Signals" in CloudWatch, or see the updated documentation for EKS to learn more.
  3. Automatic Application logs and top contributor metrics: We're now making it easier to understand the root cause of performance anomalies by automatically correlating application logs, along with key performance metrics broken down by infrastructure components such as nodes, pods. With this new information, directly alongside correlated traces, you can spot if elevated, latency, faults or errors are isolated to an individual node/pod/instance, and can quickly navigate to individual traces to continue troubleshooting. You can learn more about these new integrated features in the documentation here.
  4. **New Service Summary dashboard: **The new Service Overview tab in Application signals provides  a central dashboard that offers a comprehensive view of the health and performance for your service. At glance you will be able to see the number of operations by SLI health, dependencies contributing to faults, Synthetic canaries testing your service with their success rate, and client pages experiencing high error rates. With the new latency, volume of requests, faults and errors graphs you can see a summary of the performance pf your service across all operations in a single view, as well as quickly identify top operations or dependencies contributing to higher latency, volume of requests, or changes in overall service availability. For more information on the new Service overview dashboard, please see the updated documentation for viewing Service health.
  5. Managing High Cardinality Operations: Ensuring effective monitoring of your applications in CloudWatch Application Signals just got easier with automated protection against high-cardinality operations. Due to misconfiguration, some applications may inadvertently generate metrics tracking individual user IDs, such as "/api/user/1214" or "/api/user/54545," instead of tracking parameterized paths like "/api/user/{id}." These instances can lead to additional resource consumption (CPU/memory) within your applications. The high-cardinality configuration available in the CloudWatch agent for Application Signals automatically shields your application from the proliferation of such metrics. By preventing unnecessary metric creation, it not only conserves resources but also reduces noise during application monitoring. Moreover, you have the flexibility to further create rules according to your specific needs, tailoring how these operations appear in the CloudWatch Application Signals console. Learn more about High Cardinality Operations.