Comment on page
About the StackState Agent
StackState Self-hosted v4.5.x
This page describes StackState v4.5.x. The StackState 4.5 version range is End of Life (EOL) and no longer supported. We encourage customers still running the 4.5 version range to upgrade to a more recent release.
The StackState Agent functions as a collector and gateway. It connects to external systems to retrieve data and pushes this to StackState.
StackState Agent V2 can be run on Linux or Windows systems or inside a Docker container. It is not necessary to deploy the StackState Agent on every machine to retrieve data. Each deployed StackState Agent can run multiple checks to collect data from different external systems.
StackState Agent architecture
In StackState, the StackState Agent V2 StackPack includes all the settings required to integrate with a number of external systems. Data from other external systems can be retrieved by installing additional StackPacks in StackState.
To integrate with an external system, an Agent must be deployed in a location that can connect to both the external system and StackState. An Agent check configured on the Agent can then connect to the external system to retrieve data.
Deployment instructions, commands to work with StackState Agent V2 and other platform-specific details can be found on the pages listed below:
StackState Agent connects to the StackState Receiver API.
For StackState running on Kubernetes, the Receiver API is hosted by default at:
For StackState running on Linux, the Receiver API is hosted by default at:
For the StackState SaaS product, the address of the StackState Receiver API will be provided on the StackState UI StackPack page after a StackPack has been installed.
StackState Agent V2 consists of up to four different processes -
cluster-agent. To run the basic Agent, the resources named below are required. These were observed running StackState Agent V2 v2.13.0 on a c5.xlarge instance with 4 vCPU cores and 8GB RAM. They give an indication of the overhead for the most simple set up. Actual resource usage will increase based on the Agent configuration running. This can be impacted by factors such as the Agent processes that are enabled, the number and nature of checks running, whether network connection tracking and protocol inspection are enabled, and the number of Kubernetes pods from which metrics are collected on the same host as the Agent.