Linux Monitoring Agent: How It Works

The agent is the trusted process on the monitored server. It reads local metrics, reports heartbeat data, detects common services, and receives signed maintenance tasks from the backend.

• CPU usage and load average.
• RAM usage.
• Disk and inode usage.
• SSL certificate expiry for discovered nginx and Apache domains.
• Uptime.
• Operating system and kernel information.
• Detected systemd service states.

A heartbeat tells the backend that the agent is still alive. If heartbeats stop, Telegram can show the server as offline or stale.

The agent reads systemd service states and reports detected services. Telegram buttons can be shown only for allowed and detected services.

The agent scans common nginx and Apache configuration paths for public domain names, connects to each domain on port 443 with SNI, reads the certificate expiry date and reports the number of days left. Telegram status cards show the certificate list and alerts fire when the minimum days left drops below the configured SSL threshold.

Thresholds are stored by the service and compared with incoming metrics. Alerts should fire when a value crosses a configured limit and resolve when the value returns below the limit.

The installer creates a systemd service and local agent configuration. The agent secret remains on the monitored server and is used for HTTPS authentication.

The agent makes outbound HTTPS requests to pair, send heartbeat and metrics, send service states, poll commands, and report command results.

• Restart allowed detected services.
• Clean old journal logs.
• Run logrotate through a controlled path.
• Reboot after explicit confirmation.
• Report command execution results back to Telegram.

A typical cycle has four parts: collect local metrics, send a heartbeat, report service state, and ask the backend whether any signed command is waiting. This polling model means the monitored server initiates communication instead of the backend opening a shell session.

Detected services are an operational hint, not a complete inventory system. A service may be absent because it is disabled, named differently on that distribution, hidden behind another supervisor, or not visible to the agent process. Always verify important services with systemd on the server itself.

The agent is intended to be lightweight. It should read standard Linux status sources, send compact HTTPS requests, and sleep between cycles. If you notice unusual CPU or memory usage from the agent, check logs and update or reinstall before adding more servers.

When the agent executes an allowed action, it should report the result back to the backend. Telegram can then show whether the action was accepted, completed, failed, or expired. This is important because a clicked button is not the same thing as a successful service restart.

• Server has no outbound HTTPS access.
• System time is wrong, causing short-lived commands or TLS checks to fail.
• The systemd service is stopped or disabled.
• The local configuration is missing or corrupted.
• The service name expected by the user is not detected by systemd.

Agent logs are the first place to look when Telegram shows stale data or an action fails. Read recent logs around the time of the problem and look for pairing errors, HTTPS failures, rejected commands, service permission errors or JSON parsing issues.

The agent should report operational state, not application secrets. It should not send environment files, database passwords, SSH keys, hosting panel credentials, email account passwords or arbitrary log contents to Telegram. Metric reporting should stay focused on server health.

When an update is needed, prefer a controlled reinstall with a fresh pairing token. Do it during a maintenance window for important servers, verify the service status after the update, and watch the next heartbeat. If the server is critical, keep a terminal open until Telegram confirms fresh metrics.

Keep the agent simple to operate: verify systemd status after updates, watch recent logs after a server migration, and reinstall with a fresh token when you need to rotate credentials. Do not edit generated secrets by hand unless you are intentionally repairing a broken installation.

• It should not expose arbitrary public shell execution.
• It does not need SSH passwords.
• It does not need hosting panel, database, FTP or cloud provider credentials.

Generate a fresh pairing token and reinstall when you need to rotate configuration. To uninstall, stop and disable the systemd service on a server you control. Read setup and troubleshooting before changing production machines.