Introduction

As discussed in How DataSources Get Applied to Resources, DataSources are automatically applied to the resources that you have added into monitoring. However, there may be occasions when you don’t want a particular DataSource to actively collect data for one or more resources to which it has been applied. For example, you may simply not be interested in the metrics being collected by that DataSource—or maybe you are interested in those metrics, but only for resources in your production environment. Or, perhaps, the DataSource has been deprecated by a new DataSource.

For these types of cases, you can perform targeted DataSource disabling. DataSource disabling allows you to discontinue data collection (and therefore, alerting) for one or more resources, while preserving all historical data collected for the resource thus far. (Deleting a DataSource or disassociating a DataSource (via a change in AppliesTo logic), on the other hand, results in the loss of all historical data.)

Alternatives to Disabling DataSources

Depending upon your objective, you may be better served by courses of action other than disabling a DataSource. Next are two examples:

• Are you disabling monitoring because of noisy alert conditions? If so, alternate courses of action could be to disable alerting instead of monitoring, or to make datapoint thresholds less sensitive, as discussed in Disabling Alerting and Tuning Static Thresholds for Datapoints respectively. Adjusting alert settings rather than disabling the DataSource allows the DataSource to continue collecting data.
• Is the DataSource incorrectly applied? If the DataSource is incorrectly applied to one or more resources, you can update the AppliesTo logic so that the DataSource automatically disassociates. (Important! Proceed with extreme caution as disassociating a DataSource from one or more resources immediately and permanently deletes all historical data collected by that DataSource for those resources.) For more information on AppliesTo logic, see AppliesTo Scripting Overview.

Disabling a DataSource

You can disable monitoring for a particular DataSource on a single resource, a particular instance of a multi-instance DataSource on a single resource, or for a particular DataSource across all resources in a resource group. As discussed in the following sections, the steps for disabling a DataSource vary depending on how broadly you are targeting disablement.

Note: When you disable monitoring of a particular DataSource for a resource or resource group, Active Discovery is also disabled for that DataSource. This means that instances will not be discovered, updated, or deleted for impacted resources.

Disabling a DataSource Across a Resource Group

To disable monitoring for a DataSource for all resources in a resource group, navigate to the Resources page and, from the Resources tree, select the desired resource group. From the detail view, open the group’s Alert Tuning tab and uncheck the checkbox in the “Enable” column for the DataSource you are disabling.

In this image, two DataSources have been disabled for all resources that are members of the “API” resource group.

When a DataSource is disabled at the resource group level, it is automatically moved into a dynamic DataSource group titled “Disabled Datasource.” This group is created for each resource in the resource group for which that DataSource applied. A refresh may be required before this group appears.

Continuing with the example in the previous screenshot, DataSources disabled at the group level are moved into a dynamic DataSource group titled “Disabled Datasource”. As shown here, this group is created for each resource in the resource group to which the DataSource applies.

Disabling a DataSource for a Single Resource

To disable a single-instance DataSource for a particular resource, navigate to the Resources page and, from the Resources tree, expand the resource for which you want to disable the DataSource. Select the desired child DataSource and, from its detail view, toggle the Enabled slider to the “OFF” position.

Note: If the DataSource is multi-instance, you’ll need to disable it at the instance level (discussed next). This allows you to disable for some instances, but not others, if desired.

Disabling an Instance of a DataSource for a Single Resource

To disable one or more instances for a multi-instance DataSource for a particular resource, navigate to the Resources page and, from the Resources tree, expand the resource for which you want to disable the DataSource. Select the desired child DataSource and, from the detail view, open its Instances tab. Place a checkmark to the left of those instances of the DataSource you want to disable, click the Actions button, and select “Disable Instance” from the dropdown.

When an instance of a DataSource is disabled, it is automatically moved into a dynamic instance group titled “Unmonitored”. For more information on instance groups, see Instance Groups.

Overview

For every DataSource applied to a device, LogicMonitor attempts to discover instances to monitor. Some DataSources will only ever have one one instance to monitor per device (e.g. ping), while others may identify multiple instances (e.g. disks, server volumes, interfaces, etc.) to monitor per device

When multiple instances are identified by a DataSource (called a multi-instance DataSource), these instances can be grouped. Instance groups allow you to organize instances in ways that are meaningful to your environment.

In addition to providing logical organizational structures, instance groups, like device groups, are available for selection from the Resources tree. As independent entities, they support many of the same actions that other tree objects do, including the ability to:

• Tune static datapoint thresholds (using the Alert Tuning tab) for all member instances en masse (see Tuning Static Thresholds for Datapoints).
• Enable dynamic thresholds (using the Alert Tuning tab) for all member instances en masse (see Enabling Dynamic Thresholds for Datapoints).
• Put all member instances into SDT (using the SDT tab) en masse (see SDT Tab).
• View overview DataSource graphs (using the Graphs tab) for just those instances in the group (see Graphs tab).
• View alerts (using the Alerts tab) for just those instances in the group.

Instance groups can be created and populated manually or automatically. Automated group management is driven by the Active Discovery process configured for a DataSource.

Manual Management of Instance Groups

For multi-instance DataSources that do not have automated instance grouping enabled, instance groups can be manually created, populated, and edited from the Instances tab. The Instances tab displays when viewing a multi-instance DataSource from the Resources tree.

To create a new instance group, click the Add Instance Group button. Once created, an instance can be moved from the default “Ungrouped” group into the new group by either dragging and dropping it or placing a checkmark to its left in the instance table and selecting Actions | Move to Instance Group.

To edit the name or description of an instance group, or delete the group, click the down arrow located to the left of the group name, as shown next.

From the Instances tab of the parent multi-instance DataSource, groups that were manually created can be edited or deleted.

Automated Management of Instance Groups

As an alternative to manually grouping instances, you can allow LogicMonitor to automatically group instances according to shared attributes upon discovery. Automated grouping is a function of the Active Discovery process, which is configured from the DataSource definition. (For more information on Active Discovery, see Active Discovery).

Specifically, automated management of instance groups is established by selecting something other than “Manual” from the Group method field’s dropdown. In order for the Group method field to be available, the DataSource definition’s Multi-instance? and Enable Active Discovery options must be checked.

There are up to four automated grouping methods you can use to organize instances:

• NetScaler
• NetScalerServiceGroup
• Regular Expression
• Instance Level Property

Which methods you are presented with from the Group method field is dependent upon what is supported by the protocol (e.g. SNMP, WMI, etc.) being used to discover instances (as defined in the Discovery method field of the DataSource definition). Each automated grouping method is discussed next.

NetScaler

Used only for Citrix NetScalers, this grouping method automatically groups instances (i.e. services) according to the load balancing virtual IPs (VIPs) in which they are members.

NetScalerServiceGroup

Used only for Citrix NetScalers, this grouping method automatically groups instances (i.e. services) according to service group names.

Regular Expression

This method supports three parameters:

• useValue=”name”|”value”|”description”|”auto.instance_property_name”
• dynamicGroup=”a regex with capturing”
• groupName1=”regex1″ groupName2=”regex2″

As detailed in the following sections, these parameters exist to answer two basic questions:

• How should instances be organized and what should those resulting instance groups be called? (Determined via either the groupName or dynamicGroup parameter; these two parameters are mutually exclusive.)
• When evaluating the first question, which property of the instance should be used—either its name or value? (Determined via the useValue parameter.)

useValue (optional)

This parameter determines which instance property (name or value) will be evaluated. It is optional; if useValue is not specified, the instance name (also commonly referred to as “WILDALIAS”) will be used by default.

The following examples illustrate how the useValue parameter can be used in conjunction with either the dynamicGroup or groupName parameter to indicate that the instance’s value (also commonly referred to as “WILDVALUE”) should be evaluated, rather than its name.

useValue="value" dynamicGroup="\w+"

useValue="value" Controllers="tray\d+controller." Batteries="tray\d+battery." CacheDIMMs="tray\d+dimm." Fans="tray\d+fan." PowerSupplies="tray\d+psu." SFPs="tray\d+sfp."

dynamicGroup

If you want to dynamically extract group names from instance names or values, you can specify a regular expression with capturing (i.e. a portion of the regular expression that should be used as the group name, which will be the first capture group, defined by parentheses). For example, Linux hosts may have some set of physical block devices (e.g. sda, sdb, hdb, hdc, etc.), each with zero or more partitions. To group each partition (e.g. sda1, sda2, sda3, sdb2, sdc5) with its parent block device (sda, sdb, sdc) without requiring advanced knowledge of all possible block device names (and thus groups), you could use the following expression, which would return group name “sda” for sda1, sda2, and sda3; group name “sdc” for sdc5; and so on.

dynamicGroup="^(.d.)"

groupName

You can assign instances to a predefined set of groups based on the name or value of the instances. The parameters are group name, followed by a regular expression. Any instance that matches the regular expression will become a member of the group. Instances can be members of more than one group if they match more than one regular expression.

For example, a Linux host may have physical disks sda, sdb, and sdc, along with Logical Volume Manager (LVM) disks dm0, dm1, and dm2. To auto-assign all LVM disks into group “LVM”, and all physical disks into group “physical”, you could use the following expression:

physical="sd.*" LVM="dm.*"

The regular expression must match the entire instance in order for the instance to be assigned to that group. Thus, it is usually necessary to end in regex wildcards, as shown in the previous example (i.e. “.*”). Additionally, predefined group names cannot contain spaces.

Instance Level Property

If you enter an Instance Level Property name (prepended with “auto.”), into the Parameters field, an instance group for each unique value of that ILP will be created. For example, if you wanted to group all instances that share a common port speed, you would enter the following:

auto.port_speed

This would result in unique groups being created for instances with port speeds of 100Mbps, 1Gbps, 10Gbps, and so on. Note that ILPs are case sensitive in this field. For more information on instance properties, see Resource and Instance Properties.

“Unmonitored” Instance Groups

If monitoring is disabled for an instance (or if newly discovered instances are initially set to be disabled per Active Discovery configurations), LogicMonitor will automatically create an instance group called “Unmonitored” and populate it with the unmonitored instance(s). You can disable monitoring for other instances by dragging them into this group. Conversely, you can re-enable monitoring for an instance by dragging it out of this group and into an active instance group. For more information on disabling monitoring, see Disabling DataSources.

Overview

The Instances tab is available from the Resources page. It displays when viewing multi-instance DataSources from the Resources tree. Multi-instance DataSources are DataSources that monitor objects (e.g. disks, server volumes, interfaces, etc.) that can potentially be present multiple times on a single device.

The Instances tab provides an overview table of all the instances found for a particular DataSource on a particular device. It’s a convenient way to quickly view or edit instance detail, as well as perform tasks in bulk such as disabling instances or disabling alerting on instances.

Editing Instances

Click the cogwheel icon in the Manage column of the instance table to open the Manage Instance dialog and edit instance details. If the instance was manually added, you have the ability to edit all instance details including instance name, value, and description. If the instance was added automatically by Active Discovery, only the description is available for editing. For more information on these instance details and the process of manually adding instances, see Adding Instances.

If Active Discovery is enabled for the DataSource, the Allow Active Discovery to overwrite the description option is available. When checked, this option allows the Active Discovery process to overwrite any description manually entered here. The lock icon that displays to the right of an instance description in the instance table depicts an open lock when this option is checked and a closed lock when it’s unchecked. For more information on Active Discovery, see Active Discovery.

You can also manage property assignment for an instance from the Manage Instance dialog. See Resource and Instance Properties for more information on instance properties.

Disabling/Enabling Instances

The Instances tab supports two methods for disabling/enabling instances:

• Manage Instance dialog. Check or uncheck the Enable alerting option found on the Manage Instance dialog (available by clicking the cogwheel icon in the Manage column of the instance table) to enable/disable an instance.
• Instance table. Place a checkmark to the left of one or more instances in the instances table and select Actions | (Disable|Enable) Instance.

Disabling an instance stops data collection for that instance. Upon disabling of an instance, LogicMonitor will automatically create an instance group named “Unmonitored” and populate it with the unmonitored instance. For more information on the impacts of disabling instances, see Disabling Monitoring for a DataSource or Instance.

Disabling/Enabling Alerting for Instances

To disable or enable alerting for an instance from the Instances tab, place a checkmark to the left of one or more instances in the instances table and select Actions | (Disable|Enable) Alerting. For more information on the impacts of disabling alerting, see Disabling Alerting.

Deleting Instances

The Instances tab supports two methods for deleting instances:

• Manage Instance dialog. Click Delete from the Manage Instance dialog (available by clicking the cogwheel icon in the Manage column of the instance table) to disable an instance.
• Instance table. Place a checkmark to the left of one or more instances in the instances table and select Actions | Delete.

Note: When an instance is deleted, all data collected for it (i.e. monitoring history) is also deleted.

Managing Instance Groups

LogicMonitor supports instance groups, allowing you to flexibly show relationships between the instances that are monitored under a DataSource for a single device. From the Instances tab, you can manually create or edit instance groups (assuming they are not automatically created groups), as well as move instances among groups. For more information on managing instance groups (both manual and automatic), see Instance Groups.

Note: In addition to displaying for multi-instance DataSources, the Instances tab also displays when viewing instance groups from the Resources tree, allowing you to view and edit instance configurations for just those instances in the group, rather than all instances found on the device for that DataSource.

LogicMonitor has DataSources to monitor web pages, processes, services, and UNC Paths. Because Active Discovery is disabled for these DataSources by default, you will need to add web pages, UNC paths, process, and services as instances on a per-device basis. The steps are outlined below:

1. On the Resources page, navigate to the device in the Resources tree.
2. Highlight the device in the Resources tree, and click the down arrow icon button located next to the Manage button for that device. From this dropdown menu, select “Add Other Monitoring“.
3. Edit the necessary configurations for each web page, process, service, or UNC path you are adding as a monitored instance. These configurations are detailed in the following sections.

Web Pages

The HTTP per Page DataSource will load the web page, and provide a status and the page load time:

Processes and Services

Linux processes will be monitored by the LinuxNewProcesses DataSource, Windows processes will be monitored by the WinProcessStats DataSource and Windows services will be monitored by the Microsoft_Windows_Services DataSource. For more information about monitoring Linux services, see LogicModules in Package.

Note: Instances will need to be manually added (using Add Monitored Instance) to a resource and applied to the Microsoft_Windows_Services DataSource to get output.

UNC Paths

To monitor a UNC share, whether a domain DFS share or otherwise, use the UNC Monitor DataSource. This DataSource will do a directory listing on the given UNC share and report success or failure.

To add a share to be monitored, select a Windows host in the hosts view. The monitoring of the UNC actually occurs on the Collector that monitors this host, but the results can be associated with any Windows host.

For Windows devices, the option to monitor UNC Paths is available in the Additional Monitoring settings.

The UNC Monitor DataSource will monitor the accessibility of the UNC path from the collector monitoring this device.

When specifying UNC Paths to monitor, make sure that the user account has the proper permissions to access the UNC share. By default the user specified by the property wmi.user is used to access the file. If you need to specify an alternative user, use the following properties to set the username and password for the Windows user:

The above device properties can be used to set from Manage Device > Add Property. For more information, see Resource and Instance Properties.

Overview

For every DataSource applied to a device, LogicMonitor attempts to discover one or more instances to monitor. (For more information on how DataSources get applied to devices, see How DataSources Get Applied to Resources.)

Some DataSources will only ever have one instance to monitor per device (e.g. ping), while others may identify multiple instances (e.g. disks, server volumes, interfaces, etc.) to monitor per device.

For single-instance DataSources, the instance is automatically added and data collection begins immediately. For multi-instance DataSources, instances can be automatically added into monitoring via LogicMonitor’s Active Discovery process, or they can be manually added into monitoring. In the following sections, we’ll discuss both of these methods.

Adding Instances via Active Discovery

Active Discovery is automatically run for multi-instance DataSources that have it enabled. It is a process by which LogicMonitor determines all of the similar components of a particular type on a given system. For each component “discovered”, an instance is created and data is collected for that instance. For a detailed discussion of LogicMonitor’s Active Discovery process, see Active Discovery.

Active Discovery typically runs on a schedule that is configured from the DataSource definition. However, there may be situations in which you do not want to wait for the next scheduled execution of Active Discovery in order to add an instance into monitoring. In these situations, Active Discovery can be manually initiated.

Manually Initiating Active Discovery

Before manually initiating Active Discovery, ensure the DataSource and/or instance are not disabled at the group level as this will prevent instances from being added into monitoring.

To manually initiate Active Discovery, follow these steps:

1. Navigate to the Resources page and, from the Resources tree, highlight the device for which you’d like to initiate Active Discovery.
2. Click the device icon in the upper right corner of the Resources page and select “Run Active Discovery” from the dropdown that appears.

   

   All multi-instance DataSources that are applied to the device and have Active Discovery enabled will execute the Active Discovery process.

Note: The act of manually initiating Active Discovery for a resource also causes the reevaluation of all PropertySources and DataSources in your account in terms of their application to the current resource, as discussed in Creating PropertySources and How DataSources Get Applied to Resources respectively. In addition, LogicMonitor will perform a basic system information discovery check, as discussed in Resource and Instance Properties.

Manually Adding Instances

Multi-instance DataSources that do not have Active Discovery enabled require that instances be added manually. An example of a multi-instance DataSource for which it may be appropriate to not enable Active Discovery is one that applies to an application that runs on a different port per device, and the list of ports is not exclusive to the application. In this case, it may be most efficient to manually add an instance of the application, specifying the port.

To manually add an instance into monitoring, follow these steps:

1. Navigate to the Resources page and, from the Resources tree, highlight the device for which you’d like to initiate Active Discovery.
2. Click the device icon in the upper right corner of the Resources page and select “Add Monitored Instance” from the dropdown that appears.
3. At the Add Monitored Instance dialog, complete the following configurations:
   • DataSource. From the DataSource field, select the DataSource for which you are adding an instance to be monitored. This field provides matching suggestions as you type and you must choose from one of the suggested options. Only multi-instance DataSources that have been applied to the current device and do not have Active Discovery enabled from their configurations are available for selection here.
   • Name. In the Name field, enter a name for the instance. Instance names are limited to 255 characters.
   • Wildcard value. In the Wildcard value field, enter the value that will be used by the DataSource to query this specific instance. For example, the value could be a specific port or SNMP OID index.

     Wildcard values are limited to 1024 characters. Ensure that you do not enter the following invalid ASCII characters as Wildcard values. They are: white space, :, =, \, and #. Note that # is valid but it can break Active Discovery (AD). You can replace these invalid ASCII characters with an underscore. Note that this could collide with other instances. For example, TEST_INSTANCE and TEST:INSTANCE can collide but it is reasonably rare.

   • Description. In the Description field, enter a description for the instance.
   • Group. From the Group field, select the instance group under which you would like to organize this instance. This field provides matching suggestions as you type and you must choose from one of the suggested options. If no instance groups have been explicitly set up, only the “@default” option is available which organizes the instance in the default “Ungrouped” group. For more information on instance groups, see Instance Groups.