GKE monitoring and logging in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding GKE Monitoring Components

Which component in Google Kubernetes Engine (GKE) is primarily responsible for collecting cluster metrics and sending them to Cloud Monitoring?

A Cloud Trace Collector

B Cloud Logging Agent

C Kubelet Metrics Server

D Stackdriver Kubernetes Monitoring Agent

💡 Hint

Think about the agent that collects metrics specifically for monitoring purposes.

The Stackdriver Kubernetes Monitoring Agent collects cluster and node metrics and sends them to Cloud Monitoring. The Cloud Logging Agent handles logs, Kubelet Metrics Server provides metrics but is not the main agent for Cloud Monitoring, and Cloud Trace Collector is for tracing.

💻 Command Output

intermediate

Output of kubectl command for logs

What is the output of the following command when run on a GKE cluster?

kubectl logs -n kube-system -l k8s-app=kube-dns --tail=2

A Shows the last 2 log lines from all pods labeled k8s-app=kube-dns in kube-system namespace

B Shows logs only from the first pod found with label k8s-app=kube-dns

C Returns an error because --tail cannot be used with label selector

D Shows logs from all namespaces for pods labeled k8s-app=kube-dns

💡 Hint

Consider how kubectl logs works with label selectors and the --tail option.

The command fetches logs from all pods matching the label in the specified namespace and shows the last 2 lines of each pod's logs. It does not return an error and does not limit to only one pod.

❓ Configuration

advanced

Configuring Fluentd for Custom Log Routing

You want to configure Fluentd on GKE to route logs from a specific namespace to a custom Cloud Logging log bucket. Which configuration snippet correctly sets the match directive for logs from namespace custom-ns?

A

<match kubernetes.**>
  @type google_cloud
  <buffer>
    @type memory
  </buffer>
  <filter>
    @type grep
    <regexp>
      key $.kubernetes.namespace_name
      pattern ^custom-ns$
    </regexp>
  </filter>
</match>

B

<match kubernetes.var.log.containers.*custom-ns*.log>
  @type google_cloud
</match>

C

<match kubernetes.**>
  @type google_cloud
  <filter kubernetes.namespace_name>
    @type grep
    <regexp>
      key $.kubernetes.namespace_name
      pattern ^custom-ns$
    </regexp>
  </filter>
</match>

D

<match kubernetes.**>
  @type google_cloud
  <filter kubernetes.namespace_name custom-ns>
  </filter>
</match>

💡 Hint

Focus on the match directive pattern that filters logs by namespace in Fluentd.

Option B correctly matches log files from containers in the custom-ns namespace by using the log file path pattern. Other options misuse filter inside match or have invalid syntax.

❓ Troubleshoot

advanced

Troubleshooting Missing Metrics in Cloud Monitoring

You notice that your GKE cluster metrics are not appearing in Cloud Monitoring. Which of the following is the most likely cause?

A Cloud Logging API is disabled in the GCP project

B The cluster nodes do not have sufficient CPU resources

C The Stackdriver Kubernetes Monitoring Agent DaemonSet is not running on the nodes

D The Kubernetes API server is down

💡 Hint

Think about the component responsible for sending metrics to Cloud Monitoring.

If the Stackdriver Kubernetes Monitoring Agent DaemonSet is not running, metrics won't be collected or sent to Cloud Monitoring. CPU resources or Cloud Logging API do not directly affect metrics collection, and the API server being down would cause broader issues.

✅ Best Practice

expert

Best Practice for Secure Logging in GKE

Which practice is best to ensure logs collected from GKE workloads are securely transmitted and stored in Cloud Logging?

A Enable TLS encryption for Fluentd agents and use IAM roles with least privilege for log writing

B Store logs locally on nodes and periodically upload them to Cloud Storage without encryption

C Disable Cloud Logging API and use third-party logging tools without encryption

D Use plaintext HTTP to send logs to Cloud Logging for faster transmission

💡 Hint

Consider encryption and access control best practices for cloud logging.

Enabling TLS encryption ensures logs are securely transmitted. Using IAM roles with least privilege limits access to logs. Storing logs unencrypted or disabling Cloud Logging API reduces security. Sending logs over plaintext HTTP is insecure.

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