When an application being managed by UCP fails, you would like a summary of all requests made to the UCP API in the hours leading up to the failure.
What must be configured correctly beforehand for this to be possible?
When an application being managed by UCP fails, you would like a summary of all requests made to the UCP API in the hours leading up to the failure.
What must be configured correctly beforehand for this to be possible?
The correct answer is: A. UCP audit logs must be set to the ‘metadata’ or ‘request’ level. Explanation: To capture a summary of all requests made to the UCP (Universal Control Plane) API leading up to a failure, UCP audit logs must be enabled at the appropriate level. The metadata level records request metadata, while the request level provides detailed information about each API request. These logs enable you to trace API activity and diagnose the issue. B. Incorrect: Log driver settings for the engines in the cluster are unrelated to UCP audit logs, as they are for container logs, not API logs. C. Incorrect: UCP logging levels (e.g., info or debug) control the verbosity of general logs but do not provide detailed API request traces. D. Incorrect: Changing the logging level for the ucp-kube-api-server affects Kubernetes API logs, not the UCP API logs.
UCP (Universal Control Plane) audit logging is a feature that records all API requests made to the UCP controllers. To be able to review API requests made before a failure: You need audit logging enabled The logging level must be set to either 'metadata' or 'request' 'Request' level provides the most detailed information
Summary of UCP Logging Levels: debug: Very detailed logs for troubleshooting. info: General information, default for most environments. warn: Warnings about potential issues. error: Errors that affect functionality. fatal: Critical failures preventing operation. as per ChatGPT
Should be C 'metadata' and 'request' are not log levels