engine.conf settings

This topic describes the settings you can use in engine.conf and the values you can assign to them to determine what data is actually collected from your resources.

fa

Setting	fa
Required	no
Value	any value, for example a unique name, a short or long DNS hostname, or an IP address
Default value	IP address of the FA.
syntax	fa = <unique name of FA instance>
Description	This is the unique name for this specific FA instance. The value is the same as the host setting (the OS hostname) in the system/local/inputs.conf file in each FA VM. When set, the value determines the value of the FA field that is set in all events generated by the engine instances running in the FA. It can be any value, for example a unique name, a short or long DNS hostname, or an IP address.
Stanzas	Use only in the default stanza, not in regular stanzas.
Examples

appFunctionMetrics

Setting	appFunctionMetrics
Required	no
value
default value	OFF
syntax	OFF>
Description	This setting is case sensitive. When turned ON detailed internal performance metrics are gathered and can be used for detailed debugging and performance profiling of the internal engine's operation. The data contains information about key internal functions and important VMware API (SDK) functions. When collected, the data is mapped to the Splunk App for VMware. The collection of detailed internal performance metrics causes additional data to be forwarded to the _internal index (with sourcetype=vmware:_internal) and therefore uses additional storage. These events do not count towards daily licensing volume. When turned OFF no data is collected.
Stanzas	Used in the default stanza. It can be used in regular stanzas (vCenter Stanza, Managed ESX/i host stanza, unmanaged ESX/i host stanza) to collect data from a specific target VC machine or ESX/i host. When you incorrectly specify the value in the default stanza, then all stanzas are ignored, otherwise only the stanza in which the incorrect value was specified is ignored.
Recommendation	Specifically set the value of the FA for each FA monitored by the solution. The value should be the same as the host setting (the OS hostname) in the system /local/inputs.conf file in each FA VM.
Examples

customInvSourceWhitelist

Setting	customInvSourceWhitelist
default value	When inventoryLevel=Custom is included in a stanza the setting is applied and all sources are included in inventory collection.
Value	This is the perl compatible regular expression that matches the inventory data sources you want to *include* during data collection. If your PCRE skills are rusty, just remember that source names should be separated by "|" .
Required	no
syntax	customInvSourceWhitelist = <regex>
Description	This setting filters data out in by "source" and is used to provide very low-level, fine-grained control over the amount and kind of inventory data gathered. It is used in conjunction with the "inventoryLevel" setting (see below). The engine will only gather the inventory sources whose names match the terms of the regex. This setting is *only* applied when the "inventoryLevel=Custom" setting is placed in a stanza (see below). It is ignored for all other cases (i.e. stanzas that do not have the "inventoryLevel" setting specified, or when it is set to "Required"). Valid inventory source names map directly to objects in the VMware API Reference. The list of valid source names is too large to list here. Please see the VMware API Reference documentation for more information. Look at the "Managed Object Types" and "Data Object Types" sections of the doc to see the available source names (can be found on the left side of the page). If this setting is not specified or it is left blank (no value), but "inventoryLevel=Custom" is set in a stanza, all sources are included in inventory collection in that stanza by default. Because sources can be specified with a regex, it is possible to capture many sources at once. For example, if you want to collect all HostSystem-related inventory objects, most of them can be captured by including the string "Host" in the regex, which will match all source names that contain the string "Host". If both customInvSourceWhitelist and customInvSourceBlacklist are specified, a source is collected only when it matches the customInvSourceWhitelist regex but does *not* match the customInvSourceBlacklist regex. We recommend not using this setting at all and leaving "inventoryLevel" unspecified in stanzas so that "all" inventory data is collected. If you filter out certain inventory sources, certain views in the front-end (Splunk App for VMware) will appear to break.
Stanzas	Use only in the default stanza. As a result, it can be applied to either VC machines or ESX/i hosts, as determined by which regular stanzas specify the "inventoryLevel" setting.
Examples
Warning	Generally speaking, you should *not* attempt to use this setting unless you are a Splunk for VMware expert and understand exactly how the custom source list will affect the front-end (Splunk App for VMware). The list of potential sources is very large, and it will be very easy to make the solution appear to break.

customInvSourceBlacklist

Setting	customInvSourceBlacklist
default value	If the setting is not specified, when inventoryLevel=Custom is set in a stanza the setting is applied and no sources are excluded from inventory collection in that stanza. If the setting is not specified but inventoryLevel=Custom
value	The perl compatible regular expression that matches the inventory data sources you wish to *exclude* during data collection. If your PCRE skills are rusty, just remember that source names should be separated by "|" (with no surrounding spaces).
Required	no
syntax	customInvSourceBlacklist = <regex>
Description	This setting filters data out by "source" and is used to provide very low-level, fine-grained control over the amount and kind of inventory data gathered. It is used in conjunction with the "inventoryLevel" setting (see below). The engine will not gather the inventory sources whose names match the terms of the regex. This setting is *only* applied when the "inventoryLevel=Custom" setting is placed in a stanza (see below). It is ignored for all other cases (i.e. stanzas that do not have the "inventoryLevel" setting specified, or when it is set to "Required"). Valid inventory source names map directly to objects in the VMware API Reference. The list of valid source names is too large to list here. Please see the VMware API Reference documentation for more information. Look at the "Managed Object Types" and "Data Object Types" sections of the doc to see the available source names (can be found on the left side of the page). If this setting is not specified, but "inventoryLevel=Custom" is set in a stanza, no sources will be excluded from inventory collection in that stanza by default. Because sources can be specified with a regex, it is possible to capture many sources at once. For example, if you want to exclude all HostSystem-related inventory objects, most of them can be specified by including the string "Host" in the regex, which will match all source names that contain the string "Host". If both customInvSourceWhitelist and customInvSourceBlacklist are specified, a source is collected only when it matches the customInvSourceWhitelist regex but does *not* match the customInvSourceBlacklist regex. We recommend not using this setting at all and leaving "inventoryLevel" unspecified in stanzas so that "all" inventory data is collected. If you filter out certain inventory sources, certain views in the front-end (Splunk App for VMware) will appear to break.
Stanzas	Use only in the default stanza. As a result, it can be applied to either VC machines or ESX/i hosts, as determined by which regular stanzas specify the "inventoryLevel" setting.
Examples
Warning	Generally speaking, you should *not* attempt to use this setting unless you are a Splunk for VMware expert and understand exactly how the custom source list will affect the front-end (Splunk App for VMware). The list of potential sources is very large, and it will be very easy to make the solution appear to break.

hierarchyExpiration

Setting	hierarchyExpiration
default value	900 (15 minutes)
value	This is the amount of time that HierarchyDiscovery will run before starting a new, full snapshot of the hierarchy data. In the typical case, set the time expiration window to a value that is slightly longer than the amount of time HierarchyDiscovery takes to gather the entire hierarchy from the entire environment.
Required	no
syntax	hierarchyExpiration = <seconds>
Description	This setting is primarily used to set the time window over which the engine gathers the entire hierarchy data snapshot. When the time window expires, the engine starts to gather a new, full snapshot of the hierarchy data. It is especially useful in large environments where the engine may take a very long time to gather the entire hierarchy. When hierarchy is collected¸ the general rule of thumb is to set this value to 2 minutes (120 seconds) for each ESX/i host that the given VC manages, assuming that hosts have 10 VMs each on average. Note: this number is based on the number of ESX/i hosts that are managed by VC in total, *not* just the number of ESX/i hosts being monitored by the solution. For example, if VC #1 manages 30 ESX/i hosts, but only 10 of those are being monitored, then the expiration timer should be set to 1800 seconds (60 seconds * 30 hosts), not just 600 seconds (60 seconds * 10 hosts). If the number of VMs per ESX/i host is larger than 10 on average, you may need to increase the amount of time per host proportionally above 2 minutes. This setting can also be used as a coarse-grained way to control the amount of hierarchy data that the solution collects. If your hierarchy doesn't change very often, or you are willing to live with using older data (vs. closer to real-time) as a way to keep licensing costs low, then you can set this value higher. By setting the value higher, the engine will gather data less frequency - i.e. a bigger time window means that new, full hierarchy updates are collected less often. However, note that the amount of hierarchy data collected is small relative to other kinds of data (e.g. logs, inventory, performance). Therefore, from a practical standpoint, there may be little savings from limiting hierarchy data and it is normally better to fine-tune other data sources first.
Stanzas	Use only in the default stanza. As a result it can be applied to either VC machines or ESX/i hosts, as determined by which regular stanzas specify the "action=HierarchyDiscovery" setting
Note	If you set the expiration window to a value that is too small relative to the hierarchy size, hierarchy data collection will "snap" to the next available time window. For example, if the window is set to 15 minutes, but collection takes 20 minutes, hierarchy data collection will not start again until the 30 minute mark. While this does not cause immediate problems, it is best to set the window correctly to most efficiently gather the data as fast as possible. This is particularly important if the VMware environment is undergoing a lot of changes over a short period of time or there is a strong desire to gather data and see changes as close to real-time as possible. However, setting the expiration window too small can cause other problems, such a creating contention for engine execution time, and that can lead gaps in other kinds of data that the same engine instance is supposed to gather. As a result, we do *not* recommend setting this value to be lower than 15 minutes because it can cause too much data collection and other problems, even in small environments.
Examples

hierarchyTimeSlot

Setting	hierarchyTimeSlot
default value	10 seconds
Required	no
syntax	hierarchyTimeSlot = <seconds>
Description	This is the amount of time that HierarchyDiscovery will pull hierarchy data before stopping and letting another discovery module run. If the VMware environment is large, it may make sense to increase this value substantially. From a Splunk for VMware Solution perspective, the size of an environment is measured by the number of ESX/i hosts and VMs managed by VC instances. Note that the number of ESX/i hosts under management by VCs may be much larger than the subset of hosts that the VMware Solution is supposed to monitor (as configured in one or more engine.conf files). See the user documentation for a more detailed discussion of what a "large" environment looks like. Generally, the time slot value can be increased when an engine instance is dedicated to hierarchy data collection because there is less risk of starving other data collection actions (e.g. inventory, performance, etc.) We recommend that this value be set smaller than the "interval" setting's value.
Stanzas	Use only in the default stanza. As a result, it can be applied to either VC machines or ESX/i hosts, as determined by which regular stanzas specify the "action=HierarchyDiscovery" setting.
Examples

inventoryExpiration

Setting	inventoryExpiration
default value	900 (15 minutes)
Required	no
syntax	inventoryExpiration = <seconds>
Description	This is the amount of time that InventoryDiscovery will run before starting a new, full update of the inventory data. This setting is primarily used to set the time window over which the engine gathers the entire inventory data set one time and only getting changes to existing objects. When the time window expires, the engine will mark all inventory objects as "stale" and start to get a new, full update. It is especially useful in large environments where the engine may take a very long time to gather the entire inventory. In the typical case, the time expiration window should be set to a value that is slightly longer than the amount of time InventoryDiscovery takes to gather the entire inventory from the target VC machine or ESX/i host. When inventory is collected from VC (the normal case), the general rule of thumb is to set this value to 2 minutes (120 seconds) for each ESX/i host that the given VC manages, assuming that hosts have 10 VMs each on average. For example, if VC #1 manages 30 ESX/i hosts, then it makes sense to set the expiration to 3600 seconds (120 seconds * 30 hosts). If the number of VMs per ESX/i host is larger than 10 on average, you may need to increase the amount of time per host proportionally above 2 minutes. This setting can also be used as a coarse-grained way to control the amount of inventory data that the solution collects. If your inventory doesn't change very often, or you are willing to live with using older data (vs. closer to real-time) as a way to keep licensing costs low, then you can set this value higher. By setting the value higher, the engine will gather data less frequency - i.e. a bigger time window means that new, full inventory updates are collected less often.
Stanzas	use only in the default stanza. As a result, it can be applied to either VC machines or ESX/i hosts, as determined by which regular stanzas specify the "action=InventoryDiscovery" setting.
Note	If you set the expiration window to a value that is too small relative to the inventory size, inventory collection can "back up" because the engine will start updating existing inventory data while also still trying to gather new inventory objects. This can cause problems, the biggest of which is contention for engine execution time, and that can lead gaps in other kinds of data that the same engine instance is supposed to gather. As a result, we do *not* recommend setting this value to be lower than 15 minutes because it can cause too much data collection and other problems, even in small environments.
Examples	example stanza for an FA VM with an OS hostname set to “splunkfa1” during the initial configuration steps, and collects data from a VC with 50 hosts (2 minutes per host = 6000 seconds): # Set the fa name to the value you used for the FA VM's OS hostname # (during FA VM configuration steps). # This example assumes that the FA VM's OS hostname was set to "splunkfa1" [default] fa = splunkfa1 hierarchyExpiration = 6000 inventoryExpiration = 6000

Required settings assigned in stanzas

This section describes required settings in engine.conf stanzas.

url

Setting	url
Required	yes
Value
syntax	url = <URL>
Description	This is the URL used to connect to the given target machine to get the data. This is the same value as the variable VI_URL in the VMware SDK. The value has the following format: https://<host name or ip address>/sdk/webService This setting determines which target VC machine or ESX/i host that the engine will connect to and gather data from.
Stanzas	use only in vCenter Stanza, Managed ESX/i host stanza, unmanaged ESX/i host stanza. It can be used to target both VC machines and ESX/i hosts for data collection. Note that if a stanza targets a managed ESX/i host, then it is important to make sure that the host's managing VC also has a stanza in the same engine.conf file. If there is no stanza for an ESX/i host's managing VC, it is important to include a "blank VC stanza" in the same file (i.e. a stanza targeted at the VC using the url setting but with no "action" setting). This is not an issue for unmanaged ESX/i hosts.
Examples	Example 1: Assume that VC #1 manages ESX/i host "A" (i.e. it is a "managed" host) and there is already a stanza to get data from VC #1 in the engine.conf file. In this case, there is no need to do anything special. Simply specify the "A" ESX/i host's stanza normally (with "action=<any valid action>") and the solution will work properly. Example 2: Assume that VC #1 manages ESX/i host "A" but there is no stanza to get data from VC #1 in the engine.conf file because a different engine instance is getting VC data (and thus the data gathering configuration is in a different engine.conf file). In this case, you *must* place a blank VC stanza for VC #1 in the engine.conf file anyway so that the solution will work properly. The VC #1 stanza would have no "action" setting defined, or it would be set to blank ("action="). Note: blank VC stanzas should also set their "interval" value to 1 to avoid unnecessary delays in data gathering.

username

Setting	username
required	yes, but is not needed if you created a credentials.conf file and it contains a stanza that includes the VC or ESX/i host specified by the given stanza.
value	the same value as the variable VI_USERNAME in the VMware SDK
syntax	username = <username>
Description	The username used to log into the url. This is the same value as the variable VI_USERNAME in the VMware SDK.
Stanza	use in vCenter Stanza, Managed ESX/i host stanza, unmanaged ESX/i host stanza. It can also be placed in the [default] stanza if all stanzas are supposed to use the same username setting. It can be applied to either VC or ESX/i host stanzas.
Note	You do not need to specify this setting in engine.conf if you use a credentials.conf file and it contains a stanza that includes the VC or ESX/i host specified by the given stanza.
Examples

password

Setting	password
Required	Yes, but is not needed if you have created a credentials.conf file and it contains a stanza that includes the VC or ESX/i host specified by the given stanza.
Value	the same value as the variable VI_USERNAME in the VMware SDK
Syntax	password = <password>
Description	The password used to log into the url; it is the same value as variable VI_PASSWORD in the VMware SDK.
Stanza	use in vCenter Stanza, Managed ESX/i host stanza, unmanaged ESX/i host stanza. It can also be placed in the [default] stanza if all stanzas are supposed to use the same password setting. It can be applied to either VC or ESX/i host stanzas.
Note	You do not need to specify this setting in engine.conf if you use a credentials.conf file and it contains a stanza that includes the VC or ESX/i host specified by the given stanza.
Examples

Optional engine.conf stanza entries

This section described optional entries in engine.conf stanzas. The settings are assigned in individual stanzas.

host

Setting	host
default value	is the host name or IP address used in the url setting for a VC machine or an unmanaged ESX/i host
Required	no, but we recommend setting this for all stanzas that target VC machines and "unmanaged" ESX/i hosts. An unmanaged ESX/i host is one that is not managed by any VC instance.
value	For VC machines: This should be set to the "VC instance name" - i.e. the name of the root node in the VC's "Hosts and Clusters" view as seen in the vSphere Client. For unmanaged ESX/i hosts: This should be set to the same value as the ESX/i host's "fully qualified hostname" (see the section "An ESX/i host's "fully qualified hostname" for more information).
syntax	host = <name>
Description	For a VC machine or an unmanaged ESX/i host, this setting is important because it becomes the value of the "host" field for all data events generated by the engine for that target machine. For a "managed" ESX/i host (one that is managed by a VC instance), this setting is ignored. Instead, the value of the "host" field is set automatically based on the name of the ESX/i host as shown in the "Hosts and Clusters" tree view within VC. However, note that in order for this to function properly, there must be a stanza for the ESX/i host's managing VC. If not, a "blank VC stanza" should be placed in the same engine.conf file (as explained in the url setting description). This is not an issue for unmanaged ESX/i hosts.
Stanza	The setting is assigned in individual stanzas. You can use it in the vCenter Stanza and the unmanaged ESX/i host stanza.
Examples

action

Setting	action
Required	no, but is almost always present in a regular stanza.
value
syntax	action = <module-list>
Description	Define actions within stanzas in the engine.conf file. They correspond to the type(s) of data you want to collect. There is an action keyword for each kind of data collected. For example, you can collect hierarchy data using the action HierarchyDiscovery in engine.conf. You can define multiple actions for a single target machine. The actions run against specific machines (for example, VC machines or ESX/i hosts) to get specific types of data from VMware and forward the collected data to the relevant Splunk indexer(s) as determined by the setting in your outputs.conf file. Assign values to the action based on the machine type from which you want to collect data. In the absence of this value being set, the TimeDiscovery action is automatically performed. The only time that the action setting should be unspecified or set to blank (no value), is when telling the Engine how to reach a particular VC instance but gather no data. This should only be done when an engine.conf file tells the engine to get performance data from an ESX/i host (using the PerfDiscovery action) and doesn't actually need to get other kinds of data from VC. The discovery actions are: InventoryDiscovery - Collects a large volume of data and as a result can be slow to process it. The larger the environment the bigger the impact on data collection. For larger environments, we recommend that you create an engine.conf file that is dedicated to collecting inventory data with low interval values between stanzas.. For very large environments, that may be more volatile , or where there are multiple VCs we recommend that you create sets of engine.conf files with low interval values between stanzas. HierarchyDiscovery - Crawls a large volume of data and as a result can be slow to collect an entire snapshot. especially when there are several VCs and lots of ESX/i hosts. We recommended putting this action into its own engine.conf, running it separately from other modules, and using a low interval value. PerfDiscovery - Execution times for this module vary widely. We recommended that you put this action into its own FA VM (with or without performance filters) if gathering near real-time performance data is important. By default, ESX/i hosts only store one hour of historical performance data, so all elements on the host must be gathered at least once per hour. The module can be configured to collect data at a faster rate than the default setting. EventDiscovery - This module is fast and can run for a long time on startup if you have it set to gather historical data. We recommend that you gather this data at roughly 5 minute intervals. TaskDiscovery - This module is fast and can run for a long time on startup if you have it set to gather historical data. We recommend that you gather this data at less than 5 minute intervals because that is the timeout on the VMware “recent tasks” queue. LogDiscovery - The performance of this module falls between the faster and slower modules. This module retrieves log entries using the last line accessed, although it is important to note that the log rotation performed internally by ESX/i can cause gaps in the data collection. In general, for large environments run this module faster than other modules to reduce the chance for data gaps, and when they occur, keep the gaps as small as possible. We recommend that you run this at 3 - 30 second intervals (if no other actions are running) because VMware tends to generate a lot of log data in a very short period of time, even in a simple environment that is not very active. If you do not specify discovery actions in your stanzas, then you will not collect the type of data associated with that action. When using Splunk App for VMware, the dashboards and views will appear to break. Some actions have constraints associated with them. These are described in the Discovery Action Constraints table below.
Stanza	The setting is assigned in individual stanzas. You can use this action in vCenter Stanza, Managed ESX/i host stanza, unmanaged ESX/i host stanza. . Specify the action in the [default] stanza to enable all stanzas to use the same action setting. We do not usually recommend that you put this setting in the [default] stanza as it is mostly used to get different kinds of data from different kinds of machines; This implies that most "action" settings are different from stanza to stanza, for example, VC machines provide different kinds of data than ESX/i hosts provide. The exception is when a given engine instance (and its engine.conf file) only covers one or two actions that are common across all of the stanzas. For example, this might happen when an engine instance is dedicated to getting hierarchy data, and therefore all stanzas would have the setting "action=HierarchyDiscovery". It can be applied to either VC or ESX/i host stanzas.

Discovery Action Constraints

This table lists the constraints associated with each discovery action.

Discovery Action	Constraint Description
InventoryDiscovery	Setting inventory collection times and inventoryExpiration appropriately is important. Use this action in vCenter Stanzas and unmanaged ESX/i host stanzas. Inventory data for managed ESX/i hosts is collected using the VC.
HierarchyDiscovery	Hierarchy collection timing is important and is set using hierarchyExpiration and/or hierarchyTimeSlot appropriately. All stanzas with "action=HierarchyDiscovery" *must* be run by the same engine instance, for the solution to work correctly, therefore, all stanzas with hierarchy actions must be located in a single engine.conf file so that all hierarchy data can be captured in a single "snapshot". RESTRICTION: multiple concurrent hierarchy snapshots are not currently supported so HierarchyDiscovery actions across all VC machines and all ESX/i hosts must be place in a single engine.conf file. They cannot be split across multiple engine.conf files. Use in Stanza : use in vCenter Stanza, Managed ESX/i host stanza, and unmanaged ESX/i host stanza.
PerfDiscovery	For the solution to correctly handle performance data, if a stanza gets performance data from a managed ESX/i host, a stanza for its associated VC machine *must* also be placed in the same engine.conf file. If you are not collecting other data from the VC managing the ESX/i host in the given engine instance, then add a "blank VC stanza" to the engine.conf file (as explained in the url setting description). A blank VC stanza is a stanza pointed at the ESX/i host's managing VC but the "action" field is missing or blank. The important thing for the engine to know how to reach the host's associated VC (using the url setting). This is not an issue for unmanaged ESX/i hosts. Under normal circumstances, this action can be applied to all ESX/i hosts (managed or unmanaged) monitored for performance data by the solution. It should also be applied to every VC monitored by the solution and used in conjunction with the perfManagedEntityWhitelist setting to limit the amount of performance data collected from VC. Use perfManagedEntityWhitelist with PerfDiscovery to only get performance data for specific managed objects found only in VC, for example, Clusters. Using perfManagedEntityWhitelist prevents the engine from collecting duplicate data from the VC already collected from the ESX/i hosts. This setting can also be applied to the ESX/i hosts to limit the amount of data being collected from them. See the examples for more information. Example 1: Assume that VC1 manages ESX/i host "A" and there is already a stanza to get data from VC #1 in the engine.conf file. In this case, there is no need to do anything special. Simply specify the "A" ESX/i host's stanza normally (with "action=PerfDiscovery,...") and the solution will work properly. Example 2: Assume that VC1 manages ESX/i host "A" but there is no stanza to get data from VC1 in the engine.conf because we are using a different engine instance to collect the VC inventory data (inventory data gathering is configured in a different engine.conf file). In this case, you use a blank VC stanza for VC1 (with no action set, or set to blank ("action=")) in the engine.conf file for the solution will work correctly. Use this action in the vCenter stanza, managed ESX/i host stanza, and unmanaged ESX/i host stanza.
EventDiscovery	For VMware events, there are no special constraints. This action is currently not supported for unmanaged ESX/i hosts. VMware event data for managed ESX/i hosts is collected via VC. Use this action in the vCenter stanza.
TaskDiscovery	For VMware tasks, there are no special constraints. Use this action in the vCenter stanza and the unmanaged ESX/i host stanza.
LogDiscovery	For ESX/i host logs, there are no special constraints. Use this action in the managed ESX/i host stanza and the unmanaged ESX/i host stanza. VC log data is collected using the vCenter Server add-on component of the Splunk for VMware Solution.

disabledAction

Setting	disabledAction
Required	no
value	For VC machines: This should be set to the "VC instance name" - i.e. the name of the root node in the VC's "Hosts and Clusters" view as seen in the vSphere Client. For unmanaged ESX/i hosts: This should be set to the same value as the ESX/i host's "fully qualified hostname" (see the section "An ESX/i host's "fully qualified hostname" for more information). If left unspecified for a VC machine or an unmanaged ESX/i host, the default value is the host name or IP address used in the url setting. ||
syntax	disabledAction = <module-list>
Description	The is the list of modules (delimited by commas) to disable. This value has higher priority than the action setting. This setting is rarely used. It is useful when a set of actions has been specified in the [default] stanza (which is very unusual) and this setting is used to selectively turn off some of the default actions.
Stanzas	The setting is assigned in individual stanzas. You can use it in the vCenter Stanza, Managed ESX/i host stanza, and unmanaged ESX/i host stanza.
Examples

interval

Setting	interval
Required	no
Default Value	3 seconds
value	We recommend you set this value to 1 second to reduce the possibility of gaps forming in your data. Polling VC or ESX/i machines for data more frequently than the default value specifies will only slightly increase the load on these machines, and will prevent gaps from occurring in your data.
syntax	interval = <seconds>
Description	This is the amount of time (in seconds) that the Engine waits in-between invoking different actions in a given stanza. Introducing a delay interval between actions can be used to reduce the load on VC and ESX/i hosts from pulling data too frequently. However, if the interval is set too high, you may get gaps in your data due to some actions being “starved” (i.e. not being run often enough). Setting the interval value properly can therefore take some tuning and will depend on things like the number of ESX/i hosts and VMs managed by a given VC, the number of actions run by a single engine instance, the number of stanzas in a given engine.conf file, and so on.
stanza	The setting is assigned in individual stanzas. You can use it in the vCenter Stanza, Managed ESX/i host stanza, and unmanaged ESX/i host stanza. Note It can also be placed in the [default] stanza if all stanzas are supposed to use the same interval setting. Using this setting in the [default] stanza would be unusual as it is typically used to collect different types of data at different intervals, which implies that most "interval" settings vary from stanza to stanza based on the action, which determines the type of data to collect (e.g. task data is collected at a different interval vs. performance data). The obvious exception to this is when a given engine instance (and its engine.conf file) only covers one or two actions that have a common interval across all of the stanzas. For example, this might happen when an engine instance is dedicated to getting hierarchy data at a common interval (e.g. 3 seconds), and therefore all stanzas would have the setting "interval=3".
Example	If an engine.conf stanza shows "Action=InventoryDiscovery, HierarchyDiscovery", then the engine will invoke InventoryDiscovery (which will run until it hits a stopping point), the engine will then wait 3 seconds before it calls HierarchyDiscovery.

invBlacklist

Setting	invBlacklist
value
Required	no
syntax	invBlacklist = <regex>
Description	The perl compatible regular expression that matches the managed entities to filter out of inventory collection. If your PCRE skills are rusty, just remember that entity names should be separated by "|" (with no surrounding spaces). This setting is used to provide high-level control over the amount of inventory data to be collected. When combined with other inventory data controls, such as inventoryLevel, this can provide decent control over the amount and kinds of inventory data that the engine should collect. Both the invBlacklist and inventoryLevel can be specified at the same time. By default, inventory collection covers all of the major managed entities and their children. The invBlacklist is first applied to eliminate large parts of the inventory tree at the managed entity level,then the inventoryLevel is applied to select only specific sources from the remainder. Managed entities are key high-level inventory objects. Most other inventory objects are lower-level children of a managed entity. If a given managed entity is filtered out using the blacklist, then its children are also filtered out. For example, if HostSystems are blacklisted from inventory data collection, then related child objects like vNICs and vHBAs will also be filtered out. Valid managed entities are: ClusterComputeResource ComputeResource Datacenter Folder HostSystem ResourcePool VirtualMachine If this value is not present, all of the above managed entities are collected.
Recommendation	We recommend leaving this setting undefined so that inventory data for all types of managed entities are gathered. If you filter out certain types of managed entities, when exploring the data using SPlunk App for VMware, certain views and dashboards will not show the data being collected and appear to be broken.
Stanza	The setting is assigned in individual stanzas. You can use it in the vCenter Stanza, Managed ESX/i host stanza, and unmanaged ESX/i host stanza. It can also be placed in the [default] stanza (to limit the amount and kind of data collected) if all stanzas are supposed to use the same blacklist setting. It should only be used in stanzas where the "action=InventoryDiscovery" setting is specified.
Examples

inventoryLevel

Setting	inventoryLevel
value	the value is one of All, Required, or Custom. Each value is specified using an initial upper case letter. This is important when the engine checks the values.
"Default value"	All
Required	no
syntax	Required | Custom)
Description	This setting is used to provide fine-tune controls on the amount of inventory data to be collected. When combined with other inventory data controls (e.g. invBlacklist), this can provide decent control over the amount and kinds of inventory data that the engine should collect. Both the invBlacklist and inventoryLevel can be specified at the same time. By default, inventory collection covers all of the major managed entities and their children. The invBlacklist is first applied (to eliminate large parts of the inventory tree at the managed entity level), and then the inventoryLevel will be applied (to select only specific sources out of what is left). All: all available inventory sources will be gathered. Required: only a small set of predefined sources are collected - i.e. the data sources rewuired to populate the dashboards and views in Splunk App for VMware. Custom: the customInvSourceWhitelist and customInvSourceBlacklist settings are used to determine exactly which sources will be gathered (see above). Note: The engine's value checks are case-sensitive. If you provide a value with the incorrect syntax, the engine will log an error and ignore the entire stanza.
Stanza	The setting is assigned in individual stanzas. You can use it in the vCenter Stanza, Managed ESX/i host stanza, and unmanaged ESX/i host stanza. It can also be placed in the [default] stanza (to limit the amount and kind of data collected) if all stanzas are supposed to use the same inventoryLevel setting. It should only be used in stanzas where the "action=InventoryDiscovery" setting is specified.
Recommendation	We recommend leaving this setting undefined so that all inventory data is gathered. When selecting a custom level, if you forget to specify certain required types of inventory data, certain views and dashboards in Splunk App for VMware will appear to break.
Examples

perfManagedEntityWhitelist

Setting	perfManagedEntityWhitelist
value	For VC machines, set this value to "ClusterComputeResource". We recommend giving this setting the same value for a given type of target machine.
syntax	perfManagedEntityWhitelist = <regex>
Required	no
Description	Set this to the perl compatible regular expression that matches the managed entities types you wish to gather performance data about. Entity names should be separated by "|" <nowiki> with no surrounding spaces. This setting is used to provide high-level control over the amount of performance data to collect. It is used to select specific managed entities and add them to the performance data collection action. When combined with mid-level performance data type controls, for example perfTypeWhitelist, this can provide fairly fine-grained control over the amount and kinds of performance data that the engine should collect. Both whitelists can be specified at the same time. The managed entity list is applied first (to select specific managed entities), and then the performance data type list is applied (to select the types of performance data on the given managed entities to collect). The allowed entity names are: *'''ClusterComputeResource:''' Object that represents a Cluster of Hosts. *'''HostSystem''': Object that represents an ESX/i Host. *'''ResourcePool''': Object that represents a Resource Pool. *'''VirtualApp''': Object that represents a vApp. *'''VirtualMachine''': Object that represents a Virtual Machine. If this setting is not present, or no value is provided, all of the above managed entities are collected. We recommend using the following values with this setting: * '''VC machines''': set this value to "ClusterComputeResource". Most performance data is gathered directly from ESX/i hosts, which gets data for the other 4 types of objects by default. Example: <div class="samplecode"> <pre> perfManagedEntityWhitelist = ClusterComputeResource </pre></div> * '''ESX/i hosts''': Omit this setting from stanzas. You will typically omit this setting so that the engine gathers performance data for all of the available inventory objects on the host. In all cases we recommend giving this setting the same value for a given type of target machine. For example, you should set all VC stanzas with the same value, and separately set all ESX/i host stanzas to a common value. If you forget to specify certain types of performance data, then certain views in the Splunk App for VMware will appear to be broken. |- |Stanza || The setting is assigned in individual stanzas. You can use it in the vCenter Stanza, Managed ESX/i host stanza, and unmanaged ESX/i host stanza. It can also be placed in the [default] stanza ( to limit the kind and amount of data collected) if all stanzas are supposed to use the same whitelist setting. Only use it in stanzas where the "action=PerfDiscovery" setting is specified. |- |Examples || |- |} ==perfTypeWhitelist == {| border=1 cellpadding=5 cellspacing=0 width=100% |- ! Setting !! perfTypeWhitelist |- | '''value''' || The perl compatible regular expression that matches the type of performance data you wish to collect. Remember that in the RegEx, separate performance data type names with <nowiki> "|" (with no surrounding spaces).
syntax	perfTypeWhitelist = <regex>
Required	no
Description	This setting is used to provide mid-level control over the types of performance data to collect. It is used to select specific types of performance data and add them to the performance data collection action. When combined with managed high-level managed entity controls (e.g. perfManagedEntityWhitelist), this can provide fairly fine-grained control over the amount and kinds of performance data that the engine should collect. Both whitelists can be specified at the same time. The managed entity list is applied first (to select specific managed entities), and then the performance data type list is applied (to select the types of performance data on the given managed entities to collect). The allowed performance type values include: cpu disk net mem power ds (datastore) cl (cluster services) ma (management agent) sa (storage adapter) spth (storage path) rcpu (resource scheduler) vdsk (virtual disk) vcdbg (vc debug info) vcres (vc resources) sys (system) If this value is not present, all of the above performance types are collected. If you forget to specify certain types of performance data, certain views in the front-end (Splunk App for VMware) will appear to break. For more information about performance metric groups, see the VMware API Reference page that explains performance counter groups.
Stanza	The setting is assigned in individual stanzas. You can use it in the vCenter Stanza, Managed ESX/i host stanza, and unmanaged ESX/i host stanza. It can also be placed in the [default] stanza (to limit the kind and amount of data collected) if all stanzas are supposed to use the same whitelist setting. It should only be used in stanzas where the "action=PerfDiscovery" setting is specified.
Recommendation	leave this setting undefined to allow all types of performance data to be gathered. In all cases we recommend giving this setting the same value for a given type of target machine. For example, you should set all VC stanzas with the same value, and separately set all ESX/i host stanzas to a common value.
Examples

perfLevel

Setting	perfLevel
Required	no
Value	one of levels 1, 2, 3, or 4
Default value	4
syntax	perfLevel = <level>
Description	This setting has numeric value of 1,2,3 or 4. The value corresponds to a level associated with a specific performance metric in VMware. This level is used (by the engine) in the Solution to gather performance data from VC machines. The higher the level specified, the greater the amount of performance metrics gathered. Specifying a level, 3 for example, gathers all performance metrics for level 3 and for levels 1 and 2. For more information on VMware performance levels see VMware API Reference page.
Note	Setting the performance data level less than the default value of 4 may cause some dashboards and views in Splunk App for VMware to appear to break. This setting only affects the amount of performance data that the engine collects from VC and ESX/i hosts using the "level" mechanism that they already understand. it does not affect the amount of data collected by vSphere itself.
Stanza	The setting is assigned in individual stanzas. You can use it in the vCenter Stanza. It can be placed in the [default] stanza ( to limit the kind and amount of data collected) if all stanzas are supposed to use the same perfLevel setting. It should only be used in stanzas where the "action=PerfDiscovery" setting is specified.
Examples

perfInstanceData

Setting	perfInstanceData
Required	no
Value	Only one of the two values can be specified - ON or OFF
Default value	OFF
syntax	OFF>
Description	Use this setting in engine.conf to control the amount of performance data to collect in the Solution and whether you want to collect instance data. In this case an Instance identifies a specific devices reporting a specific type of metric. For example, vmnic0 represents a virtual Ethernet adapter. For the definition of instance data, see http://pubs.vmware.com/vsphere-50/topic/com.vmware.wssdk.pg.doc_50/PG_Ch16_Performance.18.2.htm. When set to "OFF", the engine does not collect instance data, but it continues to collect aggregate data. When used in combination with entity controls (perfManagedEntityWhitelist) and data type controls (perfTypeWhitelist) the result can provide fine-grained control over the amount and kinds of performance data that you want the engine to collect.
Note	If a default value is not set or if the setting is not specified at all, then only aggregate data is collected. You must specifically set the value to ON if you want it to work.
Stanza	This setting is generally used only in regular stanzas, but it can also be placed in the [default] stanza if all stanzas are supposed to use the same whitelist setting. It can be applied to either VC or ESX/i host stanzas. It should only be used in stanzas where the action=PerfDiscovery setting is specified.
Examples	user only wants to keep perftype=disk instance data but not anything else. See engine.conf.spec file.

eventHistory

Setting	eventHistory
Required	no
value
syntax	eventHistory = <hours>
Description	The event history specifies the number of hours you want to go back in time to collect VMware events. Increasing the eventHistory value increases the amount of time the EventDiscovery module takes on its first pass, which increases the time it takes for Splunk to start processing data from VMware. If this value is not present, event collection starts at the time when the EventDiscovery module starts running.
Stanza	The setting is assigned in individual stanzas. You can use it in the vCenter Stanza. It can also be placed in the [default] stanza if all stanzas are supposed to use the same eventHistory setting. Event collection directly from ESX/i hosts is currently not supported. It should only be used in stanzas where the "action=EventDiscovery" setting is specified.
Examples

eventWhitelist

Setting	eventWhitelist
Value
Default value	all available VMware event types are collected.
Required	no
syntax	eventWhitelist = <regex>
Description	The perl compatible regular expression that matches the types of VMware event data you want to collect. If your PCRE skills are rusty, just remember that event names should be separated by "|" (with no surrounding spaces). Valid event names map directly to data objects in the VMware API Reference. For more information on the list of valid event names, see VMware API Reference documentation. Refer to the "Data Object Types" section of the doc to see the available event names (can be found on the left side of the page). Event names almost always end with "Event", for example, AccountCreatedEvent. You can also type "event" in the "quick index" search box and it will list all of the valid event types.
Recommendation	We recommend omitting this setting so that the engine gathers all types of events. In all cases we recommend giving this setting the same value for all VC stanzas. If you do not gather all types of events some of the dashboards and views in Splunk App for VMware will not display correctly.
Stanza	The setting is assigned in individual stanzas. You can use it in the vCenter Stanza. It can also be placed in the [default] stanza (to limit the kind and amount of data collected) if all stanzas are supposed to use the same whitelist setting. Event collection directly from ESX/i hosts is currently not supported. It should only be used in stanzas where the "action=EventDiscovery" setting is specified.
Examples

logWhitelist

Setting	logWhitelist
value	this is the short form of the log name. For example, "hostd" to get the hostd.log file. Specifying the full path is not necessary.
Default value	all logs are collected
syntax	logWhitelist = <regex>
Required	no
Description	" (with no surrounding spaces). The value is matched against the full log file name and path on the ESX/i host. Since a PCRE is used for matching, it is sufficient to simply give the short form of the log name. For example, you can specify "hostd" to get the hostd.log file – you do *not* need to specify the full path. If you forget to specify certain log files, some views and dashboards in Splunk App for VMware will not work correctly.
Stanza	use in Managed ESX/i host stanzas and and unmanaged ESX/i host stanzas. It can also be placed in the [default] stanza (to limit the kind and amount of data collected) if all stanzas are supposed to use the same whitelist setting. It should only be used in stanzas where the "action=LogDiscovery" setting is specified.
Recommendation	Omit this setting so that the engine gathers all of the logs available for an ESX/i host. This setting, however, can be used to reduce the amount of log data that is captured (described above). In all cases we recommend giving this setting the same value for all ESX/i host stanzas.
Examples	Valid values for an ESXi host are: /var/log/vmware/hostd.log /var/log/messages /var/log/vmware/vpx/vpxa.log Valid values for an ESX host are: /var/log/vmware/hostd.log /var/log/messages /var/log/vmware/vpx/vpxa.log /var/log/vmkernel /var/log/vmksummary.txt /var/log/vmkwarning

taskHistory

Setting	taskHistory
value
Default value	tasks collection starts at the time when the TaskDiscovery module starts running.
Required	no
syntax	taskHistory = <hours>
Description	The task history specifies the number of hours you want to go back in time to collect tasks. Increasing the taskHistory value increases the amount of time the TaskDiscovery module takes on its first pass, which increases the time it takes for Splunk to start processing data from VMware.
Stanza	The setting is assigned in individual stanzas. You can use it in the vCenter Stanzas and unmanaged ESX/i host stanzas. It can also be placed in the [default] stanza ( to limit the kind and amount of data collected) if all stanzas are supposed to use the same taskHistory setting.It should only be used in stanzas where the "action=TaskDiscovery" setting is specified.
Examples