article 'Default up.time data store' monitor crit after adding a vCenter to up.time

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.

Related Articles

What should I monitor on a vCenter server?


In general the following approach is recommended for monitoring the health of your vCenter installations: - Install an agent on the vCenter server to monitor it’s overall performance and system...

By: uptime Support | Date Created: 8-18-2010 | Last Modified: 8-13-2011 | Index: 487


vCenter 5 Compatibility with up.time


vCenter 5 Compatibility with up.time VMware has released update 1 for vCenter 5 that addresses some vCenter instability issues and improves up.time monitoring consistency.  The official name for...

By: uptime Support | Date Created: 7-12-2012 | Last Modified: 7-14-2012 | Index: 579


How to monitor Exchange with up.time


Monitoring the performance of your Exchange infrastructure is critical to ensure that your users are receiving the best experience possible from your mail services. Find out how easy it is to...

By: uptime Support | Date Created: 5-17-2007 | Last Modified: 6-29-2011 | Index: 175


The up.time Data Collector is unavailable


By: uptime Support | Date Created: 6-9-2006 | Last Modified: 10-17-2013 | Index: 077


Problems adding an Agent to up.time


By: uptime Support | Date Created: 6-15-2006 | Last Modified: 8-9-2011 | Index: 083


User Comments

No comments have been posted.

Copyright © 2021 IDERA, Inc.   Legal   Privacy Statement