Replicated Application Container Anomaly Filtering

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current services for automatic deployment, scaling, and operation of application containers fail to monitor the health of the application itself, leading to instability when replicated pods are generated across a cluster of nodes, as they only focus on pod health rather than individual application container health.

Innovation Solution

A method to identify and address anomalies in URI requests between replicated application containers by determining the root cause of errors and dynamically applying rules to drop specific URI requests that cause errors, enhancing fault tolerance by preventing further instability and allowing for modification of application configurations or container templates if necessary.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If current services monitor only pod health rather than individual application container health, then deployment and scaling operations are simplified, but application container stability and reliability deteriorate

Engineering Contradiction:
Improvedeployment and scaling operation simplicityVSAvoidapplication container stability
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent segments the health monitoring function from the pod level to the individual application container level. Each application container within a pod is monitored independently for anomalies in URI requests, allowing granular detection of failures while maintaining simplified pod-level deployment and scaling operations. This segmentation enables the system to track individual container health without complicating the overall pod management workflow.

Inventive Principle:
Principle #1Segmentation

2Productivity

If replicated pods are generated across a cluster of nodes, then system scalability and load distribution are improved, but anomaly propagation between containers increases

Engineering Contradiction:
Improvesystem scalabilityVSAvoidanomaly propagation
Core Design Contradiction:
ProductivityVSObject-generated harmful factors

Solution Approach 1:

The patent extracts the anomaly detection and filtering logic from the replicated container ensemble and centralizes it in the anomaly filter component. When anomalies are detected in any replicated application container, the filter identifies the root cause and generates a filter rule that is applied across all replicated containers, preventing anomaly propagation while maintaining the scalability benefits of having multiple replicated pods across the cluster.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent implements a feedback mechanism where anomaly detection in one replicated container triggers the generation of filter rules that are fed back to all replicated containers. This feedback loop ensures that when an anomaly is detected in any container within the replicated set, the system responds by applying protective filtering rules across the entire replicated group, preventing the anomaly from propagating while preserving the scalable replicated architecture.

Inventive Principle:
Principle #23Feedback

3Measurement precision

If anomaly monitoring is implemented across all URI requests, then detection precision is improved, but system complexity and computational overhead increase

Engineering Contradiction:
Improveanomaly detection precisionVSAvoidmonitoring system complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The patent applies partial monitoring by focusing anomaly detection specifically on URI requests rather than all possible container activities. The anomaly filter monitors URI requests for patterns and anomalies, identifies root causes, and generates filter rules based on this partial but targeted observation. This selective monitoring approach maintains high detection precision for application-level failures while avoiding the complexity of comprehensive full-system monitoring.

Inventive Principle:
Principle #16Partial or excessive action

Data Source

PatentUS10585745B2Prevention of application container failure between replicated containers
Publication Date: 2020.03.10 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • US10585745B2 patent drawing
  • US10585745B2 patent drawing
  • US10585745B2 patent drawing

AI summary

A computer-implemented method includes identifying a set of anomalies during a runtime of a first set of replica application containers. The computer-implemented method further includes determining a root cause of the set of anomalies based, at least in part, on comparing uniform resource identifier (URI) requests generated by each replica application container in the set of replica application containers. The computer-implemented method further includes determining a first set of URI requests can be dropped, wherein each URI request in the first set of URI requests includes the root cause of the set of anomalies. The computer-implemented method further includes dropping the first set of URI requests during the runtime of the first set of replica application containers. A corresponding computer system and computer program product are also disclosed.