Monitoring, logging, tracing, and troubleshooting
Domain 7 - Monitoring, logging, tracing, and troubleshooting
This domain tests how you find and diagnose a failed instance. The exam focuses on monitoring views, instance states, activity-level payloads, logs, and safe recovery.
Core rules
- The monitoring console shows integrations, instances, and errors. Filter by integration, time, status, and business identifier. Business identifiers and tracking variables make a specific order or customer searchable.
- Instance states include received, running, completed, failed, aborted, and waiting. A failed instance has an error at a specific activity; a waiting instance may be paused for a callback or approval.
- The activity stream shows each activity, its input and output payloads, and the error. Use it to locate the first failure, not the last cascade.
- Logs can be viewed in the service and exported to OCI Logging. Correlation IDs and tracking variables connect a caller's request to the integration instance.
- Recovery options include resubmit, abort, and, for asynchronous flows, callback recovery. Resubmit only when the operation is idempotent or you have corrected the cause.
Worked example
A scheduled integration fails at an ERP invoke. Open the instance, inspect the activity stream, and find HTTP 401 at the invoke. Test the ERP connection; the credential has expired. Update the credential, resubmit the instance, and confirm the activity stream shows a successful invoke. If the failure had been a schema validation error, resubmit would fail again until the mapping was fixed.
Traps
Do not debug only in the Designer; the runtime payload may differ. Do not resubmit a non-idempotent create without checking for a partial success. Do not ignore agent heartbeat or connection test failures. Do not rely on logs that have passed their retention period.