top of page
  • Brock Peterson

Pulling vCenter Events into Aria Operations

We've been pulling vCenter Events into Aria Operations for years, but I've never been able to determine exactly which ones, I finally found it! The vCenter Events imported into Operations by the vCenter Adapters can be found in a file called eventlist.txt which is located on your Primary Node (and Data Nodes) in /usr/lib/vmware-vcops/user/plugins/inbound/vmwarevi_adapter3/conf.


The file looks like this, some Events are commented out with a hashtag, these are not being collected.



The Events that are being collected are those that aren't commented out, ie those without hashtags in front of them, they look like this.



These events will generally have an Alert/Symptom combination defined against them as well, using the Message Event or Fault Symptoms. To know exactly what Event Types are being sent, map the Event in eventless.txt to its corresponding Event Type in describe.xml (same location). For example, the com.vmware.vc.HA.HostAgentErrorEvent is a Fault event type as shown here.

root@vr83-bpeterson [ /usr/lib/vmware-vcops/user/plugins/inbound/vmwarevi_adapter3/conf ]# cat describe.xml | grep -i HostAgentErrorEvent
            <ProblemEvent key="com.vmware.vc.HA.HostAgentErrorEvent" faultScore="100" nameKey="7545"/>
            <Condition type="fault" key="fault|host|ha" faultevent="com.vmware.vc.HA.HostAgentErrorEvent"/>

You can uncomment Events in this list to start importing them, be careful though, there are a lot of vCenter Events, importing all of them can affect performance and capacity. Let's uncomment this Event: vim.event.UserLoginSessionEvent.

##Session Events
#vim.event.SessionEvent
#       vim.event.AlreadyAuthenticatedSessionEvent
        vim.event.BadUsernameSessionEvent
#       vim.event.GlobalMessageChangedEvent
#       vim.event.NoAccessUserEvent
#       vim.event.ServerStartedSessionEvent
#       vim.event.SessionTerminatedEvent
        vim.event.UserLoginSessionEvent
#       vim.event.UserLogoutSessionEvent

Once adjusted you must cycle the Analytics Server on your Primary and Data Nodes by running "service analytics restart" on them. You will now start seeing these Events in Operations, I generally go to the object itself, Alerts, then Events to see if the Events are in fact being received.



There they are! Once you've confirmed the Events are in fact coming in, you can generate Alerts against them by defining Alert/Symptom combinations. When creating the Symptom be sure to select the Change event type, all new vCenter Events you uncomment in eventlist.txt will come in as Change event types as shown above.



Once your Symptom has been defined, you can define your Alert, mine looks like this.



Once defined, Alerts should be generated when these new vCenter Events are imported.



And there they are! A couple things to note: be careful what and how many vCenter Events you are bringing in, there can be a lot and Operations performance can be negatively affected. You will also note that they are canceled (and thus Inactive) almost immediately upon ingestion, though this is not consistent. The eventlist.txt needs to be maintained across Analytics Nodes and will be overwritten upon Operations upgrades, so beware.


If you ever want to turn off/on ingestion of vCenter Events at any time you can via Advanced Settings - Process Change Events in your vCenter Adapters. Documentation for this can be found here.




bottom of page