Automation Actions from Log Insight Alerts using Perl SDK

By | January 8, 2015

In a previous post, I talked about how my Log Insight server was getting spammed by some hosts that have these ‘ipmi’ errors. The temporary fix is to remote into the systems and run some commands. My colleague also found out that some of the commands could be cleared with PowerCLI.

The script was great, but we were getting annoyed that we would get an email alert and then would have to then open PowerCLI in order remediate the issue.

I looked for ways to automate actions based off of Log Insight alerts and found two articles:

Log Insight Alerts SNMP Scripts
Steve demonstrates how to awk the alerts file to get the hostname and the title of the alert and then ssh into the host. I don’t think the tail method that Steve used actually works though (it didn’t for me), I figured out a modified syntax that seemed to constantly tail the file correctly. SSH’ing into the host would work for me, but I would have to setup some ssh keys and sometimes for new hosts the ssh thumbprint changes after a rebuild and messes up things.

Quick Post: Launching Custom Actions on LogInsight Alerts
Matt demonstrates how to parse the alert file using Python/pyvmomi

Both of these assume that you want to run the scripts on the Log Insight server and not Windows.
I thought that maybe I could setup a samba share on the LI server and have the Windows server scrape the alert log file.
Another idea was to setup a nfs share on the LI server and have a Linux server with the Perl SDK on it.
A third idea was to have a script on the LI server scrape the log file and then push the content via FTP.

All of the ideas were either not possible given what was available on the LI server or weren’t very secure (FTP).

The whole reason I thought of option 2 was that I thought that the Perl SDK was not available on the LI server, but surprise surprise it is! The pyvmomi may be available as well, but I wasn’t as familiar with where that was installed to (I did install the Perl SDK).

UPDATE 01-09-2015:
I was installing the scripts on my three Log Insight server and one server DID NOT have the Perl SDK. The ones that did have it were originally installed as 1.0 and upgraded to 1.5, 2.0 and then 2.5. The one that DID NOT have it was the server that was installed as 2.0 and upgraded to 2.5. I will probably install the SDK on that last server at some point but I have reached out to someone from the Log Insight team to see if it is supposed to be there as a standard (so I can count on it in the future).

My approach is a hybrid of the two articles above, I have a bash script that runs forever, continously tailing the alert file (this runs as a service). The bash script scrapes the correct info and then passes it to a customized version of the perl script that is included with the Perl SDK. Note that these scripts are pretty rough, but in general it works


First script is /etc/init.d/monitoripmi
This is needed to start and stop the service (I looked at /etc/init.d/skeleton and /etc/init.d/loginsight)

Next script is the bash script that monitors the log file located in /usr/lib/vmware-vcli/apps/host/monitoripmi, note that I am matching the title of my alert.

Next is a snippet of what I added to (which I made a copy of and run as

I ran into an issue with Perl not liking my self-signed certs, in order to get around this you have to add the following to disable SSL verification using LWP:


One of the last things that you must do is to add the credentials for the Perl SDK to access your hosts with, repeat the following for all of the hosts that this script may touch:

/usr/lib/vmware-vcli/apps/general/ add -s HOSTNAME.FQDN -u root -p PASSWORD

To put this all together, you add monitpripmi as a service and then start it


Note, The first command looks at /etc/init.d/monitoripmi

Note that this may re-process some alerts that have already occurred. The python scripts mentioned on one of the other links used a python file monitor module, and I’m sure there is one for Perl as well. My goal though was to use ONLY what was already on the LI server (note I had to use sendmail since there was no mail command).

Overall, this was a nice introduction for me to the Perl SDK and got me back to my Unix/Linux roots. Hopefully launching custom actions or some sort of remediation engine is in the future for the vROPS suite.

Leave a Reply

Your email address will not be published. Required fields are marked *