LogicModules

Creating a DataSource

DataSources are templates that define what numerical data should be collected, how it should be collected, and what values should be graphed and trigger alerts.

There are four sections included in every DataSource definition:

General Information

The General Information section includes identifying information about the DataSource. This includes the collection method that will be used to collect data, how often data will be collected, and from which devices data will be collected.


Name

The unique name of the DataSource.  As a best practice, this name should be descriptive: specify the platform or application name first, then specify a specific component of the platform.  

For instance: "Tomcat Threads-", or "Aruba Controller Power Supply-".

Displayed as

The name the DataSource will be displayed with on the Devices page.  This name does not need to be unique (e.g. there can be several DataSource that display as "CPU", as they apply to different kinds of devices).  As a best practice, the display name should be shorter than the full DataSource name.  For example, "Services" instead of "Windows Services", or "VIPs" instead of "Citrix Netscaler VIPs."

Note that the DataSource name and display name cannot include the operators and comparison functions available in LogicMonitor's datapoint expression syntax, as discussed in Complex Datapoints.

Description

The description that will be associated with this DataSource.  As a best practice, if the DataSource name is not unambiguous as to what the DataSource is collecting, the description field should provide enough information that someone seeing the name and the description will be clear what the DataSource does.

Technical Notes

This field can contain any technical notes associated with the DataSource.

Group

The DataSource Group to which the DataSource will be added.  If this field is left empty, the DataSource will not be added to a DataSource group.  If you enter text that does not match an existing DataSource Group, one will be created.

For example, all the Dell hardware monitoring DataSources are assigned the group Dell.  This collapses those DataSources to a single DataSource group entry that can be expanded.  

Applies To

The Applies To field defines which devices will be associated with this DataSource. This text entered here must be formatted in AppliesTo Scripting syntax.  

Select the "Test" option to display a list of all devices that will be added or removed when Applies To is changed.

Collection Interval

The Collect every field defines how frequently data is collected. This field should be set to a collection interval (i.e. polling cycle) that is appropriate for the type of data being collected. Metrics that change frequently (e.g. CPU) or require immediate attention in the event of an error (e.g. ping loss) should have a shorter polling cycle, such as one minute, whereas metrics that can tolerate a longer delay in alerting or change less frequently (e.g. drive loss in a RAID system, disk utilization) should have a longer polling cycle, such as five minutes.

Note: Longer polling cycles impose less load on the resource being monitored, the Collector, and the LogicMonitor platform.

Changing the Collection Interval

Once a DataSource has been applied to one or more resources and monitored instances are created for those resources, the underlying data storage is created with some dependency on the collection interval. In order to minimize data loss, this underlying data storage isn't updated when you change the collection interval for the DataSource.

This impacts how data is stored and displayed. For example, if the collection interval is decreased (e.g. reduced from 15 minutes to one minute), the data is collected and evaluated for alerts on the new schedule, but only stored (and hence graphed) according to the old schedule. In other words, 15 data values will be collected (one per minute according to the new collection interval), but instead of each being stored individually, the average of these 15 values will be what gets stored every 15 minutes (per the old collection interval).

Note: You can view the collection interval with which the underlying datastore was created by downloading a DataSource graph's raw data. The downloaded data will show timestamps for each new entry of collected data. For more information on downloading data from a DataSource graph, see Graphs Tab.

Overriding Collection Intervals at the Resource or Resource Group Level

You can override the collection interval for a DataSource on a particular resource or for all resources in a resource group by assigning a numeric polling interval (in minutes) to the following custom property at the resource or resource group level:

[DataSourceName].pollinginterval

Ensure that you are using the DataSource name and not display name; both are present in the DataSource definition. For more information on assigning properties to resources, see Device Properties.

Collector

The Collector field defines the mechanism that will be used to collect data.

Multi-instance?

If this option is checked, the DataSource will be multi-instance.  You should make your DataSource multi-instance if you know that there are multiple occurrences of the object you would like to monitor (e.g. multiple disks or volumes on a server). 

Active Discovery

If the DataSource is multi-instance (i.e. the Multi-instance option is selected in the General Information section), then you can use Active Discovery to manage the monitored instances of the DataSource.

Enable Active Discovery

A DataSource must be multi-instance to enable Active Discovery.

If enabled, LogicMonitor will automatically find a DataSource's instances on your device, determine their display names or aliases, and keep them up to date.

Disable discovered instances

If this option is checked, instances are placed in a disabled state when they are discovered. Monitoring will have to be manually enabled on specific instances.  

Checking this option is helpful if you would like to fine-tune your instances' datapoint thresholds prior to enabling monitoring. This ensures you do not receive a flood of alerts as soon as new instances are discovered.

Automatically delete instance

If this option is checked, LogicMonitor will automatically remove an instance from monitoring if a future Active Discovery iteration reports that it is no longer present on a device. As a best practice, you should uncheck this option if you would like to receive alerts for the instances of this DataSource even if they are not present. For example, you would likely not want this option checked if Active Discovery detects that a service should be monitored by finding a listening TCP port. This is because, if the service were to fail, the port would stop responding, Active Discovery would report the instance as no longer present, it would be removed from monitoring, and you would no longer receive alerts for it—at precisely the time you would want to receive alerts for it.

When automatically removing an instance from monitoring, you can choose how long the instance's monitoring history will remain in LogicMonitor:

  • Delete Immediately. An instance's monitoring history will be immediately removed from LogicMonitor upon the instance being determined not present.
  • Delete After 30 Days. An instance's monitoring history will remain in LogicMonitor for 30 days before being removed. If an instance is rediscovered within this 30-day window, the prior monitoring history will be associated with the new instance. This option is useful in cases such as replacing a failed network card, where you would want the old history visible once the new card is active. (You would not want the history kept if the new instance is not related to the old.)

Discovery schedule

This option controls how frequently Active Discovery will run to discover instances for this DataSource.

Discovery method

Defines the protocol (SNMP, WMI, NetApp API, Script, etc) employed by Active Discovery to find instances.

NOTE: If you choose to embed or upload your own Active Discovery script, you will be able to use our "Test Script" functionality. Selecting this button will return a table of all instances that would be discovered using the script. This is a good way to ensure that all instances you expect to capture are, in fact, being discovered.

For more detail, see our Data Collection Methods topic, which features specific instructions for each of the data collection protocols supported.

Filters

Enables you to refine which instances are added into monitoring via Active Discovery. If filters are added, instances must match the filter criteria in order to be discovered.  

As a best practice, you should ensure that any Active Discovery filters are described in the "comment" field, if not self explanatory.

Group method

Select how you'd like the instances of this DataSource to be grouped. Choose manual if you'd like to manually group monitored instances.  Note that if you select an automatic grouping method (e.g. grouping based on regular expression), you will not be able to manually change instance group membership.

Collector Attributes

Certain data collection methods require you to configure specific attributes in this section.  As a best practice, the Name field in the SNMP, JMX, etc. Collector Attributes section should reflect the name used by the entity that defined the object to be collected (i.e. use the oid object name for SNMP data, the WMI property name for WMI data, etc.). For more information, see the Data Collection Methods topic, which features specific instructions for each of the data collection protocols supported.

Datapoints

Each DataSource must have one or more datapoints that define what information to collect and store. Once datapoints are identified, they can be used to trigger alerts when data from a device exceeds the threshold(s) you've specified, or when there is an absence of expected data. For more information on configuring a DataSource's datapoints, see Datapoint Overview.