In a VMworld 2021 session entitled “The 3 M’s of a Service-Level Objective: Manifest, Measure, Maintain,” Chief Technologist Emad Benjamin explained the importance and role of service-level objectives (SLOs) in driving application resiliency and performance service-level agreements (SLAs). Following Emad, Staff Engineer Deepa Kalani went through the various types of SLOs. She also explained SLO lifecycle as an iterative process. Next, the team delivered a few short demos on how to scribe SLOs in Tanzu Service Mesh (TSM) and monitor them.
The demos showed how to deal with SLOs for services in the Global Namespace (GNS) scope in TSM. We presented “Acme Inc.” as a cloud-native sample application deployed in multiple clusters. “Acme” is a GNS that forms an application boundary for the Acme, Inc., application across clusters. In the sections that follow, we will look at the demo details around configuring monitored SLOs, configuring actionable SLOs, and tracking these SLOs for GNS services.
Configuring GNS-scoped monitored SLO
Figure 1 shows the first page in the SLO creation wizard for the monitored SLO type. We select “acme” GNS and specify the intended Service Level Indicators (SLIs) that form part of this SLO. We also state the objective in terms of the percent of time in a calendar month that the SLI’s conditions must be met. It shows a corresponding error-budget estimate based on the set objective percentage. This error budget is common and federated across all instances of the applied service (see “shopping” as an example). Any of the “shopping” service members in the GNS “acme” violating the SLIs are subtracted from the corresponding error budget.
In Figure 2, we show the service “shopping” selected as service that the SLO applies to.
Figure 3 shows the final page in the SLO Creation Wizard, where the SLO configuration details can be reviewed. Clicking “Save” creates the monitored SLO.
Configuring an GNS-scoped actionable SLO
The creation wizard for an actionable SLO looks similar to that of a monitored SLO. Figure 4 shows the additional step of enabling the service autoscaling action in the SLO.
SLOs can be tracked in the “Performance” tab on the “Service Detail” page. Figure 5 shows the SLO health, error-budget depletion, and SLI violation data for multiple GNS service members over time for the selected time range.
Figure 6 shows SLO charts for the selected calendar month for a given SLO.
Related sessions at VMworld:
- [DEM3171] Distributed Runtimes for Multi-Cloud Application Services
- [VI1448] Take a Modern Approach to Achieve Application Resiliency
Resources: learn more about SLOs: