Use Cases for Push Metrics
Last updated on 09 September, 2024As 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.
| Use Case | 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 |
| Web applications Gather business metrics on a separate thread and report the data to LogicMonitor via that thread. | – Number of website hits – Time taken to serve a request – Concurrent sessions |