As part of the initial install of up.time, the Monitoring Station itself is setup as an element within up.time. This sample element is initially setup to use localhost as it's hostname, along with some sample Service Monitors to test the functionality of up.time itself.
One of these sample Service Monitors is the 'Default up.time data store' which tests up.time's ability to connect to it's MySQL database using the 'uptime@localhost' database user. The up.time 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 about '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 instead, it should now start succeeding again. If you are interested in why adding your vCenter into up.time 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 up.time is installed, is initially setup as an element via the localhost hostname.
2. When the vCenter is added into up.time, it goes through an auto-discovery process, which finds all the Virtual Machines(VM) and tries to create them as elements within up.time.
3. As part of this discovery process, up.time 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 up.time 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 up.time 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.