Logs and diagnosis

Use the time of a failed action to locate relevant log entries. Start with the error in the RMON interface: an installation task, a failed channel test or a recorded check result. Review recent RMON messages on Overview, or read the full log on the host running the affected service.

Logs in the web interface

As an admin or superAdmin, open Overview → Recent RMON logs to reach the log viewer. A superAdmin can also open it from the RMON monitoring heading above the CPU and RAM charts. Editor and guest accounts do not have these log controls.

The viewer contains a Log selector, Number of rows (initially 10), Find, Exclude, a Time range control and a Show button. Select the relevant file, request enough rows to cover the failure, and use Find and Exclude to narrow the messages. Check the log timestamps when choosing the time range.

If Show returns 404 or fails to load the log, use the host or container commands below. A blank viewer does not establish that the log is empty. The file selector lists logs available to the RMON web service; for a receiver or agent on another host, read that service's logs on its host.

Choose the log

Scroll horizontally to view the full table.

RMON Server writes to console output by default (RMON_SERVER_LOG_PATH=-). If the administrator sets this variable to a file path, read that file instead. Use the configured paths for web and agent logs if they were changed. An empty file does not prove that no error occurred.

Read Docker service logs

On the RMON host, open a terminal in the existing deployment directory. Keep the same Compose project name and files used to start the installation:

docker compose ps --all
docker compose logs --since=15m --tail=200 web scheduler operations proxy

If this project also runs the result server:

docker compose logs --since=15m --tail=200 server

On the affected agent host:

sudo docker ps -a --filter name=rmon-agent
sudo docker logs --since=15m --tail=100 rmon-agent
sudo tail -n 100 /var/log/rmon/rmon-agent.log

The container log can show startup failures; the agent log contains its check and delivery messages. Use the active container name if it was customized. Historical rollback containers are not evidence of the active agent's state.

Read native service logs

For the native RMON application, scheduled tasks and agent operations:

sudo systemctl status rmon-web rmon-scheduler rmon-operations --no-pager
sudo journalctl -u rmon-web -u rmon-scheduler -u rmon-operations --since "15 minutes ago" --no-pager

For a native result receiver:

sudo systemctl status rmon-server --no-pager
sudo journalctl -u rmon-server --since "15 minutes ago" --no-pager

For web access failures, inspect apache2 on Ubuntu or httpd on Enterprise Linux with the same status/journal commands. Ask the host administrator to read protected logs when your account lacks access.

Match the error to the action

1. Record the check/agent name, active group and failure time with its time zone.
2. Read a short window around that time, including a few messages before the error.
3. Find the first useful cause, such as a refused connection, certificate mismatch or unreadable file.
4. Correct that cause using troubleshooting, then repeat the same operation once.
5. Confirm success in both the interface and fresh monitoring results.

Send a useful support report

Include the RMON and agent versions, affected action and location, timestamp, exact error, whether the issue affects one or all locations, and what changed before it began. Attach only the relevant log excerpt. Remove passwords, tokens, private keys, cookies and unrelated personal data before sending it.