Log Insight

When vRealize Lifecycle Manager 1.2 was released recently, I was keen to get it installed in my lab, since I maintain several vRealize Automation deployments for development and testing, as well as performing upgrades. With vRLCM I can reduce the administrative overhead of managing the environments, as well as easily migrate content between environments (I’ll be blogging on some of these cool new features soon).

However, I hit a snag when I began to import my existing environment - I couldn’t get the vCenter data collection to run.

As promised, vROps Webinar Series 2017 is back with the second episode of the year. Last time around we looked closely into the features of vROps 6.5 and as stated during that webinar, we will now show you how you can unlock the full capabilities of vROps using the extensibility of the platform.

If you have been following the Webinar Series, by now you have a complete visibility into the capabilities of vROps, when it comes to monitoring the vSphere infrastructure. While this infrastructure is important for the IaaS provider, what business cares about is Applications. The good news is that vROps provides you an extensible platform which can be leveraged to extend the product capability into any area where metrics exist. This could be at the layers of your Software Defined Datacenter such as Compute, Network & Storage, or in the Application Stack and it’s tiers such as App, Web and DB.

So vROps 6.5 has been out for around a month now and I finally have a little while to write a post on what I personally really like.

There is a lot of great new enhancements and improvements added in 6.5 but for the sake of brevity I shall highlight two that I really liked.

Flexibility to increase RAM in between node sizes

So if you are familiar with vROps you will know that when you deploy it you have “T-Shirt” sizes to choose from, Small, Medium, Large and now Extra Large (6.5). However an additional extra in 6.5 is support to increase the memory allocation of your vROps nodes, you will not require additional CPU for the node until you hit the next node size bracket. If in doubt check the sizing guide spreadsheet VMware has provided so you can be sure on what you can and cannot do.

In this humble consultant’s opinion, Log Insight is one of the most useful tools in the administrator’s tool belt for troubleshooting vRealize Automation. I have lost count of the number of times I’ve been asked to help troubleshoot an issue that, when asked, people don’t know which log they should be looking at. The simple fact is that vRealize Automation has a lot of log files. Correlating these log sources to provide an overall picture is a painful, manual process - unless you have Log Insight!

I ran into this problem at a customer site where all the Log Insight nodes were changed due to some IP address conflicts. I think the problem occurred because the IP addresses were all changed and the VMs shut down, without time for the application to update the node IPs.

The symptoms:

• The web interface was down, a netstat -ano | grep -i “443” showed the service was listening
• _service loginsight status|restart|stop|start _hung and then timed out on the Master node
• The loginsight service was not running on the Worker nodes
• /var/log/loginsight/runtime.log contains warning messages about “Cassandra cluster not ready yet”

• Running /usr/lib/loginsight/application/lib/apache-cassandra-*/bin/nodetool status showed the two data nodes down (DN) and used the old IP address

All of the nodes were up with their new IP addresses, however Cassandra on the Master node was still looking for the old IP addresses for the Worker nodes. The Worker nodes were in a similar state, knowing their own new IP addresses but not being able to update the Master node because they didn’t have the Master node’s new IP address.