GKE monitoring and logging in GCP - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the command to enable monitoring on a GKE cluster.

GCP

gcloud container clusters create my-cluster --enable-[1]

Drag options to blanks, or click blank then click option'

Astackdriver-kubernetes

Bautoscaling

Clogging

Dnetwork-policy

Attempts:

3 left

💡 Hint

Common Mistakes

Using --enable-logging alone does not enable full monitoring integration.

Confusing autoscaling with monitoring features.

The --enable-stackdriver-kubernetes flag enables Google Cloud's monitoring and logging for GKE clusters.

2fill in blank

medium

Complete the command to view logs of a pod named 'web-server' in namespace 'default'.

GCP

kubectl logs [1] -n default

Drag options to blanks, or click blank then click option'

Adeployment/web-server

Bpod/web-server

Cweb-server

Dservice/web-server

Attempts:

3 left

💡 Hint

Common Mistakes

Using deployment or service names instead of pod name.

Omitting the namespace when the pod is not in default namespace.

The kubectl logs command takes the pod name directly. Using just web-server works if it is the pod name.

3fill in blank

hard

Fix the error in the command to enable logging on an existing cluster named 'prod-cluster'.

GCP

gcloud container clusters update prod-cluster --[1]-logging

Drag options to blanks, or click blank then click option'

Aenable

Bdisable

Cstart

Dactivate

Attempts:

3 left

💡 Hint

Common Mistakes

Using --start-logging or --activate-logging which are invalid flags.

Using --disable-logging when intending to enable.

The correct flag to enable logging is --enable-logging. Other options are invalid.

4fill in blank

hard

Fill both blanks to create a monitoring workspace and link it to a GKE cluster.

GCP

gcloud monitoring workspaces [1] --project=[2]

Drag options to blanks, or click blank then click option'

Acreate

Bdelete

Cmy-gke-project

Dlist

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'delete' or 'list' instead of 'create' for the workspace.

Not specifying the correct project ID.

You create a monitoring workspace with create and specify the project ID to link it.

5fill in blank

hard

Fill all three blanks to filter logs for pods with label 'app=frontend' in Stackdriver Logging.

GCP

resource.type="k8s_container" AND labels.k8s-pod/app=[1] AND resource.labels.namespace_name=[2] AND severity [3] "ERROR"

Drag options to blanks, or click blank then click option'

A"frontend"

B"default"

C>=

D"backend"

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong label values or namespaces.

Using incorrect severity operators like '=' instead of '>='.

The filter uses the label value "frontend", namespace "default", and severity operator >= to show errors and above.

Practice

1. What is the main purpose of enabling monitoring and logging in a GKE cluster?

easy

A. To deploy new applications faster

B. To increase the cluster's CPU and memory automatically

C. To watch the health and performance of your cluster and applications

D. To backup your cluster data to Google Drive

Solution

1. Step 1: Understand monitoring and logging roles

   Monitoring and logging help track the health, performance, and errors in your cluster and apps.

2. Step 2: Identify the correct purpose

   Increasing resources, faster deployment, or backups are unrelated to monitoring and logging.

3. Final Answer:

   To watch the health and performance of your cluster and applications -> Option C

4. Quick Check:

   Monitoring and logging = watch cluster health [OK]

Hint: Monitoring = watch health; logging = record events [OK]

Common Mistakes:

• Confusing monitoring with resource scaling
• Thinking logging backs up data
• Assuming monitoring deploys apps

2. Which command correctly enables Cloud Logging and Monitoring on an existing GKE cluster named my-cluster in zone us-central1-a?

easy

A. gcloud container clusters create my-cluster --zone us-central1-a --enable-logging --enable-monitoring

B. gcloud container clusters update my-cluster --zone us-central1-a --logging=SYSTEM,WORKLOAD --monitoring=SYSTEM

C. kubectl enable logging my-cluster --zone us-central1-a

D. gcloud container clusters update my-cluster --zone us-central1-a --enable-logs --enable-metrics

Solution

1. Step 1: Identify the correct update command syntax

   The gcloud container clusters update command uses flags --logging and --monitoring with values like SYSTEM and WORKLOAD.

2. Step 2: Check each option

   gcloud container clusters update my-cluster --zone us-central1-a --logging=SYSTEM,WORKLOAD --monitoring=SYSTEM uses correct flags and values. gcloud container clusters create my-cluster --zone us-central1-a --enable-logging --enable-monitoring is for creating clusters, not updating. kubectl enable logging my-cluster --zone us-central1-a is invalid syntax. gcloud container clusters update my-cluster --zone us-central1-a --enable-logs --enable-metrics uses wrong flags.

3. Final Answer:

   gcloud container clusters update my-cluster --zone us-central1-a --logging=SYSTEM,WORKLOAD --monitoring=SYSTEM -> Option B

4. Quick Check:

   Update cluster with --logging and --monitoring flags [OK]

Hint: Use 'gcloud container clusters update' with --logging and --monitoring [OK]

Common Mistakes:

• Using 'create' instead of 'update' to enable logging
• Wrong flag names like --enable-logs
• Trying to use kubectl for cluster logging setup

3. You run kubectl logs -l app=webserver on your GKE cluster. What output should you expect?

medium

A. Logs from all pods labeled with app=webserver

B. A list of pods with label app=webserver

C. An error saying label selector is invalid

D. Metrics data about the webserver pods

Solution

1. Step 1: Understand kubectl logs -l usage

   The -l flag selects pods by label, and kubectl logs shows their logs.

2. Step 2: Analyze the command output

   The command outputs logs from all pods matching app=webserver. It does not list pods or show metrics.

3. Final Answer:

   Logs from all pods labeled with app=webserver -> Option A

4. Quick Check:

   kubectl logs -l = logs from matching pods [OK]

Hint: kubectl logs -l shows logs from pods matching label [OK]

Common Mistakes:

• Expecting pod list instead of logs
• Confusing logs with metrics
• Thinking label selector syntax is invalid

4. You enabled Cloud Monitoring on your GKE cluster, but metrics do not appear in the Cloud Console. What is a likely cause?

medium

A. The cluster is in a different Google Cloud project

B. kubectl logs command was not run

C. Cloud Logging is disabled, so metrics cannot show

D. The cluster was updated with incorrect monitoring flags

Solution

1. Step 1: Check monitoring setup flags

   If monitoring flags were set incorrectly during cluster update, metrics won't appear.

2. Step 2: Evaluate other options

   kubectl logs does not affect metrics. Cloud Logging can be separate from Monitoring. Different project would cause access issues but not necessarily missing metrics if viewed correctly.

3. Final Answer:

   The cluster was updated with incorrect monitoring flags -> Option D

4. Quick Check:

   Incorrect monitoring flags block metrics [OK]

Hint: Check monitoring flags in cluster update command [OK]

Common Mistakes:

• Assuming kubectl logs affects metrics
• Confusing logging with monitoring
• Ignoring project or permissions issues

5. You want to monitor a custom application metric in your GKE cluster and view it in Cloud Monitoring. Which steps should you take?

hard

A. Instrument your app to expose metrics, deploy Prometheus, and configure Cloud Monitoring to scrape them

B. Enable Cloud Logging only and check logs for metric data

C. Use kubectl logs to collect metrics from pods and upload manually

D. Create a new GKE cluster with monitoring enabled and redeploy your app

Solution

1. Step 1: Instrument the application

   Custom metrics require your app to expose them, usually via Prometheus format.

2. Step 2: Deploy Prometheus and configure scraping

   Prometheus collects metrics from your app. Cloud Monitoring can integrate with Prometheus to display metrics.

3. Step 3: Understand other options

   Cloud Logging alone does not handle custom metrics. kubectl logs is for logs, not metrics. Creating a new cluster is unnecessary.

4. Final Answer:

   Instrument your app to expose metrics, deploy Prometheus, and configure Cloud Monitoring to scrape them -> Option A

5. Quick Check:

   Custom metrics need app instrumentation + Prometheus + Cloud Monitoring [OK]

Hint: Use Prometheus with app instrumentation for custom metrics [OK]

Common Mistakes:

• Relying on logs for metrics
• Thinking kubectl logs collects metrics
• Creating new cluster unnecessarily