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?
To minimize the costs associated with application logging while still collecting GKE operational logs, you should add an exclusion filter to the _Default logging sink that filters out less critical logs. Adding the severity >= DEBUG resource.type = 'k8s_container' exclusion filter to the _Default logging sink in the project would exclude verbose application logs (which are typically of lower severity like DEBUG) from being ingested into Cloud Logging. This approach reduces the volume of application logs ingested, consequently minimizing costs, while still retaining important operational logs.
right answer
D The idea is to prevent/minimize container logs from getting sent to the sink,
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
A is correct
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.
If the filter in the exclusion filter is for severity >= DEBUG... would not exclude severity >= DEBUG instead of severity <= DEBUG?
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?
I meant to say that I disagree the least with *B* as my selected answer
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!