Agent architecture and admin


The OpsClarity agent is the primary source for collection of application and infrastructure data from your hosts. If AWS is used as the infrastructure cloud platform, then the data collected via AWS 3rd party account access acts as a secondary source.

Internally, there are four major parts to the OpsClarity agent:

  • Forwarder
  • Watchdog
  • OpsClarity collectd plugins
  • OS & Network Data Collector


The forwarder

The forwarder does most of the work by forwarding the collected data back to the OpsClarity cloud service at a frequency of once every 30 seconds.  It only ever initiates an outbound connection and never listens for any inbound connection, so there is no need to reconfigure your firewall. It sends metrics, events, and meta data back to the cloud and receives configuration updates back from the cloud as necessary.

Inside the agent, the forwarder launches collectd and it's associated plugins, as well as the OS & network data collectors.  It also interfaces with custom apps through a statsd API as well as custom metric REST API.  

The forwarder may also be restarted by the watchdog if it ever fails or otherwise stops running.


The watchdog

There is only one thing the watchdog needs to do, and that is keep the forwarder running.  It is a cron job that watches the health of the forwarder, and will restart it whenever needed to ensure the continued data collection.


OpsClarity collectd plugins

We use collectd (and many of its plugins) to gather statistics about the supported integrations running on the system as well as standard OS metrics such as those related to CPU, memory, disk and network activity. 


OS & network data collector

For those things that collectd doesn't access (such as certain network data and some operating system information) we have our OS & network data collector.  This collector is responsible for collecting process data (by running a variant of the "ps" unix command) and network data (by running a variant of the "netstat" unix command).




Start the agent

/sbin/start opsclarity-agent
service opsclarity-agent start


Stop the agent

/sbin/stop opsclarity-agent
service opsclarity-agent stop


Check status of the agent

/sbin/status opsclarity-agent
service opsclarity-agent status


Default logs directory


Uninstall the agent

/opt/opsclarity/agent/current/scripts/ -c uninstall


For help on integrating your own custom metrics, head on over to our custom metric API section.


Routing agent traffic through a HTTP Proxy

In case the individual hosts are not connected to the Internet, a HTTP proxy can be used to route agent traffic from your environment to the OpsClarity Cloud. At the outset, following domains need to be whitelisted.

1. For agent to communicate with the OpsClarity Cloud -

2. For downloading agent installer -


Thereafter, following command can be used to download the agent installer onto a given host.

http_proxy=http://<proxy-host>:<proxy-port> wget --user=<from-your-opsclarity-welcome-email> --password=<from-your-opsclarity-welcome-email> -N "" && bash ./ -k "<your-opsclarity-license-key>" 


Final step is to install the agent using the following command.

sudo bash ./ -k "<your-license-key" -q http://<proxy-host>:<proxy-port> -r http://<proxy-host>:<proxy-port>


Collecting host tags through configuration


The agent collects hosts tags available in a YAML-formatted "opsclarity.conf" file. The location of this config file can be either of the following:


3 special tags can be used to automatically split services on the Application Topology

1. opsclarity_region

2. opsclarity_env

3. opsclarity_split


Sample file

app: streaming-producer
purpose: api
opsclarity_region: sjc-datacenter
opsclarity_env: prod

If you have any questions or comments about this article, feel free to contact us at

2016.1.23 0.8.111

Have more questions? Submit a request


Please sign in to leave a comment.