Monitoring, Reporting, and Troubleshooting
Monitoring proves the platform works; troubleshooting narrows from target to topology to policy to action, in that order.
Where to look
- Dashboards and the Overview page for market health, utilization, and pending actions; entity pages for physical and virtual utilization charts.
- Notifications: configure the mail server and recipients for action failures, target status changes, and license events; use webhooks, chat, or ticketing for team routing.
- Reports: built-in cloud cost, rightsizing, capacity, and chargeback/showback reports can be scheduled, emailed, and exported.
- Audit: Action History and user activity answer who changed what, and whether it ran.
Troubleshooting order
- Target status and probe errors: credentials, ports, time skew.
- Entity discovery and supply chain stitching: are the right entities present and linked?
- Policy and constraints: is the action allowed, and is a group scoped oddly?
- Execution: orchestrator errors, permissions, change windows.
- Platform health: component status, logs, disk, certificate expiry, then a support bundle for support.
Worked example
After adding a target, no recommendations appear for its VMs. Reasoning: automation mode does not hide recommendations, since Recommend and Automated both generate them, so look at data first. Check the last discovery time and probe errors; time skew from a bad NTP source is a classic cause of failed validation and stale topology.
Traps
Reading logs before checking target status; assuming no recommendations means automation is off; forgetting that report generation depends on the reporting component, not the market engine.