SPEAKER: Service Level Objectives, or SLOs,
are the primary way by which we set appropriate reliability
targets for our services.
The latest release of SLO monitoring in Google Cloud
operations makes doing this especially easy for services
running on GKE.
I'm here today to give you a walk through and show you
how to get started.
This is The Stack Doctor.
[MUSIC PLAYING]
We looked at how to use the API to define Service Level
Indicators, or SLIs and set SLOs in an earlier episode.
But now, you can do both of those in the UI.
Let's take a look.
Start by going to the Services screen under Monitoring.
If you were using the Istio service mesh in your cluster,
you'll notice that your services have already been automatically
identified for you.
You can filter the list as necessary.
For example, you may want to only see
services running in a particular cluster
or in that particular region.
To filter for services that match a particular label value,
just type the value of the label you want into the Filter field.
If you're not using Istio, you can define a new service
by selecting a GKE entity you'd like to use
as the base for the service.
This won't make any modifications of the entity
itself, it'll just create a new monitoring construct
you can use to create SLOs.
Once you've found the service you're looking for,
or created a new one, click on it in the list.
On the Service Detail screen, you
can see the SLOs you've already defined for it, if there
are any, any alerts for the time span selected,
and the logs for the service.
From here click Create SLO.
In order to create an SLO, you first
have to choose the SLI, or the Service Level Indicator,
you'd like to use as the measure of service reliability.
Here you have three options: availability, performance,
or other.
But what does each one of those mean?
An Availability SLI will measure the ratio
of successful requests to all request of the service.
For this service, Istio automatically
tracks that metric and no additional instrumentation
is necessary.
A Performance SLI will measure the ratio
of requests that complete within a specific time
to all requests.
Because Istio automatically tracks latency
for each request, this is another out of the box metric.
If you want to use a custom metric as your SLI,
select Other at this point.
For example, you may have instrumented the service
using OpenTelemetry to count the number of transactions
that meet specific criteria.
Using a custom SLI will let you select that metric.
The next choice is between a Request-based
and a Window-based SLI.
We covered this in our earlier episode
on using the API to create SLOs, but it's worth
reviewing it briefly.
Request-based SLIs measure the fraction
of good units of work against the total.
Now for example, what percentage of requests of your service
were successful in a given time window?
An example of a Request-based availability
SLO is 99% of requests are successful over a rolling seven
day window.
This is the more straightforward,
and commonly used, option.
Window-based SLIs measure the fraction of time intervals
during which the service meets some threshold over a given
time window.
An example of a Window-based availability
SLO is 99% of requests are successful within 99%
of 10 minute intervals over a rolling seven day window.
Once you've selected your SLI and evaluation type,
click Next.
Take a look at the signal you've chosen
and confirm that the metric behaves as you would expect.
For example, if the service has been healthy for the last hour
the metric should show a mostly flat trend.
Once you're satisfied with the signal, click Next.
You may recall that an SLO is the combination of three
things: the SLI, which we've already chosen,
a target, and a compliance period.
On this screen, you need to provide the compliance period,
which is the length of the time window
over which the SLI is going to be evaluated.
Next, specify your goal.
This is the target for the SLI.
Now your SLO definition is complete.
Click Next to finalize it.
This is the last step: give your SLO
a name that reflects what it's measuring, and click Submit.
That'll take you back to the Service Detail screen
with your new SLO added and its health clearly displayed.
Thanks for joining me today.
We looked through the new SLO monitoring functionality
and learned how to use it to define availability
and performance SLOs for our services running in GKE.
Now you are ready to start configuring
SLOs for your own services.
Thanks for watching and come back soon for more.
This is The Stack Doctor.
Stay healthy out there.