ApplicationSignalsClient

Use CloudWatch Application Signals for comprehensive observability of your cloud-based applications. It enables real-time service health dashboards and helps you track long-term performance trends against your business goals. The application-centric view provides you with unified visibility across your applications, services, and dependencies, so you can proactively monitor and efficiently triage any issues that may arise, ensuring optimal customer experience.

Application Signals provides the following benefits:

  • Automatically collect metrics and traces from your applications, and display key metrics such as call volume, availability, latency, faults, and errors.

  • Create and monitor service level objectives (SLOs).

  • See a map of your application topology that Application Signals automatically discovers, that gives you a visual representation of your applications, dependencies, and their connectivity.

Application Signals works with CloudWatch RUM, CloudWatch Synthetics canaries, and Amazon Web Services Service Catalog AppRegistry, to display your client pages, Synthetics canaries, and application names within dashboards and maps.

Installation

NPM
npm install @aws-sdk/client-application-signals
Yarn
yarn add @aws-sdk/client-application-signals
pnpm
pnpm add @aws-sdk/client-application-signals

ApplicationSignalsClient Operations

Command
Summary
BatchGetServiceLevelObjectiveBudgetReportCommand

Use this operation to retrieve one or more service level objective (SLO) budget reports.

An error budget is the amount of time or requests in an unhealthy state that your service can accumulate during an interval before your overall SLO budget health is breached and the SLO is considered to be unmet. For example, an SLO with a threshold of 99.95% and a monthly interval translates to an error budget of 21.9 minutes of downtime in a 30-day month.

Budget reports include a health indicator, the attainment value, and remaining budget.

For more information about SLO error budgets, see SLO concepts .

CreateServiceLevelObjectiveCommand

Creates a service level objective (SLO), which can help you ensure that your critical business operations are meeting customer expectations. Use SLOs to set and track specific target levels for the reliability and availability of your applications and services. SLOs use service level indicators (SLIs) to calculate whether the application is performing at the level that you want.

Create an SLO to set a target for a service or operation’s availability or latency. CloudWatch measures this target frequently you can find whether it has been breached.

The target performance quality that is defined for an SLO is the attainment goal.

You can set SLO targets for your applications that are discovered by Application Signals, using critical metrics such as latency and availability. You can also set SLOs against any CloudWatch metric or math expression that produces a time series.

When you create an SLO, you specify whether it is a period-based SLO or a request-based SLO. Each type of SLO has a different way of evaluating your application's performance against its attainment goal.

  • A period-based SLO uses defined periods of time within a specified total time interval. For each period of time, Application Signals determines whether the application met its goal. The attainment rate is calculated as the number of good periods/number of total periods.

    For example, for a period-based SLO, meeting an attainment goal of 99.9% means that within your interval, your application must meet its performance goal during at least 99.9% of the time periods.

  • A request-based SLO doesn't use pre-defined periods of time. Instead, the SLO measures number of good requests/number of total requests during the interval. At any time, you can find the ratio of good requests to total requests for the interval up to the time stamp that you specify, and measure that ratio against the goal set in your SLO.

After you have created an SLO, you can retrieve error budget reports for it. An error budget is the amount of time or amount of requests that your application can be non-compliant with the SLO's goal, and still have your application meet the goal.

  • For a period-based SLO, the error budget starts at a number defined by the highest number of periods that can fail to meet the threshold, while still meeting the overall goal. The remaining error budget decreases with every failed period that is recorded. The error budget within one interval can never increase.

    For example, an SLO with a threshold that 99.95% of requests must be completed under 2000ms every month translates to an error budget of 21.9 minutes of downtime per month.

  • For a request-based SLO, the remaining error budget is dynamic and can increase or decrease, depending on the ratio of good requests to total requests.

For more information about SLOs, see Service level objectives (SLOs) .

When you perform a CreateServiceLevelObjective operation, Application Signals creates the AWSServiceRoleForCloudWatchApplicationSignals service-linked role, if it doesn't already exist in your account. This service- linked role has the following permissions:

  • xray:GetServiceGraph

  • logs:StartQuery

  • logs:GetQueryResults

  • cloudwatch:GetMetricData

  • cloudwatch:ListMetrics

  • tag:GetResources

  • autoscaling:DescribeAutoScalingGroups

DeleteServiceLevelObjectiveCommand

Deletes the specified service level objective.

GetServiceCommand

Returns information about a service discovered by Application Signals.

GetServiceLevelObjectiveCommand

Returns information about one SLO created in the account.

ListServiceDependenciesCommand

Returns a list of service dependencies of the service that you specify. A dependency is an infrastructure component that an operation of this service connects with. Dependencies can include Amazon Web Services services, Amazon Web Services resources, and third-party services.

ListServiceDependentsCommand

Returns the list of dependents that invoked the specified service during the provided time range. Dependents include other services, CloudWatch Synthetics canaries, and clients that are instrumented with CloudWatch RUM app monitors.

ListServiceLevelObjectivesCommand

Returns a list of SLOs created in this account.

ListServiceOperationsCommand

Returns a list of the operations of this service that have been discovered by Application Signals. Only the operations that were invoked during the specified time range are returned.

ListServicesCommand

Returns a list of services that have been discovered by Application Signals. A service represents a minimum logical and transactional unit that completes a business function. Services are discovered through Application Signals instrumentation.

ListTagsForResourceCommand

Displays the tags associated with a CloudWatch resource. Tags can be assigned to service level objectives.

StartDiscoveryCommand

Enables this Amazon Web Services account to be able to use CloudWatch Application Signals by creating the AWSServiceRoleForCloudWatchApplicationSignals service-linked role. This service- linked role has the following permissions:

  • xray:GetServiceGraph

  • logs:StartQuery

  • logs:GetQueryResults

  • cloudwatch:GetMetricData

  • cloudwatch:ListMetrics

  • tag:GetResources

  • autoscaling:DescribeAutoScalingGroups

After completing this step, you still need to instrument your Java and Python applications to send data to Application Signals. For more information, see Enabling Application Signals .

TagResourceCommand

Assigns one or more tags (key-value pairs) to the specified CloudWatch resource, such as a service level objective.

Tags can help you organize and categorize your resources. You can also use them to scope user permissions by granting a user permission to access or change only resources with certain tag values.

Tags don't have any semantic meaning to Amazon Web Services and are interpreted strictly as strings of characters.

You can use the TagResource action with an alarm that already has tags. If you specify a new tag key for the alarm, this tag is appended to the list of tags associated with the alarm. If you specify a tag key that is already associated with the alarm, the new tag value that you specify replaces the previous value for that tag.

You can associate as many as 50 tags with a CloudWatch resource.

UntagResourceCommand

Removes one or more tags from the specified resource.

UpdateServiceLevelObjectiveCommand

Updates an existing service level objective (SLO). If you omit parameters, the previous values of those parameters are retained.

You cannot change from a period-based SLO to a request-based SLO, or change from a request-based SLO to a period-based SLO.

ApplicationSignalsClient Configuration

Parameter
Type
Description
defaultsMode
Optional
DefaultsMode | Provider<DefaultsMode>
The @smithy/smithy-client#DefaultsMode that will be used to determine how certain default configuration options are resolved in the SDK.
disableHostPrefix
Optional
boolean
Disable dynamically changing the endpoint of the client based on the hostPrefix trait of an operation.
extensions
Optional
RuntimeExtension[]
Optional extensions
logger
Optional
Logger
Optional logger for logging debug/info/warn/error.
maxAttempts
Optional
number | Provider<number>
Value for how many times a request will be made at most in case of retry.
profile
Optional
string
Setting a client profile is similar to setting a value for the AWS_PROFILE environment variable. Setting a profile on a client in code only affects the single client instance, unlike AWS_PROFILE.When set, and only for environments where an AWS configuration file exists, fields configurable by this file will be retrieved from the specified profile within that file. Conflicting code configuration and environment variables will still have higher priority.For client credential resolution that involves checking the AWS configuration file, the client's profile (this value) will be used unless a different profile is set in the credential provider options.
region
Optional
string | Provider<string>
The AWS region to which this client will send requests
requestHandler
Optional
__HttpHandlerUserInput
The HTTP handler to use or its constructor options. Fetch in browser and Https in Nodejs.
retryMode
Optional
string | Provider<string>
Specifies which retry algorithm to use.
useDualstackEndpoint
Optional
boolean | Provider<boolean>
Enables IPv6/IPv4 dualstack endpoint.
useFipsEndpoint
Optional
boolean | Provider<boolean>
Enables FIPS compatible endpoints.
Additional config fields are described in the full configuration type: ApplicationSignalsClientConfig