Minimizing GKE Logging Costs with SYSTEM Mode

PCDOE By islever Editorial Last updated

Implementing FinOps practices for optimizing resource utilization and costs.

Short answer

A Run the gcloud container clusters update --logging=SYSTEM command for the development cluster.

Question

Your company runs services by using Google Kubernetes Engine (GKE). The GKE dusters in the development environment run applications with verbose logging enabled. Developers view logs by using the kubectl logs command and do not use Cloud Logging. Applications do not have a uniform logging structure defined. You need to minimize the costs associated with application logging while still collecting GKE operational logs. What should you do?
  1. Run the gcloud container clusters update --logging=SYSTEM command for the development cluster. Correct Answer
  2. Run the gcloud container clusters update --logging=WORKLOAD command for the development cluster.
  3. Run the gcloud logging sinks update _Default --disabled command in the project associated with the development environment.
  4. Add the severity >= DEBUG resource.type = "k8s_container" exclusion filter to the _Default logging sink in the project associated with the development environment.

Key Takeaways

The question tests the difference between SYSTEM and WORKLOAD logging modes in GKE, specifically targeting the cost optimization aspect of operational logging.

This page explains how to configure Google Kubernetes Engine (GKE) logging to minimize costs by disabling workload log ingestion while retaining essential operational logs.

Common mistake: Many learners choose Option D, attempting to filter logs via exclusion sinks, but this is often less efficient or incorrect because it doesn't prevent the initial collection/ingestion overhead at the source as effectively as changing the cluster logging mode.

Expert Analysis

Why the Answer Is Correct

Option A is correct because setting --logging=SYSTEM instructs GKE to stop sending application (workload) logs to Cloud Logging while continuing to send system logs (such as node, control plane, and Kubernetes system logs). Since developers use kubectl logs directly from the nodes, they can still access application logs locally without incurring Cloud Logging storage and ingestion costs for those verbose outputs. This directly addresses the requirement to minimize costs while collecting GKE operational logs.

Why the Other Options Are Wrong

Option B (--logging=WORKLOAD) would disable system logs and enable only workload logs, which increases costs due to the verbose application logs mentioned in the scenario. Option C disables the default sink entirely, which would also drop critical system logs needed for operations. Option D attempts to filter logs using an exclusion rule; however, filtering at the sink level occurs after logs are ingested, meaning you still pay for ingestion and analysis of the unwanted logs, whereas Option A prevents them from being sent to Cloud Logging in the first place.

Community Comment Notes

Community consensus strongly favors Option A. As user 'cachopo' noted, "The --logging=SYSTEM option disables workload logging... while keeping GKE system logs." Another commenter, 'BlackCoffee', highlighted that "exclusion filters are evaluated at the log router level," implying higher overhead compared to source-level configuration. User 'GP123123' initially debated A vs D but acknowledged the official guidance on available logs supports the SYSTEM approach for operational needs.

Official Reference

https://cloud.google.com/kubernetes-engine/docs/concepts/about-logs#available-logs

This link opens the official vendor documentation in a new tab.

Exam Strategy

Always distinguish between preventing log generation/collection (source-level config like --logging=SYSTEM) versus filtering logs after ingestion (sink-level exclusions). Source-level prevention is typically more cost-effective for high-volume noisy logs.

Frequently Asked Questions

Why not use an exclusion filter instead of changing the logging mode?

Exclusion filters run after logs are ingested into Cloud Logging, so you still pay for ingestion and analysis. Changing the mode to SYSTEM prevents the logs from being sent at all.

Does --logging=SYSTEM affect developer ability to view logs?

No, developers can still use kubectl logs to view application logs directly from the GKE nodes, as these logs remain on the local filesystem even if not exported to Cloud Logging.

More PCDOE FAQ →

Discussion 14 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 14

  1. Jason_Cloud_at 👍 4 Answered D
    right answer
  2. GP123123 👍 3 Answered A
    I am torn between A and D. With D's approach, in addition to DEBUG, messages such as INFO and WARNING may also be retained. For option A, the question does not explicitly define what operational logs should include. According to https://cloud.google.com/kubernetes-engine/docs/concepts/about-logs#available-logs, in addition to System and Workloads, there should also be API server, Scheduler, and Controller manager. Considering the lowest cost and the ability to view logs via kubectl, I ultimately chose option A.
  3. cachopo 👍 3 Answered A
    • The --logging=SYSTEM option disables workload logging (application logs) while keeping GKE system logs (like node, control plane, and Kubernetes system logs). - This helps reduce costs by not storing verbose application logs while still collecting critical GKE operational logs for monitoring. - Since developers use kubectl logs, they can still see logs without needing Cloud Logging.
  4. lelele2023 👍 3 Answered D
    D The idea is to prevent/minimize container logs from getting sent to the sink,
  5. asdasdfczxhjkvz 👍 2 Answered A
    A is correct
Show 9 more comments
  1. xhilmi 👍 1 Answered D
    To minimize costs associated with application logging in Google Kubernetes Engine (GKE) while still collecting operational logs, the recommended approach is (option D). Add the severity >= DEBUG resource.type = "k8s_container" exclusion filter to the _Default logging sink in the project associated with the development environment. This filter excludes logs with a severity level of DEBUG or lower for the specified resource type, "k8s_container," effectively reducing the volume of verbose application logs being ingested into Cloud Logging. This allows you to focus on collecting GKE operational logs while excluding less critical and potentially costly application logs. It helps strike a balance between maintaining visibility into operational aspects and optimizing costs associated with log storage and processing.
  2. cachopo 👍 1
    Why not the other options? B. --logging=WORKLOAD disables system logs but keeps workload logs (application logs). - This increases costs because verbose application logs continue being collected in Cloud Logging. C. - This completely disables all logging, including GKE system logs, which is not recommended because operational logs are needed for debugging and monitoring. D. - This filters logs based on severity but still keeps some workload logs, not fully disabling application logging. - Also, not all logs use severity labels, so some logs may still be ingested, leading to unnecessary costs.
  3. SahandJ 👍 1
    I just realised I completely misunderstood the question. For some reason I had the notion in my head that the Developers were to migrate to Cloud Logging as well and that not only do we need to minimize cost, but also remove redundant logs (like system logs) in Cloud Logging. However, obviously, the only requirement is to minimize costs for cloud logging. The devs are already reading the logs directly using kubectl. As such we want to remove as much logging as possible from the _Default bucket. Therefore (D) is the correct answer!
  4. SahandJ 👍 1 Answered B
    Not sure I agree with any answers. But I disagree the least with A. A) Would send all the logs, including memory, CPU, and other system information. This is too verbose. B) WORKLOAD logs should be sufficient I believe C) Not sure disabling _Default helps here D) An exclusion filter of "severity >= DEBUG..." would literally exclude all logs?
  5. BlackCoffee 👍 1 Answered A
    D is incorrect exclusion filters are evaluated at the log router level. Depending on your configuration, you may still incur log ingestion analysis overhead, and managing filters is more complex and prone to errors than simply telling GKE not to send application logs at the cluster level.
  6. cachopo 👍 1
    By choosing A, you ensure that GKE system logs are collected while stopping application logs from being stored, minimizing logging costs without impacting developers' ability to use kubectl logs
  7. lelele2023 👍 1
    C is invalid since a valid gcloud CLI will be: gcloud logging settings update --folder=FOLDER_ID--disable-default-sink https://cloud.google.com/logging/docs/default-settings#disable-default-sink
  8. Luu13 👍 1
    If the filter in the exclusion filter is for severity >= DEBUG... would not exclude severity >= DEBUG instead of severity <= DEBUG?
  9. SahandJ 👍 1
    I meant to say that I disagree the least with B as my selected answer

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Binary Authorization Attestor Implementation

S-grade

GKE Cluster and Namespace Design for Data Isolation

S-grade

Granting Log Export Permissions in Google Cloud

S-grade

Optimizing SLO Balance Between Reliability and Velocity

S-grade

Practice All PCDOE Questions

Access 75 questions with complete answers and detailed explanations.

View Full PCDOE Practice Test →

← Back to PCDOE Study Guide