Event-Driven Health Checks for Non-HTTP Applications
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current HTTP health check mechanisms are limited in accurately determining the health status of non-HTTP applications and services, often resulting in false positives and negatives, and are slow, with frequency limitations that hinder rapid detection of issues in critical systems like firewalls.
Innovation Solution
An event-driven health check service that uses an API gateway to perform detailed health status checks at high frequencies, supporting various protocols and protocols, and can trigger corrective actions based on the health status of applications, including non-HTTP workloads like firewall appliances.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If HTTP health check messages are sent to monitor application health, then the health status can be detected, but the detection accuracy is insufficient for non-HTTP applications and results in false positives and negatives
Solution Approach 1:
The patent introduces an intermediary system that translates non-HTTP application health checks into HTTP-compatible monitoring. A sidecar proxy or adapter component acts as a mediator between the non-HTTP application and the HTTP-based monitoring infrastructure, enabling accurate health status reporting without requiring changes to the core application protocol.
Solution Approach 2:
The patent replaces direct HTTP protocol interactions with a more generalizable health check mechanism. Instead of relying on HTTP-specific status codes and responses, the system uses a protocol-agnostic health verification approach that can adapt to any application type, substituting the mechanical HTTP interaction model with a flexible event-driven health reporting model.
2Speed
If HTTP health checks are performed frequently to detect issues rapidly, then the detection speed improves, but the system imposes limitations on check frequency
Solution Approach 1:
The patent implements periodic health checks with dynamically adjustable intervals. The monitoring system can configure check frequencies based on application criticality, historical performance data, and resource availability, performing more frequent checks for critical services and less frequent checks for non-critical applications, optimizing both detection speed and resource utilization.
Solution Approach 2:
The patent maintains continuous health monitoring through persistent connections and event-driven notifications. Instead of discrete periodic polls, the system establishes continuous monitoring channels that provide real-time health status updates, eliminating gaps between checks and ensuring uninterrupted detection capability for time-sensitive applications.
3Ease of operation
If simple HTTP status messages are used for health checks, then the configuration is easy and usage is simple, but the health status determination is inaccurate for non-HTTP workloads
Solution Approach 1:
The patent creates a universal health check framework that can monitor both HTTP and non-HTTP applications through a common interface. The system provides protocol-agnostic health verification capabilities that work across different application types, maintaining the simplicity of HTTP-based configuration while extending functionality to support diverse workloads including databases, message queues, and custom applications.
Data Source
AI summary
Techniques are disclosed for monitoring the health of a computing application, system or service. A health monitoring service performs event driven health status checks for applications that use non-HTTP workloads. To do so, heath status messages (e.g., HTTP status requests) are directed to an API gateway at a specified frequency. In response to each health status message, the API gateway triggers at least a first event driven function to perform a health check of an application. Results of the health-status check performed by the first event driven function may be written to a status database. Further, results of the first event driven function can result in additional event driven functions being triggered (e.g., to remove an unhealthy application from production use).