Monitoring solutions can either pull monitoring information from devices by querying those devices, or the devices themselves can use code to push data using an API into the monitoring system. Both work equally as well but have separate use cases. It is not always possible to query a device remotely, which means asking the device itself to send the data out to the monitoring platform is easier. Keep reading to learn more about push metrics and when it makes the most sense to use it.
In this blog we will cover:
As computing architecture evolves into more ephemeral, transient, and stateless instances, the ability to bypass collectors and push data directly to a monitoring platform for ingestion is vital. A few prominent broad use cases for push metrics include:
Serverless computing services such as AWS Lambda are well suited for the push model of data ingestion.
The push metrics REST API provides the ability to report the data from within the app itself, without the need to define or configure external entities. This is helpful for monitoring 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.
Many of today’s computing instances are transient in nature (for example, containers, batch jobs, services running as a cluster, scripts, cron jobs, and so on). Their locations, time to live (TTL), and other attributes are completely 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.
| Use Case/Description | Metrics |
|---|---|
| Applications running on transient compute Container/VM supporting autoscaling | Number of API calls served by an application running within the container -From within the application running within a container, intercept the API calls and report periodically Resource utilization by application -From within the application running within a container, intercept the API calls and report periodically |
| Custom business metrics Push business metrics for business service (running on multiple hosts/containers). Agnostic to the language of the business application. | Number of new orders Number of orders shipped Purchase rate |
| IoT devices | Temperature Production count Device availability |
| Serverless computing services AWS Lambda | Number of times Lambda functions are invoked per minute -From within the function that has been invoked, send the data on each invocation Processing time/lifetime of Lambda instance -Compute the time taken to serve the request and send it before terminating the called function |
| Synthetic monitoring | Availability Response Errors |
| Ticket management systems Using Jira as an example, as tickets are created by various stakeholders, JIRA REST APIs can be used to collect custom data about the tickets which can then be sent to LogicMonitor. | Number of new tickets Number of tickets closed Number of tickets created for priority stakeholders |
| Transient systems Lambda functions are invoked on events performed by AWS services such as S3, DynamoDB, Kinesis, SNS, and CloudWatch. Invocation is purely random and the code executed is stateless on each invocation; hence only instant data can be reported. | Cron job -Number of tasks processed Script -Status of the script execution launched for either sending events, remote action, or creating tickets -Parse logs and send metrics Script for OS monitoring of CPU usage, memory usage, disk I/O, network usage -Infrastructure in use by each container and overall across all containers -Use a PowerShell script or executable to collect the data and send it periodically to LogicMonitor -Exporter plug-in for OpenTelemetry, Nagios, or other technology could also be used |
If your device only connects periodically to the internet and has a dynamic IP address, using traditional pull mechanisms to extract monitoring data is not going to work. Push metrics here would be the only way to access monitoring data.
The push model employed by push metrics could theoretically make it difficult to control the volume of data the monitoring system is receiving in a larger IoT environment. If you are leveraging push metrics for a large sensor network this could theoretically overwhelm the monitoring platform. Also, security for pushing metrics is harder to configure as you need to apply local TLS certificates to every device communicating with the platform.
LogicMonitor’s push metrics feature allows you to send metrics directly to the LogicMonitor platform via a dedicated API, removing the need to route the data through a LogicMonitor Collector. Once ingested, these metrics are presented alongside all other metrics gathered via LogicMonitor, providing a single pane of glass for metric monitoring and alerting.
The push model employed by push metrics, as opposed to the pull model that is traditionally employed by our DataSources, is beneficial across many use cases where the installation of a collector is cumbersome or not feasible.
We asked our customer, Nuno Rosa, Enterprise Architect and Monitoring Specialist at Infosys his thoughts on our new push metrics capabilities. Here’s what he had to say:
“LogicMonitor’s push metrics API provides endpoints that enable integrators to push raw data from an external source. Bi-directionality between LogicMonitor and other applications, we’ll gain new momentum with the ability to push metrics (i.e. ServiceNow incident information attached to alerting and the ability to see incident progress and interactions from the LogicMonitor console). The ability to push metrics will also allow us to send business-centric data into LogicMonitor, enabling additional observability into operational intelligence and diversifying the user audience to include non-technical personas.
Serverless computing is becoming a trend within major corporations and becoming a key accelerator for green policies by optimizing power usage (PuE). Push metrics will become a must-have to adapt to new monitoring capability requirements.”
© LogicMonitor 2025 | All rights reserved. | All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
Blogs
See only what you need, right when you need it. Immediate actionable alerts with our dynamic topology and out-of-the-box AIOps capabilities.
