Bird
Raised Fist0
GCPcloud~5 mins

GKE monitoring and logging in GCP - Cheat Sheet & Quick Revision

Choose your learning style10 modes available
Recall & Review
beginner
What is the main purpose of monitoring in GKE?
Monitoring in GKE helps track the health and performance of your Kubernetes clusters and workloads by collecting metrics and alerts.
Click to reveal answer
beginner
Which Google Cloud service is commonly used for logging in GKE?
Google Cloud Logging (formerly Stackdriver Logging) collects and stores logs from GKE clusters for analysis and troubleshooting.
Click to reveal answer
intermediate
How does GKE export metrics for monitoring?
GKE exports metrics to Google Cloud Monitoring, where you can create dashboards and alerts based on cluster and workload data.
Click to reveal answer
intermediate
What is the role of Fluentd in GKE logging?
Fluentd is an open-source log collector used in GKE to gather container logs and send them to Cloud Logging.
Click to reveal answer
beginner
Name two key benefits of using Cloud Monitoring with GKE.
1. Real-time visibility into cluster health and performance. 2. Ability to set alerts to detect and respond to issues quickly.
Click to reveal answer
Which service collects logs from GKE clusters?
ACloud Storage
BCloud Functions
CCloud Logging
DCloud SQL
What tool does GKE use to collect container logs before sending them to Cloud Logging?
APrometheus
BFluentd
CGrafana
DKubelet
Where can you create dashboards to visualize GKE metrics?
ACloud IAM
BCloud Build
CCloud Run
DCloud Monitoring
What type of data does GKE monitoring primarily collect?
AMetrics and alerts
BUser data
CSource code
DLogs only
Which of these is NOT a benefit of GKE monitoring and logging?
AImproving cluster security by default
BDetecting cluster issues early
CVisualizing workload performance
DTroubleshooting application errors
Explain how GKE uses Cloud Monitoring and Cloud Logging to maintain cluster health.
Think about metrics for performance and logs for troubleshooting.
You got /4 concepts.
    Describe the process of collecting and viewing logs from containers in a GKE cluster.
    Focus on the flow from container to log viewer.
    You got /4 concepts.

      Practice

      (1/5)
      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
      Recommended

      Ready to prove it?

      Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

      10 questions~5 mineasy hard