Site24x7's Linux server monitoring is agent-based: a monitoring agent runs on each server, gathers host data, and sends it to Site24x7. The setup is straightforward, but search results still surface obsolete Site24x7 "old client" pages with historical download URLs and navigation. This tutorial uses only the current Site24x7 help path.
The goal is to install one Linux agent safely, understand the root/non-root choice, protect the device key, confirm the agent registered, and verify that fresh CPU, memory, disk, process, and network data reach the correct monitor.
Last verified: September 10, 2026. Use current /help/admin/ documentation and the install command generated by your Site24x7 account. Do not substitute commands from /help-oldclient/ pages.
What You'll Accomplish
You will:
- open the current Linux monitor onboarding screen;
- choose whether to install/run the agent as root or non-root;
- install the agent with the account's device key;
- identify the documented agent/config paths;
- confirm the server appears in Site24x7;
- verify fresh metrics; and
- troubleshoot device-key, outbound network, permission, and duplicate-host problems.
Prerequisites
You need:
- a Site24x7 account with permission to add server monitors;
- a supported Linux distribution or a current supported custom-platform path;
- shell access to the server;
- root/sudo privileges if using the root installation path;
- outbound HTTPS access needed by the Site24x7 agent; and
- the Site24x7 device key shown in the current Add Linux Server Monitor screen.
Treat the device key as authorization material. Do not publish it in terminal screenshots, shell history examples, tickets, or repositories.
Quick Answer
In Site24x7, go to Server → Server Monitor → Servers (+) → Linux. The current page lets you choose root/non-root installation and provides a copyable install command. A current documented root installation starts by downloading https://staticdownloads.site24x7.com/server/Site24x7InstallScript.sh and runs it with -i -key=<device_key> -automation=true. Use the command generated for your account instead of copying an old-client command. After installation, confirm the monitor under Server → Server Monitor → Servers, then verify fresh host metrics. If the server does not appear, check the device key, outbound HTTPS/network controls, agent permissions, and logs before reinstalling.
Step 1: Open the Current Linux Onboarding Page
Use:
Server → Server Monitor → Servers (+) → Linux
The current Site24x7 help also documents an alternate route through Admin → Inventory → Add Monitor → Linux Server Monitoring.
This distinction matters because old indexed documentation may instruct you to download files from historical URLs. The current documentation uses staticdownloads.site24x7.com and a newer installation script.
Do not use /help-oldclient/ as an installation source.
Step 2: Decide Root vs Non-Root Operation
The current Linux onboarding page provides options to:
- install as root or non-root; and
- run the agent as root or non-root.
Root operation can expose more host information, but it also grants broader privileges. Non-root operation can reduce privilege but may limit access to some process/resource data.
Choose the least privilege that still supplies the telemetry your use case requires.
Site24x7's current security documentation says the Linux agent has two components, Site24x7Agent and Site24x7AgentWatchdog, and can run under root or non-root installation models.
Document the choice so operators know whether a "missing metric" is an agent failure or an expected permission limitation.
Step 3: Copy the Current Install Command from Site24x7
Site24x7's current help shows this generic pattern:
wget https://staticdownloads.site24x7.com/server/Site24x7InstallScript.sh
bash Site24x7InstallScript.sh -i -key=<device_key> -automation=true
Replace <device_key> only in your own secure terminal with the key displayed by your account.
Prefer the Copy to Clipboard command generated in the current Site24x7 UI because Site24x7 can update installer details.
Avoid leaking the device key
If you are documenting the process internally, keep the placeholder:
<device_key>
Do not include the real key in:
- Git repositories;
- CI logs;
- screenshots;
- wiki pages readable by unnecessary users; or
- public incident reports.
If a key is exposed, follow Site24x7's current key-rotation/account guidance rather than assuming deletion from a shell history fully removes exposure.
Step 4: Understand Where the Agent Is Installed
Current Site24x7 documentation lists:
Root installation:
/opt/site24x7/monagent
Non-root installation:
<home_dir_of_user>/site24x7/monagent
For root installation, the documented configuration path is:
/opt/site24x7/monagent/conf/monagent.cfg
Site24x7 states that configuration data including the device key and proxy details are encrypted in the agent configuration.
Do not manually edit encrypted credential fields unless current Site24x7 support documentation explicitly instructs you to.
Step 5: Verify the Agent Registered
After installation, the current help says the monitor should appear under:
Server → Server Monitor → Servers
Find the expected hostname/server.
Do not stop after seeing the monitor name. Confirm the latest collection time is current and host telemetry is arriving.
Check a few independent signals:
- CPU;
- memory;
- disk/filesystem;
- process information; and
- network metrics.
The exact dashboard arrangement can change, but fresh values from more than one metric family provide better evidence than a single status badge.
Step 6: Check the Agent's Data-Collection Context
Site24x7 documents that the Linux agent collects performance information using operating-system commands such as:
top;free;df;ps; and related platform commands.
That means agent permissions and the availability of standard tools can affect collection.
For custom distributions, Site24x7's current support article lists prerequisites such as Bash, wget/curl, Python with SSL, and system commands needed for metrics.
If the agent registers but some metrics remain empty, check permissions and command availability before assuming the network is broken.
Verify the Setup
A Linux server monitor is ready when:
- the current Site24x7 installer was used;
- the correct device key was supplied privately;
- the agent processes/service are running;
- the expected server appears in Server → Server Monitor → Servers;
- the latest collection timestamp is current;
- CPU, memory, disk and at least one other metric family contain plausible values; and
- the chosen root/non-root model explains the level of visibility.
The tutorial does not claim PerfMonitoring installed an agent on your server. These checks are the observable conditions you should validate in your own environment.
Common Problems and Fixes
Problem: The installation command fails to download
Cause: DNS, outbound HTTPS, proxy, TLS inspection, or egress policy blocks the download host.
Fix: verify DNS resolution and outbound HTTPS from the server. Use the proxy method documented by Site24x7 if your organization requires one. Do not download an old agent from an outdated search result as a shortcut.
Problem: The installer runs but no monitor appears
Cause: wrong device key, connectivity failure, installation failure, or registration delay.
Fix: confirm the device key came from the current account/workspace, inspect agent logs/current help troubleshooting, and verify outbound connectivity. Avoid repeatedly reinstalling until you know why registration failed.
Problem: Some process or system metrics are missing
Cause: non-root permissions or missing system commands.
Fix: compare the required telemetry with Site24x7's root/non-root documentation. Grant only the documented access required rather than running everything as root by default.
Problem: The same server appears twice
Cause: reinstall/hostname identity changes or a second registration.
Fix: inspect the current monitor identities before deleting either record. Preserve history if needed and follow Site24x7's current reinstall/duplicate-monitor guidance.
Problem: The agent stops reporting after a firewall change
Cause: outbound connectivity to Site24x7 is blocked.
Fix: correlate the last successful collection with firewall/proxy changes and restore only the documented network access. Do not open broad inbound access; agent monitoring is primarily an outbound reporting workflow.
Best Practices
Pilot one server first
Verify the exact installation, permissions, network path, tags, and expected metrics before bulk-deploying.
Use configuration management only after validation
Once one host works, automate the known-good setup with your existing fleet-management system.
Treat monitoring credentials as secrets
Device keys and proxy credentials belong in protected deployment configuration.
Keep the agent current
Site24x7 recommends running the latest agent for performance and fixes. Use your change process to test upgrades rather than pinning an old agent indefinitely.
Record root/non-root expectations
If security policy requires non-root operation, document which metrics are expected to differ so responders do not chase false "missing data" incidents.
When This Setup Makes Sense
Site24x7's agent is appropriate when you want host-level telemetry such as CPU, memory, disk, processes, and network behavior for a Linux server.
Use an external Website monitor instead when the primary question is whether users can reach a public HTTP(S) service. Host telemetry and external uptime answer different questions and are often complementary.
FAQ
Is the Site24x7 device key a secret?
Treat it as authorization material and keep it out of public source, screenshots, and shared logs. Use the placeholder form in documentation.
Can the Linux agent run without root?
Current Site24x7 documentation supports root and non-root installation/operation. Non-root mode can have different visibility depending on permissions and the metrics required.
Where is the Site24x7 Linux agent installed?
Current docs list /opt/site24x7/monagent for root installation and a site24x7/monagent directory under the installing user's home for non-root.
Why is the server not appearing?
Check the device key, installer completion, outbound network access, proxy/TLS requirements, agent process/logs, and whether the server registered under an unexpected identity.
Conclusion
Use the current Site24x7 Linux onboarding workflow, not old-client search results. Choose root/non-root deliberately, protect the device key, run the generated installer, then verify actual metrics—not just installation success.
Once host monitoring is stable, add external availability monitoring separately for the user-facing service. The sibling tutorial covers How to Monitor a Website and Configure Alerts in Site24x7.
References
- Site24x7 Online Help — "Add a Linux Monitor" — https://www.site24x7.com/help/admin/adding-a-monitor/linux-server-monitoring.html — accessed September 10, 2026.
- Site24x7 Online Help — "Server Metrics" — https://www.site24x7.com/help/server-metrics.html — accessed September 10, 2026.
- Site24x7 Online Help — "Server Monitoring Agent Security Documentation" — https://www.site24x7.com/help/admin/server-monitor/server-agent-documentation.html — accessed September 10, 2026.
- Site24x7 Support — "Open source Linux monitoring agent" — https://support.site24x7.com/portal/en/kb/articles/linux-monitoring-agent-custom-platform — accessed September 10, 2026.