GSP091

Overview

Log-based metrics are Cloud Monitoring metrics that are based on the content of log entries. These metrics can help you identify trends, extract numeric values out of the logs, and set up an alert when a certain log entry occurs by creating a metric for that event. You can use both system and user-defined log-based metrics in Cloud Monitoring to create charts and alerting policies.google

The log-based metrics interface is divided into two metric-type panes: System metrics and User-defined metrics.

System-defined log-based metrics are provided by Cloud Logging for use by all Google Cloud projects.They calculated only from logs that have been ingested by Logging. If a log has been explicitly excluded from ingestion, it isn't included in these metrics.

User-defined log-based metrics are created by you to track things in your Google Cloud project. For example, you might create a log-based metric to count the number of log entries that match a given filter.

Creating an alert from a metric lets you create an alerting policy based on the log-based metric.

What you'll learn

In this lab, you learn how to:

• Create a log-based alert.
• Create a log-based metric.
• Create a metrics-based alert.
• Test alerts.

Setup and requirements

Before you click the Start Lab button

Read these instructions. Labs are timed and you cannot pause them. The timer, which starts when you click Start Lab, shows how long Google Cloud resources will be made available to you.

This hands-on lab lets you do the lab activities yourself in a real cloud environment, not in a simulation or demo environment. It does so by giving you new, temporary credentials that you use to sign in and access Google Cloud for the duration of the lab.

To complete this lab, you need:

• Access to a standard internet browser (Chrome browser recommended).

Note: Use an Incognito or private browser window to run this lab. This prevents any conflicts between your personal account and the Student account, which may cause extra charges incurred to your personal account.

• Time to complete the lab---remember, once you start, you cannot pause a lab.

Note: If you already have your own personal Google Cloud account or project, do not use it for this lab to avoid extra charges to your account.

How to start your lab and sign in to the Google Cloud console

1. Click the Start Lab button. If you need to pay for the lab, a pop-up opens for you to select your payment method. On the left is the Lab Details panel with the following:

   • The Open Google Cloud console button
   • Time remaining
   • The temporary credentials that you must use for this lab
   • Other information, if needed, to step through this lab

2. Click Open Google Cloud console (or right-click and select Open Link in Incognito Window if you are running the Chrome browser).

   The lab spins up resources, and then opens another tab that shows the Sign in page.

   Tip: Arrange the tabs in separate windows, side-by-side.

   Note: If you see the Choose an account dialog, click Use Another Account.

3. If necessary, copy the Username below and paste it into the Sign in dialog.

   {{{user_0.username | "Username"}}}

   You can also find the Username in the Lab Details panel.

4. Click Next.

5. Copy the Password below and paste it into the Welcome dialog.

   {{{user_0.password | "Password"}}}

   You can also find the Password in the Lab Details panel.

6. Click Next.

   Important: You must use the credentials the lab provides you. Do not use your Google Cloud account credentials. Note: Using your own Google Cloud account for this lab may incur extra charges.

7. Click through the subsequent pages:

   • Accept the terms and conditions.
   • Do not add recovery options or two-factor authentication (because this is a temporary account).
   • Do not sign up for free trials.

After a few moments, the Google Cloud console opens in this tab.

Note: To view a menu with a list of Google Cloud products and services, click the Navigation menu at the top-left.

Activate Cloud Shell

Cloud Shell is a virtual machine that is loaded with development tools. It offers a persistent 5GB home directory and runs on the Google Cloud. Cloud Shell provides command-line access to your Google Cloud resources.

1. Click Activate Cloud Shell at the top of the Google Cloud console.

When you are connected, you are already authenticated, and the project is set to your Project_ID, . The output contains a line that declares the Project_ID for this session:

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

gcloud is the command-line tool for Google Cloud. It comes pre-installed on Cloud Shell and supports tab-completion.

2. (Optional) You can list the active account name with this command:

gcloud auth list

3. Click Authorize.

Output:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

4. (Optional) You can list the project ID with this command:

gcloud config list project

Output:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Note: For full documentation of gcloud, in Google Cloud, refer to the gcloud CLI overview guide.

Task 1. Deploy a GKE Cluster

In this task, you deploy a Google Kubernetes Engine (GKE) cluster to use in later tasks for log-based metrics.

1. In Cloud Shell, set the zone in for this lab environment:

gcloud config set compute/zone {{{ project_0.default_zone | "ZONE" }}}

If prompted, click Authorize Cloud Shell.

2. Set the project ID for this lab environment:

export PROJECT_ID=$(gcloud info --format='value(config.project)')

3. Deploy a standard GKE cluster:

gcloud container clusters create gmp-cluster --num-nodes=1 --zone {{{ project_0.default_zone | "ZONE" }}}

When the cluster has been deployed, the output displays STATUS: RUNNING for the cluster named gmp-cluster.

Note: It may take several minutes for the cluster to be deployed. You can proceed to complete Task 2, and then return to validate your progress using the check below.

Click Check my progress to verify the objective. Deploy the GKE cluster

Task 2. Create a log-based alert

Log-based alerts notify you whenever a specific message appears in your logs. Try it out by setting up a log-based alert to tell you when a VM stops running.

1. From Cloud Console, in the Search bar, type Logs explorer, then click on the Logs Explorer result.

2. Enable the Show Query slide bar (if it is not already).

3. Copy and paste the following parameters into the query window to create Log Based Alert:

resource.type="gce_instance" protoPayload.methodName="v1.compute.instances.stop"

4. Under Actions (at the top of the Results section), click Create log alert.

5. Add the following parameters, and click Next after adding each value, so that you can see the next section:

• Alert policy name: stopped vm
• Choose logs to include in the alert: this section auto-fills with the query you entered previously
• Set notification frequency and autoclose duration: Select Time between notifications as 5 min and Incident autoclose duration as 1 hr.

6. Click Next.

7. For Who should be notified, complete the following:

• Click on the dropdown arrow next to Notification Channels, then click on Manage Notification Channels. (A Notification channels page will open in the new tab.)
• Scroll down the page and click on Add new for Email.
• Enter an email in the Email Address field and a Display name. You can use your personal email if you want to view the email, or you can provide the lab username () for which you cannot see the email.
• Click Save.

8. Close the Notification Channels using the 'X' at top of the page, so you can return to the Logs Explorer tab you were in previously.

• Refresh the Notification Channels, then select the channel you just created. Click OK.

9. Click Save.

Click Check my progress to verify the objective. Create the Log-based alert

To test this log-based alert, you will now stop your VM.

10. Open a second Google Cloud console browser tab, and navigate to Navigation menu > Compute Engine > VM instances.

11. Check the box next to instance1, then click Stop at the top of the page. Click Stop again in the pop-up window.

    This may take a moment. When the instance has been stopped, the green check mark will turn to a gray circle.

12. In the Search bar, type Monitoring, then choose the Monitoring (Infrastructure and application quality checks) option.

13. From the left side menu for Logging, click on Alerting under Detect.

    You should see that your alert has registered.

14. Under Policies, click the See all policies to see the log-based alert you created named stopped vm.

Task 3. Deploy a simple application that emits metrics

Using log-based metrics you can define a metric that tracks errors in the logs to proactively respond to similar problems and symptoms before they are noticed by end users.

1. Run the following command to check that the cluster you deployed in Task 1 has been fully provisioned:

gcloud container clusters list Note: If your cluster status says PROVISIONING, wait a moment and run the command above again. Repeat until the status is RUNNING, at which point you can continue with the next steps.

2. Authenticate the cluster:

gcloud container clusters get-credentials gmp-cluster

You should see the following message:

Fetching cluster endpoint and auth data. kubeconfig entry generated for gmp-cluster.

3. Create a namespace to work in:

kubectl create ns gmp-test

4. Now run the following to deploy a simple application that emits metrics at the /metrics endpoint:

kubectl -n gmp-test apply -f https://storage.googleapis.com/spls/gsp091/gmp_flask_deployment.yaml kubectl -n gmp-test apply -f https://storage.googleapis.com/spls/gsp091/gmp_flask_service.yaml

5. Verify that the namespace is ready and emitting metrics:

kubectl get services -n gmp-test

You should see the following:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello LoadBalancer 10.0.12.114 34.83.91.157 80:32058/TCP 71s

Click Check my progress to verify the objective. Deploy the simple application that emits metrics

6. Re-run the command until you see the External-IP address populated.

7. Check that the Python Flask app is serving metrics with the following command:

curl $(kubectl get services -n gmp-test -o jsonpath='{.items[*].status.loadBalancer.ingress[0].ip}')/metrics

You should see the following:

# HELP flask_exporter_info Multiprocess metric # TYPE flask_exporter_info gauge flask_exporter_info{version="0.18.5"} 1.0

Task 4. Create a log-based metric

1. Return to Logs Explorer.

2. Under Actions, click Create metric link.

3. On the Create metric page, input the following:

• Metric type: leave the default setting (Counter)
• Log based metric name: hello-app-error
• Filter selection: update Build filter window with the following information:

severity=ERROR resource.labels.container_name="hello-app" textPayload: "ERROR: 404 Error page not found"

4. Click Create metric.

Click Check my progress to verify the objective. Create the log-based metric

Task 5. Create a metrics-based alert

1. From the left side menu for Logging, click on Log-based Metrics under Configure.

2. In user-defined metrics, click on More actions (3 vertical dots) for hello-app-error, and select Create alert from metric.

3. Under Select a Metric, the metric parameters will automatically fill in.

• Update the Rolling window to 2 min.
• Accept the other default settings.
• Click Next twice.

4. Set notifications using the channel you created earlier in the lab.

5. Name the alert policy: log based metric alert

6. Click Create Policy.

Click Check my progress to verify the objective. Create the metrics-based alert

Task 6. Generate some errors

Next you'll generate some errors to match the log-based metric you created and trigger the metric-based alert.

1. In Cloud Shell, run the following to generate some errors:

timeout 120 bash -c -- 'while true; do curl $(kubectl get services -n gmp-test -o jsonpath='{.items[*].status.loadBalancer.ingress[0].ip}')/error; sleep $((RANDOM % 4)) ; done'

2. Return to the Logs Explorer page, and go to the Severity section on the lower left side.

3. Click on the Error severity.

   Now you can search for the 404 Error page not found error. View more information by expanding one of the 404 Error messages.

4. Return to the Monitoring page, and click on Alerting.

   You will see the 2 policies you created.

5. Under Alert policies, click on View all.

   You should see both alerts in the Incidents section.

6. Click on an incident to see details.

Note: The log-based metric alert will eventually resolve itself. If you need more time to investigate, you can run the code to generate errors again and wait for the alert to be triggered again.

Click Check my progress to verify the objective. Generate some errors

Congratulations!

In this lab, you created a log-based alert, a system-defined log-based metric, a user-defined log-based metric, and a metric-based alert. You also generated some errors to trigger the alert. Lastly, you learned how to view the incidents and details of the alerts.

Next steps / Learn more

• Read about how to manage your alerting policies.
• For details on creating alerting policies for your log-based metrics, read Creating an alerting policy.

Google Cloud training and certification

...helps you make the most of Google Cloud technologies. Our classes include technical skills and best practices to help you get up to speed quickly and continue your learning journey. We offer fundamental to advanced level training, with on-demand, live, and virtual options to suit your busy schedule. Certifications help you validate and prove your skill and expertise in Google Cloud technologies.

Manual Last Updated November 12, 2024

Lab Last Tested November 12, 2024

Copyright 2024 Google LLC All rights reserved. Google and the Google logo are trademarks of Google LLC. All other company and product names may be trademarks of the respective companies with which they are associated.