B 100%

I think the correct answer is D https://cloud.google.com/architecture/best-practices-for-operating-containers#log_aggregator_sidecar_pattern Some applications can't be easily configured to write logs to stdout and stderr. Because such applications write to different log files on disk, the best way to handle them in Kubernetes is to use the sidecar pattern for logging. In this solution, you add a logging agent in a sidecar container to your application (in the same pod) and share an emptyDir volume between the two containers, as shown in this YAML example on GitHub. You then configure the application to write its logs to the shared volume and configure the logging agent to read and forward them where needed.

Deploy a Fluentd daemonset to GKE

Extremly happy I passed my Exam with 82.7%. I just followed the community answers (not the actual answers and cleared exam on 10th Nov2023). Latest update: Stackdriver Monitoring is now reflect as Cloud Monitoring due to the name change in GCP hence pls don't get confused in exam. Thanks to Examtopics and pass4surehub.com for helping me out!

To collect log entries from a specific file within each node in your GKE cluster, you can use a DaemonSet, Fluentd is often used as the logging agent for log forwarding in GKE.

Sidecar is expected here

Ans. is B. This solution is want to send log msg to the Stackdriver logging. However, C is possible IF we have a third party log collector like FluentD that monitoring STDOUT log from the cluster, but this question does not. Therefore, the answer must is B, because any content of container that write in files, we can scrape it in hosted worker node. It store in path /var/containers/* . If we create a customize tail path in the FluentD to monitor any path that store log content, we could use a STAR(*) operator to tell a plugins to find all folders that contain file named app_message.log .

B. Deploy a Fluentd daemonset to GKE. Then create a customized input and output configuration to tail the log file in the application's pods and write to Stackdriver Logging. Stackdriver Kubernetes Engine Monitoring provides log collection and analysis for Kubernetes clusters running on GKE out of the box, but the default configuration doesn't include the ability to tail a specific log file. To collect log entries written to /var/log/app_messages.log, you can deploy a Fluentd daemonset to your GKE cluster. Fluentd is a log collector and forwarder that can be configured to tail a specific log file, in this case, /var/log/app_messages.log and send the log entries to Stackdriver Logging. By deploying a Fluentd daemonset, you can create a customized input and output configuration, you can use this configuration to tail the log file in the application's pods and write to Stackdriver Logging, this allows you to collect the logs from that specific application, ensuring that the logs are going to stackdriver and can be analyzed later on.

The answer is D. Fluent D cannot read logs from files. https://kubernetes.io/docs/concepts/cluster-administration/logging/#sidecar-container-with-logging-agent By having your sidecar containers write to their own stdout and stderr streams, you can take advantage of the kubelet and the logging agent that already run on each node. The sidecar containers read logs from a file, a socket, or journald. Each sidecar container prints a log to its own stdout or stderr stream.

Ans: B Exam pased and taken on 19/12/2022, 50/50 from this dump without buying the full access.

Submitted B

i will go with B. flentd daemonset cannot collect logs from other pods , it collects logs from host filesystem ( stdout, stderr) https://cloud.google.com/architecture/best-practices-for-operating-containers#use_the_native_logging_mechanisms_of_containers

I think this should be D instead of B, and here's why: Installing a Fluentd daemonset will not solve your problem, as that logfile is not accessible by the Fluent pods. You'd need a sidecar to make the logfile accessible to another container, which will then be responsible for forwarding the logs to stdout. A daemonset will not do that, but a sidecar tailing the logs will.

Ans B. as the application is not writing to STDOUT or STDERR. Source for the answer - https://cloud.google.com/stackdriver/docs/solutions/gke/managing-logs Extract from this source relevant for the answer. GKE's default logging agent provides a managed solution to deploy and manage the agents that send the logs for your clusters to Cloud Logging. Depending on your GKE cluster master version, either fluentd or fluentbit are used to collect logs. Starting from GKE 1.17, logs are collected using a fluentbit-based agent. GKE clusters using versions prior to GKE 1.17 use a fluentd-based agent. If you want to alter the default behavior of the fluentdagents, then you can run a customized fluentd agent or a customized fluentbit agent. Common use cases include: removing sensitive data from your logs collecting additional logs not written to STDOUT or STDERR using specific performance-related settings customized log formatting

B is the answer. https://cloud.google.com/stackdriver/docs/solutions/gke/managing-logs#custom_agents GKE's default logging agent provides a managed solution to deploy and manage the agents that send the logs for your clusters to Cloud Logging. Depending on your GKE cluster master version, either fluentd or fluentbit are used to collect logs. Common use cases include: - collecting additional logs not written to STDOUT or STDERR - customized log formatting

B is correct https://cloud.google.com/architecture/customizing-stackdriver-logs-fluentd

D - Installing Fluentd is overkill