Monitoring Script for Remote-Agent Host Health
This article provides a script that customers can use to collect system health metrics from the server running the Turbine remote-agent containers. The goal is to capture key data points (DNS resolution, CPU, memory, I/O, network performance, etc.) at regular intervals so that, in the event of a container restart or connectivity issue, system conditions at the time can be reviewed.
This is particularly useful in environments where connectivity to the Turbine Cloud instance may be impacted by DNS timeouts, network quality issues, or resource exhaustion.
This solution has been tested on commonly used Linux distributions, including:
- RHEL 7 / 8 / 9
- Ubuntu 18.04 / 20.04 / 22.04
What the script collects
- Running containers (docker ps)
- Container IPs
- Uptime
- Memory usage
- CPU load (top processes)
- Disk I/O (iostat)
- Disk usage
- DNS resolution
- Network response times using curl
Prerequisites
- Docker must be installed and running
- Optional but recommended: iostat via sysstat package Install the sysstat package:
Installation Steps
- Save the script below to /usr/local/bin/monitor_remote_agent_health.sh
- Paste the following content into the file. Be sure to replace <FQDN> with the appropriate Turbine Cloud domain (e.g. <region>.swimlane.app):
- Make the script executable:
- Add the following line (replacing <region>.swimlane.app with the correct Turbine Cloud region FQDN):
- Set up the script to run via crontab at a frequent interval of every 2 minutes:
Output location
- Logs will be saved to: /var/log/remote_agent_health.log
You can review this log when investigating container restarts or remote-agent connectivity issues.
Understanding and interpreting the output
[docker ps]
Shows all currently running containers with status and uptime.
- Useful for checking whether containers are restarting or unexpectedly stopped.
- If a container shows "Exited", note the timestamp for correlation.
[uptime]
Shows system uptime and average CPU load over 1, 5, and 15 minutes.
- Load values should generally be less than the number of CPU cores.
- Example: On a 4-core system, a 15-minute load of 3.5 is acceptable, but 8+ may indicate CPU contention.
[free -m]
Displays memory usage in megabytes.
- Available memory should ideally not drop too low.
- Watch for high used and low free without much in cached/buffer.
[top -bn1 -o %MEM | head -n 15]
Lists top memory-consuming processes.
- Helpful to identify any app or container unexpectedly consuming large amounts of RAM.
[disk I/O summary]
Shows simplified disk performance data using iostat.
Field | Meaning | Healthy Range |
|---|---|---|
r/s | Reads per second | Relative to workload |
w/s | Writes per second | Relative to workload |
r_await | Average wait time for reads (ms) | < 20ms is ideal, < 100ms ok |
w_await | Average wait time for writes (ms) | Same as above |
%util | How busy the disk was | < 80% preferred, 100% = bottleneck |
Focus especially on r_await, w_await, and %util for signs of disk delay or saturation.
[disk usage]
Shows available disk space.
- Ensure root (/) and /var partitions are not close to full.
- < 85% usage is generally safe.
[network speed test to $FQDN]
Breaks down how long it takes to connect to your Turbine Cloud endpoint.
- DNS Lookup: Time to resolve the hostname.
- Connect: Time to establish a TCP connection.
- TTFB: Time to first byte β indicates backend response time.
- Total: Full round-trip request duration.
Use this to track spikes in network or application latency.
[dns resolution to $FQDN]
Shows how long DNS took using dig.
- Ideally under 100ms.
- Longer resolution times may indicate local DNS resolver problems.