[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-19。"],[],[],null,["# Designing SLOs\n==============\n\nThis page provides information that you might need before\n[creating a service level objective (SLO)](/service-mesh/v1.19/docs/observability/create-slo).\n\nFor an introduction to SLOs, see the\n[Service level objectives overview](/service-mesh/v1.19/docs/observability/slo-overview).\n\nSLI type and compliance targets\n-------------------------------\n\nCloud Service Mesh supports the following types of service level indicators:\n\n- **Latency**: How long it takes a service to return a response to a request, measured in milliseconds.\n- **Availability**: The fraction of the time that a service responds successfully.\n- **Other**: Customizable SLO type based on your configurable metrics.\n\nYou also define the compliance target that you want from your service. In\ngeneral, SLOs shouldn't be higher than is necessary or meaningful for your\nusers. Consider at what point users might notice service degradation. For\nexample, if your users cannot tell the difference between a latency\nof 300ms or 500ms for your service, use the higher value as the latency\nthreshold in the SLO. The lower value is more expensive to meet, and your users\nwon't notice the difference.\n\nWhen you set a compliance target, consider the end-user requirements for your\nservice. For example, an internal tool used by employees to book vacation time\nmight be fine with a 99% availability target (\\~3 days of downtime per year). But\na critical service for an online store might need 99.999% availability (\\~5\nminutes of downtime per year).\n\nCompliance periods\n------------------\n\nIn addition to defining a target for an SLI, an SLO specifies a period of time\nin which the SLI is being measured. For example, 99% availability over a single\nday is different from 99% availability over a month. The first SLO would not\npermit more than 14 minutes of consecutive downtime (24 hrs \\* 1%), whereas the\nsecond SLO would allow consecutive downtime up to \\~7 hours (30 days \\* 1%).\n\nThe compliance period is particularly important when an SLO is included in a\nservice level agreement (SLA) with your users. An SLA is a contract with the\nusers of your service that typically specifies the consequences of not meeting\nthe SLOs. Whether or not you have an SLA with your users is a product or\nbusiness decision, but for monitoring purposes, you still need to specify a\ncompliance period for your SLOs when you create them.\n\nWhen you configure SLOs, you choose the type of compliance period:\n\n- **Calendar** : When you select **Calendar** as the **Period Type** , you\n also specify the **Period Length**, which can be a day, week or month.\n Periods are non-overlapping and fixed to the calendar start and end dates.\n Compliance can only be evaluated at the end of the period.\n\n- **Rolling** : When you select **Rolling** as the **Period Type** , you\n also specify the number of days for the **Period Length**, for example, 30\n days. Unlike Calendar periods, rolling periods don't have fixed start and\n end dates. Cloud Service Mesh continually evaluates SLOs with a rolling\n compliance period. The oldest data in the previous calculation drops out of\n the current calculation as it is replaced by new data. A rolling time period\n provides more compliance measurements because each day, you get a measure of\n compliance for the last 30 days, rather than one per month. However,\n services can hover between compliance and noncompliance as the SLO status\n changes daily.\n\nError budgets\n-------------\n\nAnother important monitoring concept is the error budget. An SLO specifies an\nSLI and a target value that measures success of the service in the compliance\nperiod. The error budget for an SLO represents the total amount of time that a\nservice can be noncompliant before it is in violation of its SLO. Thus, an error\nbudget is `100% - SLO%`. For example, if you have a rolling 30-day availability\nSLO with a 99.99% compliance target, your error budget is 0.01% of 30 days:\njust over 4 minutes of allowed downtime each 30 days. A service required to meet\na 100% SLO has no error budget.\n\nError budgets let you track how many bad SLI measurements are allowed to occur\nduring the remainder of your compliance period before the service violates the\nSLO. You can use the error budget to help manage maintenance tasks like\ndeployment of new versions. When the error budget is close to depleted, it's not\na good time to take risky actions like deploying new updates. Conversely,\nif you have a full error budget near the end of a compliance period, you might\nwant launch new features since the risk of violating the SLO is lower.\n\nIf you are measuring an SLO with a calendar compliance period, Service Mesh\nstarts the error budget at the maximum value and reduces the budget over time,\ntriggering an SLO violation when the error budget drops below 0.\nCloud Service Mesh resets the SLO's error budget at the end of the compliance\nperiod.\n\nIf you are measuring an SLO over a rolling compliance period, you are\neffectively always at the end of a compliance period. Rather than starting from\nscratch, old data points are continuously dropped and new data points are\ncontinuously added. If a period of poor compliance rolls out of the compliance\nwindow, and if the SLO is compliant, the error budget goes up. At any point in\ntime, an `error budget ≥ 0` indicates a compliant rolling SLO window, and an\n`error budget \u003c 0` indicates a non-compliant rolling SLO window.\n\nWhat's next\n-----------\n\n- Learn more about SLOs from Site Reliability Engineering at Google:\n\n - [Site Reliability Engineering](https://sre.google/sre-book/service-level-objectives/)\n - [The Site Reliability Workbook](https://sre.google/workbook/implementing-slos/)\n- [Create SLOs](/service-mesh/v1.19/docs/observability/create-slo)\n\n- [Monitor SLOs](/service-mesh/v1.19/docs/observability/monitor-slo)"]]