Managing Resources that Ingest Push Metrics
Last updated on 15 December, 2024By 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.
Standard Devices/Kubernetes Containers | AWS Resources | GCP Resources | Azure Resources |
system.display namesystem.deviceid system.hostname system.collectorid system.sysoid System.ips auto.network.mac_address | system.display namesystem.deviceid system.aws.resourceid system.aws.arn | system.displayname system.deviceid system.gcp.resourceid system.gcp.resourcename system.gcp.projectId system.cloud.category system.gcp.resourceid | system.displayname system.deviceid system.azure.resourceid system.azure.resourcename |
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.
The Push Metrics REST API has an endpoint dedicated to updating a resource’s properties. For more information, see Updating Resource Properties with the Push Metrics REST API.
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.
If the deleted resource was created using the Push Metrics REST API and only receives data from push model DataSources, it is immediately deleted (unlike other resources, which are moved to the Recently Deleted folder for seven days).