Module types 

Data structures used by operation inputs/outputs.

Modules

builders

Builders

error

Error types that Amazon CloudWatch Application Signals can respond with.

Structs

AttributeFilter

A structure that defines a filter for narrowing down results based on specific attribute values. This can be used to filter services by platform, environment, or other service characteristics.

AuditFinding

A structure that contains information about an audit finding, which represents an automated analysis result about service behavior, performance issues, or potential problems identified through heuristic algorithms.

AuditTarget

A structure that specifies the target entity for audit analysis, such as a service, SLO, or service_operation.

AuditorResult

A structure that contains the result of an automated audit analysis, including the auditor name, description of findings, and severity level.

BatchUpdateExclusionWindowsError

An array of structures, where each structure includes an error indicating that one of the requests in the array was not valid.

BurnRateConfiguration

This object defines the length of the look-back window used to calculate one burn rate metric for this SLO. The burn rate measures how fast the service is consuming the error budget, relative to the attainment goal of the SLO. A burn rate of exactly 1 indicates that the SLO goal will be met exactly.

For example, if you specify 60 as the number of minutes in the look-back window, the burn rate is calculated as the following:

burn rate = error rate over the look-back window / (100% - attainment goal percentage)

For more information about burn rates, see Calculate burn rates.

CalendarInterval

If the interval for this service level objective is a calendar interval, this structure contains the interval specifications.

ChangeEvent

A structure that contains information about a change event that occurred for a service, such as a deployment or configuration change.

DependencyConfig

Identifies the dependency using the DependencyKeyAttributes and DependencyOperationName.

When creating a service dependency SLO, you must specify the KeyAttributes of the service, and the DependencyConfig for the dependency. You can specify the OperationName of the service, from which it calls the dependency. Alternatively, you can exclude OperationName and the SLO will monitor all of the service's operations that call the dependency.

DependencyGraph

A structure that represents the dependency relationships relevant to an audit finding, containing nodes and edges that show how services and resources are connected.

Dimension

A dimension is a name/value pair that is part of the identity of a metric. Because dimensions are part of the unique identifier for a metric, whenever you add a unique name/value pair to one of your metrics, you are creating a new variation of that metric. For example, many Amazon EC2 metrics publish InstanceId as a dimension name, and the actual instance ID as the value for that dimension.

You can assign up to 30 dimensions to a metric.

Edge

A structure that represents a connection between two nodes in a dependency graph, showing the relationship and characteristics of the connection.

ExclusionWindow

The core SLO time window exclusion object that includes Window, StartTime, RecurrenceRule, and Reason.

Goal

This structure contains the attributes that determine the goal of an SLO. This includes the time period for evaluation and the attainment threshold.

GroupingAttributeDefinition

A structure that defines how services should be grouped based on specific attributes. This includes the friendly name for the grouping, the source keys to derive values from, and an optional default value.

GroupingConfiguration

A structure that contains the complete grouping configuration for an account, including all defined grouping attributes and metadata about when it was last updated.

Metric

This structure defines the metric used for a service level indicator, including the metric name, namespace, and dimensions

MetricDataQuery

Use this structure to define a metric or metric math expression that you want to use as for a service level objective.

Each MetricDataQuery in the MetricDataQueries array specifies either a metric to retrieve, or a metric math expression to be performed on retrieved metrics. A single MetricDataQueries array can include as many as 20 MetricDataQuery structures in the array. The 20 structures can include as many as 10 structures that contain a MetricStat parameter to retrieve a metric, and as many as 10 structures that contain the Expression parameter to perform a math expression. Of those Expression structures, exactly one must have true as the value for ReturnData. The result of this expression used for the SLO.

For more information about metric math expressions, see CloudWatchUse metric math.

Within each MetricDataQuery object, you must specify either Expression or MetricStat but not both.

MetricGraph

A structure that contains metric data queries and time range information that provides context for audit findings through relevant performance metrics.

MetricReference

This structure contains information about one CloudWatch metric associated with this entity discovered by Application Signals.

MetricStat

This structure defines the metric to be used as the service level indicator, along with the statistics, period, and unit.

Node

A structure that represents a node in a dependency graph, containing information about a service, resource, or other entity and its characteristics.

RecurrenceRule

The recurrence rule for the SLO time window exclusion .

RequestBasedServiceLevelIndicator

This structure contains information about the performance metric that a request-based SLO monitors.

RequestBasedServiceLevelIndicatorConfig

This structure specifies the information about the service and the performance metric that a request-based SLO is to monitor.

RequestBasedServiceLevelIndicatorMetric

This structure contains the information about the metric that is used for a request-based SLO.

RequestBasedServiceLevelIndicatorMetricConfig

Use this structure to specify the information for the metric that a period-based SLO will monitor.

RollingInterval

If the interval for this SLO is a rolling interval, this structure contains the interval specifications.

Service

This structure contains information about one of your services that was discovered by Application Signals.

ServiceDependency

This structure contains information about one dependency of this service.

ServiceDependent

This structure contains information about a service dependent that was discovered by Application Signals. A dependent is an entity 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.

ServiceEntity

A structure that contains identifying information for a service entity.

ServiceGroup

A structure that represents a logical grouping of services based on shared attributes such as business unit, environment, or entry point.

ServiceLevelIndicator

This structure contains information about the performance metric that a period-based SLO monitors.

ServiceLevelIndicatorConfig

This structure specifies the information about the service and the performance metric that a period-based SLO is to monitor.

ServiceLevelIndicatorMetric

This structure contains the information about the metric that is used for a period-based SLO.

ServiceLevelIndicatorMetricConfig

Use this structure to specify the information for the metric that a period-based SLO will monitor.

ServiceLevelObjective

A structure containing information about one service level objective (SLO) that has been created in Application Signals. Creating SLOs can help you ensure your services are performing to the level that you expect. SLOs help you set and track a specific target level for the reliability and availability of your applications and services. Each SLO uses a service level indicator (SLI), which is a key performance metric, to calculate how much underperformance can be tolerated before the goal that you set for the SLO is not achieved.

ServiceLevelObjectiveBudgetReport

A structure containing an SLO budget report that you have requested.

ServiceLevelObjectiveBudgetReportError

A structure containing information about one error that occurred during a BatchGetServiceLevelObjectiveBudgetReport operation.

ServiceLevelObjectiveEntity

A structure that contains identifying information for a service level objective entity.

ServiceLevelObjectiveSummary

A structure that contains information about one service level objective (SLO) created in Application Signals.

ServiceOperation

This structure contains information about an operation discovered by Application Signals. An operation is a specific function performed by a service that was discovered by Application Signals, and is often an API that is called by an upstream dependent.

ServiceOperationEntity

A structure that contains identifying information for a service operation entity.

ServiceState

A structure that contains information about the current state of a service, including its latest change events such as deployments and other state-changing activities.

ServiceSummary

This structure contains information about one of your services that was discovered by Application Signals

Tag

A key-value pair associated with a resource. Tags can help you organize and categorize your resources.

Window

The object that defines the time length of an exclusion window.

Enums

AuditTargetEntity

A union structure that contains the specific entity information for different types of audit targets.

ChangeEventType

When writing a match expression against ChangeEventType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

ConnectionType

When writing a match expression against ConnectionType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

DurationUnit

When writing a match expression against DurationUnit, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

EvaluationType

When writing a match expression against EvaluationType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

Interval

The time period used to evaluate the SLO. It can be either a calendar interval or rolling interval.

MetricSourceType

When writing a match expression against MetricSourceType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

MonitoredRequestCountMetricDataQueries

This structure defines the metric that is used as the "good request" or "bad request" value for a request-based SLO. This value observed for the metric defined in TotalRequestCountMetric is divided by the number found for MonitoredRequestCountMetric to determine the percentage of successful requests that this SLO tracks.

ServiceLevelIndicatorComparisonOperator

When writing a match expression against ServiceLevelIndicatorComparisonOperator, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

ServiceLevelIndicatorMetricType

When writing a match expression against ServiceLevelIndicatorMetricType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

ServiceLevelObjectiveBudgetStatus

When writing a match expression against ServiceLevelObjectiveBudgetStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

Severity

When writing a match expression against Severity, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.

StandardUnit

When writing a match expression against StandardUnit, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.