You can use LogicMonitor’s .NET SDK to interact with the Push Metrics REST API.

Downloading and Installing the .NET SDK

1. Download the .NET SDK from NuGet.
2. Install the SDK by executing the command applicable to your environment:

• Package Manager

Install-Package Logicmonitor.DataSDK -Version 0.0.7-alpha

• .NET CLI

dotnet add package Logicmonitor.DataSDK --version 0.0.7-alpha

When the .NET SDK installs, you can use it to interact with the Push Metrics REST API. For more information about using the SDK with your project, including API references, see the following: 
https://github.com/logicmonitor/lm-data-sdk-dotnet

You can use LogicMonitor’s Push Metrics REST API to programmatically add or update properties for existing resources. However, system (system.xyz) and (auto.xyz) properties are not added to the payload.

Request Information

The resource property ingestion endpoint is used to add or update one or more properties for an existing resource.

For details on the fields used in this request, see Ingesting Metrics with the Push Metrics REST API.

You can use LogicMonitor’s Push Metrics REST API to programmatically add or update properties for existing instances. However, system (system.xyz) and (auto.xyz) properties are not added to the payload.

Request Information

The instance property ingestion endpoint is used to add or update one or more properties for an existing instance.

For details on the fields used in this request, see Ingesting Metrics with the Push Metrics REST API.

Rate limits are imposed for requests to LogicMonitor’s Push Metrics REST API.

The following table lists default rate limits:

If internal APIs are used to throttle the ingested data, there may be a delay in the appearance of new devices or properties being used. For example, ingesting bulk data with new resources or property updates causes an ingestion delay for the updated new devices or properties. LogicMonitor applies internal throttling which is indicated in the audit logs and you would need to make the request again. The metrics appear only on the successful creation of the devices.

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. 

By default, the Push Metrics REST API is designed to push metrics to existing resources in your LogicMonitor portal. However, you can override the default settings for Push Metrics REST API by using the API request, which creates a new resource if no existing resource matches the query. For more information, see Ingesting Metrics with the Push Metrics REST API.

All the resources, including the resources created by the Push Metrics REST API, are stored in the LogicMonitor platform. In addition, a single resource can both ingest push metrics via the Push Metrics API and receive metrics via DataSources that uses the pull-based collection methods.

Resources that ingest push metrics are displayed alongside other resources on the Resources page.

You can create resources and add them to a resource group via the system.groups property.
Note: The resource group must be an existing resource group, and you must have manage permission for resource groups.

A heartbeat is sent to the system for the resources that receive the data via Push Metrics API. If the system does not receive the heartbeats within regular intervals, the resource is displayed as dead.

Resource Design

Resources that receive data via the Push Metrics REST API are similar to the other resources in your LogicMonitor portal. You can associate the resources with multiple DataSources that are grouped into resource groups. In addition, the resources can be referenced in alert rules.

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

Unique Attribute: system.pushmodules Property

Any resource referenced in a Push Metrics REST API call will be assigned a property named system.pushmodules. Similar to the system.categories property, the system.pushmodules property is automatically updated with values that associate it with its corresponding Push Metrics DataSource(s). 

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 that is created for DataSource B will only associate with resources that carry its tag as a value in their system.pushmodules properties. For more information on DataSource design, see the Managing DataSources Created by the Push Metrics API section of this guide.

The PushDS1cstern DataSource shown here will only associate with resources whose system.pushmodules property reference its name.

Limitations

There are certain limitations for resources, which are created by the Push Metrics REST API and receive data only from push model DataSources.
Following are the limitations in the context of the push (vs. pull) communications model:

• Manually run Active Discovery for the resource
• Access the resource via a remote session
• Manually poll an instance for current datapoint values (as initiated from the Raw Data tab)
• Debug data collection for an instance (as initiated from the Raw Data tab)

Resource Matching

When a request for metrics ingestion is submitted via the Push Metrics REST API, LogicMonitor searches for the resources that have resource IDs as properties and pair the request with an existing resource in the portal.

If multiple resources are found with specified resource IDs, an error will occur. Hence, you must ensure that the resourceIds field has unique key-value pairs in its array to get the desired result.

Following is a list of system properties, organized by resource type, that can be considered for use in the API query. You can use any resource property in the query. For more information on resource properties, see Resource and Instance Properties.

If no existing resources are returned, and the create query parameter is set to TRUE in your request (the default settings is FALSE), a new resource is created, which has the specified resource IDs set on it.

Deleting Resources

You can detect the resources that receive push metrics via the LogicMonitor interface similar to other resources. However, you cannot delete these resources using Push Metrics REST API. Once the resource is deleted, any data pushed to that resource is ignored.

You can use LogicMonitor’s Python SDK to interact with the Push Metrics REST API.

Downloading and Installing the Python SDK

Install the SDK from PyPl by executing the following command:

pip install logicmonitor_data_sdk

Alternatively, you can download the SDK files directly from PyPI.

When the Python SDK installs, you can use it to interact with the Push Metrics REST API. For more information about using the SDK with your project, including API references, see the following: 
https://logicmonitor-data-sdk-py.readthedocs.io/en/latest/

You can use LogicMonitor Push Metrics REST API to programmatically ingest metrics for multiple instances associated with single or multiple resources and DataSource.

The Push Metrics REST API requires authorization using either the LMv1 API token or the Bearer token. For more information, see API Tokens and Bearer Token.

Request Information

The metric ingestion endpoint is used to push metrics of one or more instances associated with a DataSource and resource. Only one resource and DataSource is supported per request. If this is the first time metrics are being pushed to a resource, this request will result in a new DataSource and optionally a new resource (depending on parameters).

Support for Ingesting Multiple Resources

The rest/v2/metric/ingest API allows the ingestion of multiple resources at a time in a single API call. The create and match type API parameters apply to all the multiple ingested resources. 

Multiple Resource Payload Ingestion

[
    {
        single resource payload
    },
    {
        single resource payload
    }
]

Multiple Resource Response

{
    "success": false,
    "message": "Some events were not accepted. See the 'errors' property for additional information.",
    "errors" : [
        {
            "code": <custom code>,
            "message": "The request has been accepted for processing, but the processing has not been completed.",
            "resourceIds": {
                "system.displayname": "test088"
            },
        },
        {
            "message": "Resource Name is mandatory.",
            "resourceIds": {
                "system.displayname": "test096"
        },
    }
}

Example of Ingesting Metrics using Push Metrics REST API

The following Python 3 example monitors CPU utilization.

#!/usr/bin/env python3
import time, os, sys
import hmac, hashlib, base64
import requests
import json
import psutil

#--------------------------------------
# Constants - Do not change
#--------------------------------------
resource_path = '/metric/ingest'
headers =  {
	   'Content-Type': 'application/json'
	  }

#---------------------------------------
# Change Values below as per your setup
#---------------------------------------
def get_params():
	# Account info
	# Your account name
	Company = "ABC"
	# User account Access Id for which it must have permissions to manage resources and manage LogicModules 
	AccessId = "6wDEvh73taGMPP43SSmF"
	AccessKey = 'Q)cfY2w8u[G97jkz5^P8{HT)g-uq[6+E8LL%Mb{^'

	url = "https://"+Company+".logicmonitor.com/rest"+ resource_path
	return url, AccessId, AccessKey


#--------------------------------------------
# Function to send metric data to LM Platform
#--------------------------------------------
def send_metrics(timestamp, body):
		url, AccessId, AccessKey  = get_params()
		req_var =  "POST" + str(timestamp) + body +resource_path;
		signature = base64.b64encode(bytes(hmac.new(
                            bytes(AccessKey, 'latin-1'),
                            bytes(req_var, 'latin-1'),
                            digestmod=hashlib.sha256
                        ).hexdigest(), 'latin-1')).decode('latin-1')
		auth = "LMv1 "+AccessId+ ":"+ signature+":"+str(timestamp)
		headers['Authorization'] =  auth
		try:
			response = requests.post(url, verify=True, headers=headers, data=body,  params={"create":'true'})
			if response.status_code != 202:
				print('Failed to send metric. Error:', response.status_code, response.text)
			else:
				print("SUCCESS :",response.text)
		except Exception as e:
			print("Unable to connect. Error: ", e)

#--------------------------------------------
# Prepare REST payload
#--------------------------------------------
def prepare_request_body(metric, timestamp, data_value):
	return json.dumps({
	    "resourceName": metric["device_name"],
	    "resourceIds": {
			"system.displayname": metric["device_name"],
			"system.ips": metric["device_ip"]
	    },
	    "dataSource": metric["data_source"],
	    "dataSourceDisplayName": metric["data_source"],
	    "instances": [
			{
				"instanceName": metric["instance"],
				"instanceDisplayName": metric["instance"],
				"instanceProperties": {
					"version": "1",
				},
				"dataPoints": [
					{
						"dataPointName": metric["data_point"],
						"dataPointType": "GAUGE",
						"dataPointAggregationType": "sum",
						"values": {
							str(timestamp//1000): data_value
						}
					},
		    	]
			},
	    ]
	}).replace("'", '"')


#------------------
#====  MAIN =======
#------------------
if __name__ == "__main__":
	my_metric = {}
	my_metric["device_name"] = os.uname()[1]
	my_metric["device_ip"] = "192.168.1.1"
	my_metric["data_source"] = "CPU"
	my_metric["instance"] = "cpu-1"
	my_metric["data_point"] = "cpu_utilization"
	while True:
		timestamp = int(time.time()*1000)
		data_value = psutil.cpu_percent()

		body = prepare_request_body(my_metric, timestamp, data_value)
		send_metrics(timestamp, body)
		time.sleep(10)

You can use the LogicMonitor Push Metrics REST API to programmatically push metrics for multiple instances associated with a single resource and DataSource. You can also manage some aspects of the associated resource and DataSource.

Base URL: https://{ACCOUNTNAME}.logicmonitor.com/rest
Where ACCOUNTNAME is replaced with your LogicMonitor account name.

Authentication

The Push Metrics REST API requires API token authentication. LogicMonitor REST API uses the same API token authentication. For more information, see Using LogicMonitor’s REST API.

Note: At a minimum, the role associated with the API-only user account must have permissions to manage resources and manage LogicModules. For more information on creating roles and API-only user accounts, see Roles and Users respectively.

Aggregation Interval

The Push Metrics REST API pushes datapoint metrics to instances once per minute. If data is sent frequently (sub-minute intervals), the values are cached, then aggregated using the aggregation method specified. The aggregated value is stored as the datapoint value.

LogicMonitor supports the following aggregation methods:

• Average
• Sum
• Min
• Max
• Percentile
• None (This is the latest value)

The behavior of each aggregation method when data is pushed at sub-minute intervals is exemplified in the following table.

Endpoints

The Push Metrics REST API consists of three endpoints:

• https://{ACCOUNTNAME}.logicmonitor.com/rest/metric/ingest. This endpoint ingests multiple metrics for multiple instances associated with a single resource and DataSource. See Ingesting Metrics with the Push Metrics REST API.
• https://{ACCOUNTNAME}.logicmonitor.com/rest/resource_property/ingest. This endpoint updates or adds new properties for existing resources. See Updating Resource Properties with the Push Metrics REST API. 
• https://{ACCOUNTNAME}.logicmonitor.com/rest/instance_property/ingest. This endpoint updates or adds new properties for existing instances. See Updating Instance Properties with the Push Metrics REST API.

Status Codes

The status codes returned by the Push Metrics REST API are detailed in About REST API v2.

As computing architecture evolves into more ephemeral, transient, and stateless instances, the ability to bypass Collectors and push data directly to the LogicMonitor platform for ingestion is vital. A few prominent broad use cases for Push Metrics include:

• Serverless computing services monitoring. Serverless computing services such as AWS Lambda are well suited for the push model of data ingestion.
• Custom metric monitoring. The Push Metrics REST API can report the data from the application; without the need to define or configure external entities. The push Metrics REST API helps monitor health metrics in a DevOps environment (for example, CI/CD pipeline metrics, autoscaling application metrics, and so on) and business metrics such as the number of new orders.
• Transient resource monitoring. Many of today’s computing instances are transient (for example, containers, batch jobs, services running as a cluster, scripts, cron jobs, and so on). Instance locations, time to live (TTL), and other attributes are transactional. Typically, these instances are also stateless and do not have any historical information about themselves. Pulling data from these transient resources using traditional resource monitoring methods is a complex undertaking; pushing the data, on the other hand, is a very efficient monitoring model.

The following table lists some use case categories for the various types of metrics that you may want to send directly to LogicMonitor.