You have an application running on Google Kubernetes Engine (GKE). The application is currently using a logging library and is outputting to standard output. You need to export the logs to Cloud Logging, and you need the logs to include metadata about each request. You want to use the simplest method to accomplish this. What should you do?
In Google Kubernetes Engine (GKE), container logs are automatically collected and sent to Cloud Logging if they are written to standard output (stdout). Updating your application to output logs in JSON format and including the necessary metadata in the JSON is the simplest method to ensure that Cloud Logging captures the needed metadata without other configuration. Since GKE already captures stdout and forwards it to Cloud Logging, this approach avoids the complexity of changing the logging library or managing additional agents.
The answer is B since GKE is integrated with Cloud Logging by default. "By default, GKE clusters are natively integrated with Cloud Logging (and Monitoring). When you create a GKE cluster, both Monitoring and Cloud Logging are enabled by default." "GKE deploys a per-node logging agent that reads container logs, adds helpful metadata, and then sends the logs to the logs router, which sends the logs to Cloud Logging and any of the Logging sink destinations that you have configured. Cloud Logging stores logs for the duration that you specify or 30 days by default. Because Cloud Logging automatically collects standard output and error logs for containerized processes, you can start viewing your logs as soon as your application is deployed." Source: https://cloud.google.com/blog/products/management-tools/using-logging-your-apps-running-kubernetes-engine
Option D, installing the Fluent Bit agent on each of your GKE nodes, is not the most straightforward method for exporting logs to Cloud Logging, as it requires manual configuration and management of the Fluent Bit agent. While Fluent Bit can be used to collect and forward logs to Cloud Logging, it is typically used for more complex logging scenarios where custom log processing is required. Using the Cloud Logging library, as described in Option A, is a simpler and more direct method for exporting logs to Cloud Logging, as it eliminates the need to manage an additional log agent and provides a more integrated solution for logging in a GKE environment.
took my exam yesterday (01-03-2023) and this question was there
I will go for B. In Google Kubernetes Engine (GKE), the standard output (stdout) of containers is automatically sent to Cloud Logging. This means that if your application in GKE prints logs to standard output, these logs will be captured and can be viewed in Cloud Logging without additional configuration. And if the logs are in JSON is better for processing. Option A is irrelevant because the logs have been sent already to cloud logging via standar output.
https://cloud.google.com/run/docs/logging#container-logs
Answer A not D
https://cloud.google.com/blog/products/management-tools/using-logging-your-apps-running-kubernetes-engine
When you write logs from your service or job, they will be picked up automatically by Cloud Logging so long as the logs are written to any of these locations: Standard output (stdout) or standard error (stderr) streams Any files under the /var/log directory syslog (/dev/log) Logs written using Cloud Logging client libraries, which are available for many popular languages https://cloud.google.com/run/docs/logging#container-logs
https://cloud.google.com/stackdriver/docs/solutions/gke/managing-logs#what_logs
to log request metadata https://cloud.google.com/logging/docs/reference/libraries#write_request_logs
The key here is "use the simplest method to accomplish this...", using Cloud logging library is a very simple and straight forward solution. If the app is running on the single and multiple VMs in a instance group, then installing the cloud logging agent must be the correct answer. This environment is GKE cluster and separate some normal VM workflow.
How is it simpler to change every logging statement to use a different library rather than configuring the existing one to ouput in JSON and automatically append context metadata? I'd go for B
B for me: we're looking for the simplest method and I feel it's easier to configure the existing library to output JSON and include some context metadata rather than changing every log statement to use Cloud Logging library.
since we need to update the application, the best solution between A, B and C is A.
Enhanced Metadata: The Cloud Logging library can automatically include valuable metadata about each request, such as request ID, user agent, and resource information. why not B. Update your application to output logs in JSON format, and add the necessary metadata to the JSON: While this is possible, it requires more manual effort to format logs and ensure all the necessary metadata is included.
B is correct because it’s the easiest way to get a rich format into Cloud Logging. GKE automatically forwards logs sent to stdout to Cloud Logging. As long as it has the right JSON format, Cloud Logging will ingest the rich message
answer from google practice exam
Feedback B is correct because it’s the easiest way to get a rich format into Cloud Logging. GKE automatically forwards logs sent to stdout to Cloud Logging. As long as it has the right JSON format, Cloud Logging will ingest the rich message A is not correct because it would require a lot of extra work to replace the library, and replicate the extra information (such as pod name) that the GKE logs exporter automatically provides. D is not correct because this is only needed for pods (normally special/privileged pods) that write directly to the GKE file system. C is not correct because Cloud Logging doesn’t support ingesting CSV.