Usage Graphs and the Activity Log

Two parts of the cloud portal answer the questions "what is my server doing?" and "who did what to it?": the usage graphs on a server's Overview, and the activity log. Both are worth a look before you open a ticket, because they usually point straight at the cause.

Usage graphs#

Open a server at cloud.nobullnetworks.com and the Overview tab shows live graphs measured from outside the guest, so they are accurate even when the operating system is misbehaving:

CPU

Utilisation of the vCPUs allocated to your plan. Sustained 100% means the workload is CPU-bound and a larger plan (or a VDS with dedicated cores) will help; a flat line at 100% you did not expect is a runaway process, or unwelcome company on the server.

Memory

RAM in use versus the plan's allocation. Linux uses spare RAM for cache, so "high" is normal; what matters is whether the guest starts swapping or the OOM killer starts firing (check dmesg and free -h inside).

Disk

Read and write throughput and, on current portal versions, how full the disk is. Steady heavy writes point at logging, backups, or a database that needs tuning.

Network

Inbound and outbound traffic. Unexplained sustained outbound is the classic sign of a compromised server or a public download that got popular; either way, see Bandwidth, Monthly Transfer, and Overage and Acceptable Use, Spam, and Abuse Reports.

Change the time range to zoom from the last hour out to longer periods, which is how you catch the nightly spike your cron job causes.

Reading the graphs with the guest#

The portal tells you that something is busy; the operating system tells you what. Pair them:

top -o %CPU          # or: htop
free -h
df -h && sudo du -xsh /var/log /var/lib/* 2>/dev/null | sort -h | tail
sudo ss -tunap | head -40   # who is talking on the network

The activity log#

The Activity tab on a server (and the account-wide activity view under your profile) records portal actions: power operations, reinstalls, rescue boots, snapshot and backup actions, password resets, network changes, and logins, each with a timestamp and the account that performed it. It is the first place to look when a server rebooted "by itself" or a setting changed and nobody owns up.

• Unexpected reboots: if the log shows no power action, the restart came from inside the guest (kernel panic, out-of-memory, an unattended-upgrade reboot) rather than from the portal. Check last -x reboot and journalctl -b -1 -e.
• Unexpected actions: if the log shows actions you did not take, change your cloud portal password, enable two-factor authentication, revoke any API tokens you do not recognise, and tell us.

Guest agent status#

The Overview also shows whether the guest agent inside the server is responding. Our templates ship with it installed; it is what lets the portal reset passwords and report accurate disk usage. If it shows as unavailable after you have replaced the operating system yourself, install qemu-guest-agent from your distribution's packages and enable the service.

Still puzzled?#

Include a screenshot of the relevant graph and the time window in your ticket. Graphs plus timestamps turn "it was slow yesterday" into something an engineer can act on in one reply.