GKE monitoring and logging in GCP - Mini Project: Build & Apply

GKE Monitoring and Logging Setup

📖 Scenario: You are managing a Google Kubernetes Engine (GKE) cluster for a small company. To keep the cluster healthy and troubleshoot issues quickly, you need to set up monitoring and logging using Google Cloud's operations suite.

🎯 Goal: In this project, you will enable monitoring and logging for your GKE cluster by configuring the necessary settings and verifying that logs and metrics are collected properly.

📋 What You'll Learn

Enable Google Cloud Monitoring and Logging for the GKE cluster

Configure the cluster to export logs to Cloud Logging

Verify that monitoring metrics are available

Verify that logs from pods are collected

💡 Why This Matters

🌍 Real World

Monitoring and logging are essential for running reliable applications on Kubernetes. This project shows how to set up these features on GKE to keep your cluster healthy and troubleshoot issues.

💼 Career

DevOps engineers and cloud administrators often configure monitoring and logging to maintain system health and respond quickly to problems in production environments.

1

Create a GKE cluster with monitoring enabled

Use the gcloud command to create a GKE cluster named monitoring-cluster in the us-central1 region with monitoring enabled by setting --enable-stackdriver-kubernetes.

GCP

# Use gcloud to create the cluster with monitoring enabled
# Your code here

Hint

The flag --enable-stackdriver-kubernetes enables both monitoring and logging integration for GKE.

2

Configure logging export to Cloud Logging

Set the cluster's logging service to logging.googleapis.com/kubernetes using the gcloud container clusters update command for the cluster monitoring-cluster in us-central1 region.

GCP

# Update the cluster to set logging service to Cloud Logging
# Your code here

Hint

Use gcloud container clusters update with the --logging-service flag to specify the logging destination.

3

Verify monitoring metrics are available

Use the gcloud command to list the monitoring metrics for the project and check for the metric kubernetes.io/container/cpu/usage_time.

GCP

# List monitoring metrics and check for CPU usage metric
# Your code here

Hint

Use gcloud monitoring metrics list with a filter to find the CPU usage metric.

4

Check logs from pods in Cloud Logging

Use the gcloud logging read command to read logs from the resource type k8s_container and filter by the cluster name monitoring-cluster. Print the first 5 log entries.

GCP

# Read and print first 5 pod logs from Cloud Logging
# Your code here

Hint

Use gcloud logging read with a filter for resource.type=k8s_container and limit the output to 5 entries.

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