If you are seeing errors about the disk being not being sufficient, there are things you can do to debug and fix that.

First, let's confirm that you indeed are out of disk space. Via SSH connection (the terminal) issue the following command (df -h):

 1[otsmanager@host ~]# df -h
 2Filesystem      Size  Used Avail Use% Mounted on
 3tmpfs           383M  892K  382M   1% /run
 4/dev/sda1        38G  4.4G   32G  13% /
 5tmpfs           1.9G     0  1.9G   0% /dev/shm
 6tmpfs           5.0M     0  5.0M   0% /run/lock
 7/dev/sda15      253M  6.1M  246M   3% /boot/efi
 8tmpfs            32M   44K   32M   1% /var/lib/php/sessions
 9tmpfs           382M  8.0K  382M   1% /run/user/1000

You can see in the output that it shows the percentage of disk space used for every "partition" mounted. The last two columns are most useful: the percentage of space used and the mount point. You are primarily concerned with the first line where the mount point is /. If it is at 100%, you are out of disk space.

It is also possible that you are out of inodes. This situation will make you unable to create new files even though you still have disk space left. An inode is, simply speaking, a file or a directory. Therefore, there is certain maximum limit of files and directories you may have, usually it is high enough for any normal usage.

To confirm if you are running out of inodes, run df -i:

 1[otsmanager@host ~]# df -i
 2Filesystem      Inodes  IUsed   IFree IUse% Mounted on
 3tmpfs           488964    758  488206    1% /run
 4/dev/sda1      2427136 138875 2288261    6% /
 5tmpfs           488964      1  488963    1% /dev/shm
 6tmpfs           488964      4  488960    1% /run/lock
 7/dev/sda15           0      0       0     - /boot/efi
 8tmpfs           488964     14  488950    1% /var/lib/php/sessions
 9tmpfs            97792     29   97763    1% /run/user/1000

As you can see, the IUse% is low, it's usage is just 21%. However, certain cases - such as a lot of PHP session stored on the disk, could possibly exhaust this limit.

Excessive logs

What typically happens is that your log files are taking too much space. This typically doesn't happen because the system (and journald) are configured to only occupy certain disk space %. However, you can simply check how much space your logs are taking using du -hs /var/log:

 1[otsmanager@host ~]# sudo du -hs /var/log
 239M     /var/log

In this case logs take only 39 MB. If you find that they take too much, you can further look what subdirectory takes most disk space:

 1[otsmanager@host ~]# sudo du -hs /var/log/*
 216K     /var/log/alternatives.log
 3152K    /var/log/apt
 44.0K    /var/log/aptitude
 51.9M    /var/log/auth.log
 63.1M    /var/log/btmp
 7104K    /var/log/cloud-init.log
 888K     /var/log/cloud-init-output.log
 98.0K    /var/log/dbconfig-common
104.0K    /var/log/dist-upgrade
11312K    /var/log/dpkg.log
124.0K    /var/log/fsck
1333M     /var/log/journal
144.0K    /var/log/kern.log
1512K     /var/log/lastlog
168.0K    /var/log/mysql
17112K    /var/log/nginx
184.0K    /var/log/php7.0-fpm.log
198.0K    /var/log/syslog
20416K    /var/log/syslog.1
218.0K    /var/log/unattended-upgrades
228.0K    /var/log/wtmp

We see that /var/log/journal is taking most disk space. Although it is not recommended, you can remove your logs if you are out of disk space:

[otsmanager@host ~]# sudo rm -rf /var/log/journal/*

Watch out how you are typing the above command, you can potentially remove something important if you misspell it!