As part of the initial install of Uptime Infrastructure Monitor, the Monitoring Station itself is setup as an element within Uptime Infrastructure Monitor. This sample element is initially setup to use localhost as it's hostname, along with some sample Service Monitors to test the functionality of Uptime Infrastructure Monitor itself.

One of these sample Service Monitors is the 'Default up.time data store' which tests Uptime Infrastructure Monitor's ability to connect to its MySQL database using the uptime@localhost database user. The Uptime Infrastructure Monitor database user is created with limited permissions that only allow it to connect from localhost.

If the 'Default up.time data store' Monitor starts failing with an error, Could not connect to database, check monitor settings, the solution is to edit the Service Monitor, and change the account used to connect to the reports user instead, which has permissions to connect to the database from anywhere.

The credentials for the reports user are:

username: reports
password: reports

After updating the Service Monitor to use the reports account, it should now start succeeding again. If you are interested in why adding your vCenter into Uptime Infrastructure Monitor would cause this seemingly unrelated service monitor to start failing, here's the general chain of events that happens:

  1. As mentioned above, the server where Uptime Infrastructure Monitor is installed, is initially setup as an element via the localhost hostname.
  2. When the vCenter is added into Uptime Infrastructure Monitor, it goes through an auto-discovery process, which finds all the Virtual Machines(VM) and tries to create them as elements within Uptime Infrastructure Monitor.
  3. As part of this discovery process, Uptime Infrastructure Monitor will compare the new VMs against any elements it's already monitoring. This is done by looking at the VMware UUID assigned to each VM by the vCenter. If Uptime Infrastructure Monitor finds an element that it's already monitoring is a VM on the vCenter, then they'll be merged to prevent duplication. As part of this merger, the existing element will be updated to use the hostname assigned to the VM by the vCenter.
  4. So in situations where Uptime Infrastructure Monitor is running from within a VM on the vCenter, it's default localhost element will be updated with the hostname assigned to it by the vCenter. As a result the 'Default up.time data store' will now be trying to connect with the uptime@myVMshostname instead of the uptime@localhost as explained above.
  5. So this change in the element's hostname during the vCenter discovery process, is what causes the Service Monitor to start failing.