create_service_level_objective async ¶

async def create_service_level_objective(
    self,
    name: "capo_application_signals.types.service_level_objective_name.ServiceLevelObjectiveName",
    *,
    config_overrides: Optional[AsyncApplicationSignalsClientConfig] = None,
    description: Optional[
        "capo_application_signals.types.service_level_objective_description.ServiceLevelObjectiveDescription"
    ] = None,
    sli_config: Optional[
        "capo_application_signals.types.service_level_indicator_config.ServiceLevelIndicatorConfig"
    ] = None,
    request_based_sli_config: Optional[
        "capo_application_signals.types.request_based_service_level_indicator_config.RequestBasedServiceLevelIndicatorConfig"
    ] = None,
    goal: Optional["capo_application_signals.types.goal.Goal"] = None,
    tags: Optional["capo_application_signals.types.tag_list.TagList"] = None,
    burn_rate_configurations: Optional[
        "capo_application_signals.types.burn_rate_configurations.BurnRateConfigurations"
    ] = None,
    create_recommended_slo: Optional[bool] = None,
    auto_investigation_enabled: Optional[bool] = None,
) -> "capo_application_signals.types.create_service_level_objective_output.CreateServiceLevelObjectiveOutput":
    """<p>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.</p> <p>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. </p> <p>The target performance quality that is defined for an SLO is the <i>attainment goal</i>.</p> <p>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.</p> <note> <p>You can't create an SLO for a service operation that was discovered by Application Signals until after that operation has reported standard metrics to Application Signals.</p> </note> <p>When you create an SLO, you specify whether it is a <i>period-based SLO</i> or a <i>request-based SLO</i>. Each type of SLO has a different way of evaluating your application's performance against its attainment goal.</p> <ul> <li> <p>A <i>period-based SLO</i> uses defined <i>periods</i> 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 <code>number of good periods/number of total periods</code>.</p> <p>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.</p> </li> <li> <p>A <i>request-based SLO</i> doesn't use pre-defined periods of time. Instead, the SLO measures <code>number of good requests/number of total requests</code> 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.</p> </li> </ul> <p>After you have created an SLO, you can retrieve error budget reports for it. An <i>error budget</i> 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.</p> <ul> <li> <p>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 <i>remaining error budget</i> decreases with every failed period that is recorded. The error budget within one interval can never increase.</p> <p>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.</p> </li> <li> <p>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.</p> </li> </ul> <p>For more information about SLOs, see <a href="https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-ServiceLevelObjectives.html"> Service level objectives (SLOs)</a>. </p> <p>When you perform a <code>CreateServiceLevelObjective</code> operation, Application Signals creates the <i>AWSServiceRoleForCloudWatchApplicationSignals</i> service-linked role, if it doesn't already exist in your account. This service- linked role has the following permissions:</p> <ul> <li> <p> <code>xray:GetServiceGraph</code> </p> </li> <li> <p> <code>logs:StartQuery</code> </p> </li> <li> <p> <code>logs:GetQueryResults</code> </p> </li> <li> <p> <code>cloudwatch:GetMetricData</code> </p> </li> <li> <p> <code>cloudwatch:ListMetrics</code> </p> </li> <li> <p> <code>tag:GetResources</code> </p> </li> <li> <p> <code>autoscaling:DescribeAutoScalingGroups</code> </p> </li> </ul>

    Args:
        name: <p>A name for this SLO.</p>
        description: <p>An optional description for this SLO.</p>
        sli_config: <p>If this SLO is a period-based SLO, this structure defines the information about what performance metric this SLO will monitor.</p> <p>You can't specify both <code>RequestBasedSliConfig</code> and <code>SliConfig</code> in the same operation.</p>
        request_based_sli_config: <p>If this SLO is a request-based SLO, this structure defines the information about what performance metric this SLO will monitor.</p> <p>You can't specify both <code>RequestBasedSliConfig</code> and <code>SliConfig</code> in the same operation.</p>
        goal: <p>This structure contains the attributes that determine the goal of the SLO.</p>
        tags: <p>A list of key-value pairs to associate with the SLO. You can associate as many as 50 tags with an SLO. To be able to associate tags with the SLO when you create the SLO, you must have the <code>cloudwatch:TagResource</code> permission.</p> <p>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.</p>
        burn_rate_configurations: <p>Use this array to create <i>burn rates</i> for this SLO. Each burn rate is a metric that indicates how fast the service is consuming the error budget, relative to the attainment goal of the SLO.</p>
        create_recommended_slo: <p>Set this to <code>true</code> to create a recommended SLO out of the box. When set to <code>true</code>, you don't need to specify the <code>MetricThreshold</code> or <code>ComparisonOperator</code> in the <code>SliConfig</code> or <code>RequestBasedSliConfig</code>. The default value is <code>false</code>.</p> <p>This is supported for SLOs on a service, service operation, or a dependency.</p>
        auto_investigation_enabled: Indicates whether DevOps Agent will automatically investigate this SLO when it is breached

    Raises:
        capo_application_signals.errors.access_denied_exception.AccessDeniedException: <p>You don't have sufficient permissions to perform this action.</p>
        capo_application_signals.errors.conflict_exception.ConflictException: <p>This operation attempted to create a resource that already exists.</p>
        capo_application_signals.errors.service_quota_exceeded_exception.ServiceQuotaExceededException: <p>This request exceeds a service quota.</p>
        capo_application_signals.errors.throttling_exception.ThrottlingException: <p>The request was throttled because of quota limits.</p>
        capo_application_signals.errors.validation_exception.ValidationException: <p>The resource is not valid.</p>
        capo_application_signals.errors.UnknownServiceError: The service returned an error code this client does not model.
    """

    async def _handler(
        req: "AsyncOperationRequest[capo_application_signals.types.create_service_level_objective_input.CreateServiceLevelObjectiveInput]",
    ) -> AsyncOperationResponse[
        "capo_application_signals.types.create_service_level_objective_output.CreateServiceLevelObjectiveOutput"
    ]:
        import capo_application_signals._operations.application_signals.create_service_level_objective

        (
            output,
            http_response,
        ) = await capo_application_signals._operations.application_signals.create_service_level_objective.async_create_service_level_objective(
            req.options, req.input
        )
        return AsyncOperationResponse(output=output, response=http_response)

    interceptors_, options_ = self.operation_options(
        config_overrides, OperationLogging("CreateServiceLevelObjective")
    )
    input_: capo_application_signals.types.create_service_level_objective_input.CreateServiceLevelObjectiveInput = {
        "name": name
    }
    if description is not None:
        input_["description"] = description
    if sli_config is not None:
        input_["sli_config"] = sli_config
    if request_based_sli_config is not None:
        input_["request_based_sli_config"] = request_based_sli_config
    if goal is not None:
        input_["goal"] = goal
    if tags is not None:
        input_["tags"] = tags
    if burn_rate_configurations is not None:
        input_["burn_rate_configurations"] = burn_rate_configurations
    if create_recommended_slo is not None:
        input_["create_recommended_slo"] = create_recommended_slo
    if auto_investigation_enabled is not None:
        input_["auto_investigation_enabled"] = auto_investigation_enabled

    response = await aexecute_pipeline(
        AsyncOperationRequest(input=input_, options=options_),
        handler=_handler,
        interceptors=list(interceptors_),
    )
    await response.response.aclose()
    return response.output