1Z0-997-25 Question 167
Single answerYou have a microservices application running on Oracle Container Engine for Kubernetes (OKE). You need to analyze sporadic performance issues by collecting and correlating logs from multiple containers in near real-time. Which approach should you use within the Oracle Cloud Infrastructure Observability platform to centralize and analyze those container logs at scale?
- A
Deploy a DaemonSet with the Oracle Fluentd plugin on each OKE node and configure a Service Connector from Logging to Logging Analytics.
- B
Install a custom log agent on each container to push logs directly to your on-premises logging solution.
- C
Store all container logs in local volumes on Kubernetes nodes and manually upload them to Object Storage at the end of the workweek for analysis.
- D
Collect logs only through the built-in node-level Linux system logs and rely on operating system metrics to troubleshoot container-specific issues.
Show answer and explanation
Correct answer: A
Explanation
For containerized workloads on OCI, the recommended approach is to deploy Fluentd on each node to capture logs and forward them to OCI Logging. From there, Service Connector Hub can automatically route logs to Logging Analytics, enabling real-time analysis and correlation across ephemeral containers. Refer to the Oracle Cloud Infrastructure documentation for best practices on setting up DaemonSets, Logging, and Logging Analytics integration.
- A. Correct.
Correct: Deploying a Fluentd DaemonSet on each OKE node to capture container logs, then leveraging OCI Logging and Service Connector Hub to forward those logs to Logging Analytics, is a recommended best practice. This enables centralized analysis, near real-time indexing, and rich log analysis for ephemeral containers.
- B. Incorrect.
Incorrect: While running a custom log agent inside each container might gather logs, it introduces unnecessary complexity and duplication. Also, pushing logs outside OCI bypasses native Observability features and can make correlation more difficult or add latency.
- C. Incorrect.
Incorrect: Manually uploading logs later is inefficient, complicates analysis of sporadic issues, and does not provide near real-time insights. You miss out on time-sensitive troubleshooting and automated correlation features offered by OCI Observability.
- D. Incorrect.
Incorrect: Relying only on node-level system logs typically omits container-level details and correlation, making troubleshooting container-specific issues more difficult. It also undermines the centralized view of logs that Observability provides.