Managing DataSources Created by the Push Metrics API

For a resource to receive metrics through the Push Metrics REST API, the resource must be associated with a DataSource. The Datasource must be created initially via Push Metrics Rest API. For more information, see  Ingesting Metrics with the Push Metrics REST API.

DataSources created by the Push Metrics REST API are stored along with the other DataSources in the LogicMonitor platform and are managed like the existing DataSources.

DataSource Design

You can manage the DataSources created via Push Metrics REST API from the Settings page. You can also set the thresholds on the DataSource datapoints, which can be referenced in alert rules.

However, the DataSource has a few unique attributes that allow them to support push model data ingestion. These unique attributes and limitations are discussed in the following sections.

Push_Modules Designation

DataSources that push metrics to resources will have a designation of “push_modules” as their collection method type (specified by the Collector field in a DataSource designation). 
You cannot modify the DataSource designation via the interface.

Active Discovery Disabled

DataSources created by the Push Metrics API support multiple instances. However, you cannot discover the instances by the Active Discovery Method as the DataSource is dependent on the instance information; and the metrics pushed via the API request.

LogicMonitor uses identical logic to disable the other DataSource configurations relevant only for the pull model of data collection.
For example, LogicMonitor disables the ability to set a collection interval and the ability to alert on the absence of data (known as No Data alerts).

AppliesTo Statement

All DataSources created by the Push Metrics REST API will have an AppliesTo statement that explicitly associates that DataSource with the resource that accompanies it in the API call.
For example, if an API call instructs the Push Metrics REST API to ingest metrics for resource A using DataSource B:

• A unique tag associated with DataSource B is added as a value to resource A’s system.pushmodules property.
• The AppliesTo statement for DataSource B will only associate with resources that carry its tag as a value in their system.pushmodules properties. It does this through the hasPushModules() function, which is identical in concept to the hasCategory() function. For more information on AppliesTo statements, see AppliesTo Scripting Overview.

The PushDS1cstern DataSource shown in the image has an AppliesTo statement that explicitly associates it with the resource (via the assignment of the system.pushmodules property to the resource) that accompanies it in the API call. This AppliesTo statement is not available for editing.

Managing Datapoints

Datapoints are created by the API request and cannot be modified or deleted from the LogicMonitor interface. In addition, only complex datapoints can be added to the definitions of DataSources created by the Push Metrics REST API.
You cannot edit the datapoints created by the API request; however, you can apply thresholds to the datapoints.

Managing Instances

You cannot discover the instances created by the API request using LogicMonitor’s Active Discovery process. In addition, you can manually delete the instances created by a Push Metrics DataSource from the portal interface or delete instances using standard REST API. However, the instances cannot be deleted via the Push Metrics REST API.

Cloning DataSources

You can clone the DataSources by navigating to Settings > LogicModules > DataSources > Select the required DataSource and click Clone.

Deleting DataSources

You can delete Push Metrics DataSources through the LogicMonitor interface similar to other DataSources; you cannot delete Push Metrics DataSources through the Push Metrics REST API. Once deleted, any data pushed to that DataSource creates a request for creating another new DataSource. 

Auto Delete Push Metrics Instances 

Any Push Metrics instance that has not received data for the last 45 days and is dormant will be automatically deleted. This automatic deletion allows you to control the number of inactive instances on your portal. For example, if we have Instance1 which has not received data for the last 30 days, and Instance2 which has not received data for the last 50 days, then the Push Metrics will detect Instance2 and automatically delete it.