Collecting Custom Logs from Unmodifiable GKE Pods

PCDOE By islever Editorial Last updated

Managing and analyzing logs.

Short answer

B Deploy a Fluentd daemonset to GKE and create a customized input and output configuration to tail the log file in the application's pods and write to Stackdriver Logging.

Question

You have a set of applications running on a Google Kubernetes Engine (GKE) cluster, and you are using Stackdriver Kubernetes Engine Monitoring. You are bringing a new containerized application required by your company into production.
This application is written by a third party and cannot be modified or reconfigured.
The application writes its log information to /var/log/app_messages.log, and you want to send these log entries to Stackdriver Logging.
What should you do?
  1. Use the default Stackdriver Kubernetes Engine Monitoring agent configuration.
  2. 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. Correct Answer
  3. Install Kubernetes on Google Compute Engine (GCE) and redeploy your applications. Then customize the built-in Stackdriver Logging configuration to tail the log file in the application's pods and write to Stackdriver Logging.
  4. Write a script to tail the log file within the pod and write entries to standard output. Run the script as a sidecar container with the application's pod. Configure a shared volume between the containers to allow the script to have read access to /var/log in the application container.

Key Takeaways

The question tests the integration of third-party logs into Cloud Logging on GKE; the trap is assuming sidecars are required or default agents suffice, whereas Fluentd customization is the standard solution.

This page explains how to collect custom log files from unmodifiable containers in Google Kubernetes Engine using Stackdriver Logging. It establishes that deploying a customized Fluentd daemonset is the correct approach for tailing specific file paths.

Common mistake: Many candidates choose D (sidecar) because they believe it isolates the logging logic, but this adds unnecessary complexity and operational overhead compared to the managed Fluentd agent.

Expert Analysis

Why the Answer Is Correct

Deploying a Fluentd DaemonSet allows you to run a logging agent on every node, which can then be configured via ConfigMaps to tail specific files like /var/log/app_messages.log. This method works without modifying the application container itself, satisfying the requirement that the app cannot be reconfigured. The official documentation supports customizing the Fluentd configuration to ingest additional logs.

Why the Other Options Are Wrong

Option A fails because the default agent only collects standard streams (stdout/stderr) and known system logs, not arbitrary custom files. Option C is incorrect as it suggests reinstalling the cluster infrastructure unnecessarily. Option D involves creating a sidecar and shared volumes, which is more complex and harder to manage than using the centralized Fluentd agent provided by GKE's logging service.

Community Comment Notes

Community consensus strongly favors B, noting that "Fluentd is created specifically for extracting logs" and that customizing the input configuration is the intended path. Some users initially considered D but were corrected by references stating that "the practice way" is using the agent rather than ad-hoc scripts. Comments emphasize that B is less complex and officially supported for this exact scenario.

Official Reference

https://cloud.google.com/kubernetes-engine/docs/how-to/logging#customizing-fluentd-configuration

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

Exam Strategy

When asked about collecting non-standard logs in GKE, prioritize the Fluentd agent customization over sidecar patterns unless isolation is explicitly mandated. Remember that DaemonSets ensure coverage across all nodes automatically.

Frequently Asked Questions

Why not use a sidecar container for logging?

Sidecars add complexity and require shared volumes. Fluentd DaemonSets are the native, scalable way to collect custom logs in GKE without touching the app container.

Can the default Stackdriver agent read custom files?

No, the default agent only captures stdout/stderr and predefined system logs. You must customize the Fluentd configuration to tail new file paths.

More PCDOE FAQ →

Community Votes

B
65%
D
35%

65% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 38 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 30 of 38

  1. francisco_guerra 👍 6
    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.
  2. muhasinem 👍 6
    B is correct.
  3. WakandaF 👍 4
    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
  4. syslog 👍 4 Answered B
    Because Fluentd is created specifically for extracting logs. https://docs.fluentd.org/input/tail
  5. lakiluk 👍 4 Answered D
    D is the correct answer don't get fooled.
Show 25 more comments
  1. singularis 👍 3 Answered D
    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.
  2. wences 👍 3 Answered B
    D seems doable but is like lots of effort, B seems like less complex I will dare to say B, I like D because application won't have a clue of anything and no need to cahnge it at all.
  3. Manh 👍 3
    Answer is B. D sounds good, the practice way. But the question is mention about sending log to Cloud Logging but D is just send log to shared disk
  4. dobby_elf 👍 3 Answered D
    D - Installing Fluentd is overkill
  5. akg001 👍 3
    Agree. answer should be D.
  6. Ananda 👍 3 Answered B
    Submitted B in the exam
  7. notjoost 👍 2 Answered D
    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.
  8. saminlo 👍 2
    just my thought process for choosing D over B (not sure if that's correct): if there are multiple such app containers that write logs to a non-standard location then you'd have to create a custom fluentd input config for each app. Using a sidecar and running it in the same pod as the app container makes more sense since you're 'bundling' related piece of code together.
  9. raf2121 👍 2
    Point for discussion : Is B the right answer ? When I was going through training content in Coursera, I read "Dont install Logging Agent in GKE nodes, as GKE are automatically enabled for Logging" Considering this, Is D the right answer
  10. Jason_Cloud_at 👍 2 Answered B
    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.
  11. AzureDP900 👍 2
    B is correct https://cloud.google.com/architecture/customizing-stackdriver-logs-fluentd
  12. galkin 👍 2 Answered D
    Sidecar is expected here
  13. devopsbatch 👍 2
    D i think..
  14. ralf_cc 👍 2
    B it is.
  15. alaahakim 👍 2
    Ans: B
  16. bartrek 👍 1 Answered D
    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.
  17. DoodleDo 👍 1
    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
  18. Watcharin_start 👍 1
    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 .
  19. mohan999 👍 1
    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.
  20. BlackCoffee 👍 1 Answered D
    Why B is the correct approach: By default, Google Kubernetes Engine (GKE) and Stackdriver (Google Cloud Logging) automatically collect everything written to the standard output (stdout) and standard error (stderr) streams of your containers. They do not scan random file paths inside a container like /var/log/app_messages.log. The Sidecar Pattern: Because you cannot modify the third-party application to write to stdout, the standard Kubernetes solution is to use a logging agent sidecar container.
  21. pyc 👍 1
    It should be D. Each sidecar container could tail a particular log file from a shared volume and then redirect the logs to its own stdout stream. https://kubernetes.io/docs/concepts/cluster-administration/logging/ B sounds good, however, /var/log is not in the application pods IMHO. Please correct me if I am wrong here.
  22. hanweiCN 👍 1
    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
  23. kapara 👍 1 Answered B
    GCP is not using fluentBit (and not fluent anymore) and it logs application data via STDOUT and STDERR, meaning you need to tail your app log to see it on CloudLogging. https://cloud.google.com/stackdriver/docs/solutions/gke/managing-logs#custom_agents
  24. knightus 👍 1 Answered D
    a sidecar container is the cleanest and most GKE-native solution to forward application logs from a file to Stackdriver.
  25. HunkyBunky 👍 1 Answered B
    I guess that this should be B, because it looks much robust that a D option

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