Aggregated health monitoring of a cluster during test automation

1. A system, comprising:

a cluster of nodes, wherein the cluster includes an application programming interface (API) server and two or more components;

a memory; and

a processor in communication with the memory, wherein the processor is configured to:

initialize an interface to the API server, wherein the interface is operable to send status information from the two or more components within the cluster via a single output stream;

configure the API server, via the interface, to modify the single output stream of the API server to output status information associated with a first component of the two or more components within the cluster, wherein the single output stream sends the status information external to the cluster;

aggregate the status information by receiving status information from the first component and a second component within the cluster, determining whether the status information from the second component affects the first component, and upon determining that the status information from the second component does affect the first component, combining the status information from the first component with the status information from the second component;

determine, based on the aggregated status information received from the API server, whether the cluster is at a failure point; and

in response to determining that the cluster is at a failure point, set an execution signal to false, wherein the execution signal is accessible to an automation tool in communication with the cluster.

2. The system of claim 1 , wherein one or more of the components includes applications executing on the cluster.

3. The system of claim 1 , wherein upon detecting that the execution signal is set to false, the automation tool stops sending stimulus to the cluster.

4. The system of claim 3 , wherein stimulus includes inputs to an application executing in the cluster, wherein execution of the application affects the first component.

5. The system of claim 3 , wherein stimulus includes one or more inputs sent to one or more components within the cluster.

6. The system of claim 1 , wherein the execution signal is accessible through Hypertext Transfer Protocol interface.

7. The system of claim 1 , wherein the processor is further configured to:

store the received status information external to the cluster.

8. The system of claim 1 , wherein the automation tool is stress testing the first component.

9. The system of claim 1 , wherein the processor is further configured to:

in response to determining that the cluster is stable, set an execution signal to true.

10. A method, comprising:

initializing an interface to an application programming interface (API) server, wherein the interface is operable to send status information from two or more components within a cluster via a single output stream;

configuring the API server, via the interface, to modify the single output stream of the API server to output status information associated with a first component of the two or more components within the cluster, wherein the single output stream sends the status information external to the cluster;

aggregating the status information by receiving status information from the first component and a second component within the cluster, determining whether the status information from the second component affects the first component, and upon determining that the status information from the second component does affect the first component, combining the status information from the first component with the status information from the second component;

determining, based on the aggregated status information received from the API server, whether the cluster is at a failure point; and

in response to determining that the cluster is at a failure point, setting an execution signal to false, wherein the execution signal is accessible to an automation tool in communication with the cluster.

11. The method of claim 10 , wherein one or more of the components includes applications executing on the cluster.

12. The method of claim 10 , wherein upon detecting that the execution signal is set to false, the automation tool modifies stimulus sent to the cluster.

13. The method of claim 12 , wherein modifying stimulus sent to the cluster includes stopping all stimulus sent to the cluster.

14. The method of claim 12 , wherein stimulus includes one or more inputs sent to one or more components within the cluster.

15. The method of claim 10 , wherein the automation tool is executing a chaos test on the cluster.

16. The method of claim 10 , further comprising:

in response to determining that the cluster is stable, setting an execution signal to true.

17. A non-transitory machine readable medium storing code, which when executed by a processor is configured to:

initialize an interface to an application programming interface (API) server, wherein the interface is operable to send status information from two or more components within a cluster via a single output stream;

configure the API server, via the interface, to modify the single output stream of the API server to output status information associated with a first component of the two or more components within the cluster, wherein the single output stream sends the status information external to the cluster;

aggregate the status information by receiving status information from the first component and a second component within the cluster, determining whether the status information from the second component affects the first component, and upon determining that the status information from the second component does affect the first component, combining the status information from the first component with the status information from the second component;

determine, based on the aggregated status information received from the API server, whether the cluster is at a failure point; and

in response to determining that the cluster is at a failure point, set an execution signal to false, wherein the execution signal is accessible to an automation tool in communication with the cluster.

18. The non-transitory machine readable medium of claim 17 , wherein when the code is executed the processor is further configured to:

store the received status information external to the cluster.

19. The non-transitory machine readable medium of claim 17 , wherein when the code is executed the processor is further configured to:

in response to determining that the cluster is stable, set an execution signal to true.