Monitor Anything, Anywhere With Push Metrics

Monitor Anything, Anywhere With Push Metrics

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:

Use Cases for Push Metrics

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 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 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.

Transient Resource Monitoring

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.

Detailed Use Cases for Push Metrics

Use Case/DescriptionMetrics
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 devicesTemperature
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 monitoringAvailability
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

What Are Some Benefits of Using Push Metrics Instead of Pull?

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. 

What Are Some Limitations of Push Metrics?

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 Approach to Push Metrics

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. 

Enabling Observability With Push Metrics

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.”