You can configure and apply an org-scoped monitored SLO to a service or a service group.

An Org-Scoped Monitored SLO can track, measure and observe the performance of a microservice to provide a shared quality benchmark that can be used as a reference by SREs, developers and platform operators to gauge what impacts the performance and which thresholds are key to the health of the service. This allows the platform teams to make informed decisions for service upgrades and planned maintenance windows.

You can group services with common characteristics or that are part of one or more related services in a namespace to form a service group in Tanzu Service Mesh. You can configure and set service groups to automatically track against the same SLO definition. Working with service groups helps ensure clean and organized operations. It also reduces the need for repetitively configuring every service.

Example of Use Case 1C

To apply an org scoped monitored SLO to a service or a service group, first set up an SLO. Select the Policy Scope, SLIs that indicate the service quality level and what thresholds are expected to be met.

This screenshot shows that (A) is Org Scoped SLO (applied at the Cluster Level) (B) can be applied to a service or service group (C) p90 latency is selected as 120 ms (D) and Service Level Objective is 98 percent. (D) That means that users can experience the service to have latencies exceed the threshold 14 hours and 24 minutes in a month without violating the SLO. The error budget depletion is done over a calendar month and replenished on the first day of every month.

You can apply SLOs to single services or service groups that are based on rules, for example, all static services, backend services or frontend services. SLOs tailored for individual services allow for fine-grained measurements and observations of each service. The SLO applies to all versions of the selected services. When a new version of a service is created after SLO is created, the SLO automatically applies to the new version as well. This allows SLO as a service-level contract to remain intact regardless of the various versions underneath the service.

This screenshot shows where you can select or define specific services using a service name, cluster, and namespace (A).

You can also select a service group from a drop-down menu (A).