Exam Professional Cloud DevOps Engineer topic 1 question 4 discussion

Ans is B Besides the list of default logs that the Logging agent streams by default, you can customize the Logging agent to send additional logs to Logging or to adjust agent settings by adding input configurations. The configuration definitions in these sections apply to the fluent-plugin-google-cloud output plugin only and specify how logs are transformed and ingested into Cloud Logging.

B is correct.

So in general we have a process running in a pod that opens a local file (inside the pod). Answer B does not mention volume (regardless of a type). As far as i know fluentd is not capable of accessing other pod's files unless hostpath or rwx storage is configured (shared storage). The answer does not mention that however even if this is mentioned this would not be a good choice as this way would easily lead into a log corruption when application is started in more than one replica. You may also ask yourself a question: is it right to deploy a daemonset in order to cover an edge-case? Is it good to taint the hosts with a hostpath volume? In my opinion D is the least effort solution, utilizes existing mechanisms, does not break scaling nor taints the gke hosts. Application would have to support external log truncation (open the logfile in append mode) in order to prevent infinite file growth. Regardless if you decide to use tail -f or fluentd sidecar this method will prevent log from being corrupted and will play nice with horizontal pod autoscaling. It would be interesting if someone decides to use init container - symlinking logfile to /dev/stdout (or similar) before the main container pod is started.

I think it should be D, because its says you have a set of applications already running on a Google Kubernetes Engine (GKE) cluster, and you are using Stackdriver Kubernetes Engine Monitoring. I believe we should not enable the workload logging if we were to use the custom agent - So, now just for one new application, it does not make any sense to disable the default stackdriver setting on GKE and use the custom agent for all application logging. So, D would be correct option in this context since we are only customizing this for one application.

I believe that is B, This tutorial describes how to customize Fluentd logging for a Google Kubernetes Engine cluster. You'll learn how to host your own configurable Fluentd daemonset to send logs to Cloud Logging, instead of selecting the cloud logging option when creating the Google Kubernetes Engine (GKE) cluster, which does not allow configuration of the Fluentd daemon

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. 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.

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 .

Sidecar is expected here

Deploy a Fluentd daemonset to GKE

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.

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.

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.

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