'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. |
Article InfoIndex: 592 OptionsQuick Links |
What should I monitor on a vCenter server? | Rating | Views | |
|---|---|---|---|
|
|
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 |
 
|
3654 |
vCenter 5 Compatibility with up.time | Rating | Views | |
|---|---|---|---|
|
|
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 |
|
1892 |
How to monitor Exchange with up.time | Rating | Views | |
|---|---|---|---|
|
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 |
|
12121 |
The up.time Data Collector is unavailable | Rating | Views | |
|---|---|---|---|
|
By: uptime Support | Date Created: 6-9-2006 | Last Modified: 10-17-2013 | Index: 077 |
|
6210 |
Problems adding an Agent to up.time | Rating | Views | |
|---|---|---|---|
|
By: uptime Support | Date Created: 6-15-2006 | Last Modified: 8-9-2011 | Index: 083 |
|
7973 |
