With the Infrastructure agent, you can monitor not only individual servers, but understand how your service performs as a whole. Infrastructure supports Amazon Linux, CentOS, Debian, RHEL, and Ubuntu as well as Windows Server.
All of the agents exhibit a common set of behaviors, which are explored here.
During startup the agent will:
- Register a signal handler.
- Set the loggers.
- Load the configuration from file, environment variables and call arguments.
- Register plugins for harvesting inventory, samplers and integrations.
http_server_enabled(used only by statsD integration) the agent will open an http port (by default, 8001) for receiving data.
Startup duration before harvesting and sending data is usually less than 6 seconds.
Monitoring and resource caps
By default, the Infrastructure agent runs in a single core.
The Infrastructure agent checks every second if there are events to send and, if there are, it sends them to the New Relic collector. Events that might be sent include: the default Infrastructure events, or events collected by New Relic integrations.
For descriptions of the default Infrastructure events and their collection frequencies, see Infrastructure events.
Integration monitoring is done by executing integration commands at given intervals (set in the config files) and reading their stout/err. The more integrations you enable, the greater the footprint of the agent. For more information, see the documentation for specific integrations.
When a shutdown signal is received, the agent stops all the registered plugins and integration processes.
The agent runs as a service. On installation, we set up all the service manager-required files, such as the systemD.service file. In case of a catastrophic failure, the service manager configuration will restart the agent.
There are no auto updates to agents. New versions of the agent should be installed manually through the appropriate package manager (APT, yum, Zypper) in Linux; in Windows you need to manually download the msi package and install it with msiexec.exe.
If a request made to the ingest service is unsuccessful, the payload is discarded; subsequent requests follow an exponential backoff pattern until one succeeds. In the case of inventory, we store in cache files the deltas between system states. On failure, these deltas are not deleted but are reused on requests that follow.