iTranslated by AI
A Thorough Guide to Amazon CloudWatch Application Signals (Preview)
Hello everyone.
How are you doing?
I am Ryo Yoshii, a huge fan of the phrase "No human labor is no human error."
On December 18, 2023, I gave a presentation at OpsJAWS Meetup #26 titled "A Thorough Explanation of Amazon CloudWatch Application Signals (Preview)."
I would like to share the presentation materials and a summary with you.
Materials
Contents
- What is CloudWatch Application Signals (Preview)?
- Why is it beneficial?
- Demo (Walkthrough)
What is CloudWatch Application Signals (Preview)?
What does "Signals" mean?
According to the OpenTelemetry definition, they are "system outputs that describe the underlying activity of a system."
I assume Application Signals follows this definition.

Using Application Signals allows for easy automated instrumentation and operation of your applications.
There is no need for tedious tasks like manual instrumentation or creating complex metrics.
The ADOT auto-instrumentation agent collects metrics (which are actually logs) and traces from your application.
Collected signals allow you to visualize your application's performance goals without needing to build dashboards.
Furthermore, it can integrate with multiple AWS services.

At the time of the preview, the supported language is Java, with JVM 8, 11, and 17 supported.
Application Signals is based on OpenTelemetry. Since Java is the most mature language in OpenTelemetry, it makes sense that only Java is supported at this preview stage.
However, since Preview SDKs for major languages have already been released, I have high expectations that support for others will be added sequentially by the time of GA.

Supported architectures are EKS, ECS, and EC2. I imagine this is because Application Signals requires the CloudWatch Agent.
GitHub PR 929 for the CloudWatch Agent seems to be related to Application Signals. Take a look if you are interested.

Supported regions at the time of the preview are as shown below.

This is a configuration I put together myself.
Traces and logs are collected from the application via the ADOT Agent and sent to the CloudWatch Agent. After the CloudWatch Agent converts the data format, it is sent to CloudWatch or X-Ray.

For pricing at the time of the preview, please refer to this page. In addition to Application Signals, costs for X-Ray, CloudWatch Logs, (if used) RUM, Synthetic Canary, alarms, and dashboards are expected separately.
Since it is not cheap, you need to carefully select the SLIs to be sent to Application Signals and the SLOs based on them. Also, make sure to perform proper sampling of the signals sent. If you send all service requests as signals to Application Signals, you will incur massive costs.
Why is it beneficial?


The best thing is that you can measure and manage SLOs entirely within AWS.
SLO can be thought of as a target to determine the boundary of whether you need to address a certain issue or if it is okay to wait.
With traditional CloudWatch metrics and dashboards, it was difficult to express SLOs. You might be able to achieve it if you have a "CloudWatch dashboard artisan," but such an artisan doesn't seem necessary for a team.


With Application Signals, the following are displayed automatically:
You can set up alarms if you fall below the SLO achievement rate. The rate of error budget consumption is also a good topic for morning meetings. Be careful if the rate of decrease starts to accelerate.
- SLO achievement status
- Remaining error budget
- Error budget consumption rate (burn rate)
It automatically displays latency and availability for each API and operation.
After operating for a while and measuring these, you can set your SLOs. You should be able to create realistic SLOs. This is far better than setting them arbitrarily without any baseline.
Additionally, the combination of obtaining a comprehensive view of services and automatically displaying dependencies allows for early detection of problematic areas.
3-line Summary

- Still in preview
- Easy SLO management
- Automated instrumentation and automated dashboards
One Observability Workshop, which is renowned as a textbook for learning Ops on AWS, has already added a workshop for this.
If you want to easily experience Application Signals, why not give this a try?
Discussion