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.

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.

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.