SPEAKER: In our last episode, we covered ingesting, routing,
storing, and viewing logs from your services in Cloud Logging.
But what else can you do with all that data?
Today, I'm going to show you how you
can use Cloud Logging to further improve your ability
to keep your services reliable with features like alerting
in logs, logs-based metrics, and capturing application
exceptions in error reporting.
Welcome to "Engineering for Reliability with Google Cloud."
[MUSIC PLAYING]
Let's say you are running a production environment
and you need to know if any modifications are
made to the IAM configuration for this project.
These changes will show up in audit logs,
but you don't really want to sift
through those to figure out when something like this happens.
You could set up a rudimentary log processing
pipeline with Cloud Functions, but now there's an easier way.
Let's have a look at how to use the new log-based alerts
in Cloud Logging.
From the dashboard, go to the Products menu.
And from Logging, select Logs Explorer.
We want to find all logs that show changes in IAM policies.
That's easy enough to do with using recent queries.
Once we have the logs we want to alert on,
we can use the Actions button to create a log alert.
Let's name our alert and add any information
we want to send with the alert.
Next, let's confirm our logs query.
Then, let's set the minimum time between notifications
to be as frequent as we'd like.
Finally, let's specify the notification channel
and save the alert.
The alerting policy has been created,
and we are ready to test it.
If an IAM policy change is made, we can go back to logging
and rerun the query to see that more entries matching our query
are available.
From there, we can go to Monitoring and select Alerting.
There's a current incident based on the alerting policy
we created.
We can select the incident to confirm
that we have a log query match that triggered our condition.
We can click View Logs to see the logs that generated
the match and the alert.
So that's how you can use log-based alert policies
to be notified when, for example, there's
a change in IAM configuration in your project.
Now, alerting in logs is great.
But what if you want to know how many times something like this
happens?
Or what if the log payloads have data in them
that you'd like to measure over time?
This is where logs-based metrics come in.
You can configure a counter metric
to measure the permanent rate of log entries
that match a query or a distribution metric
to capture numeric values from login to payloads.
Let's have a look at how to set up
a counter metric in Cloud Logging
and use it in Cloud Monitoring.
Let's create a metric to count requests
to our service running on App Engine labeled
by response code.
Let's go to the Logs Explorer and select our Google App
Engine application.
Let's select an entry that shows an App Engine request
and use Show Matching Entries to get all the logs that
look like what we want to include
as a source for our metric.
We'll again use the Actions button,
but this time we'll create a metric.
We'll select Counter as the metric type
and name our metric.
Next, we'll confirm the filter and add a label to our metric
that will allow us to separate request counts by status.
Finally, let's save the metric.
Now, when we go to log-based metrics,
we can see our metric here.
Once a metric is created and gathering data,
we can use it like any other monitoring metric.
We can view it in Metrics Explorer,
we can use it for charts and dashboards,
and we can even create alerts using it in a condition.
So that's how you can use a counter log-based metric
to count App Engine requests labeled by response code
status.
We've now seen how to get alerts on logs
and how to use them to create metrics.
The last thing I want to show you
is how to use error reporting to count, analyze, and aggregate
the crashes in your running Cloud Services.
Let's have a look.
From the Products menu, go to Error Reporting.
The initial screen shows you a summary of all the errors
that have been seen in your project over the selected time
interval.
You can click on an error to get more information about it.
The histogram will show you how frequently
this error has occurred.
Further down, you can see the parsed and raw stack traces
and the specific samples of the error.
You can even view the logs that generated
that particular sample.
By viewing the logs for the sample,
you can see information about where the error originated.
Here we can see the GKE cluster, namespace,
and container that threw this particular exception.
So error reporting is a great way
to see application exceptions in your services
and quickly figure out when they're happening
and where they're coming from.
Services running on App Engine or Cloud Run
send errors to error reporting automatically.
You can send errors from other applications
to error reporting by logging into Cloud
Logging in a format recognizable by error reporting,
or by using the error reporting API directly.
Refer to the documentation for details
on both of those options.
Thanks for joining me today.
We covered alerting on log entries,
using logs-based metrics to count and aggregate log
entries, and using error reporting
to track application crashes.
I hope these features help you find issues faster and keep
your services reliable and your users happy.
Thanks so much for watching.
Don't forget to like and subscribe to never miss out
on more "Engineering for Reliability with Google Cloud."
See you soon.
[MUSIC PLAYING]