Moving anything in /var to a tmpfs is a bad idea at this point, because neither Ubuntu nor any other major Linux distribution support it at the moment. It also has the disadvantage to occupy main memory and to lose all previous log files, which hampers problem diagnosis. SSD drives really aren't that delicate when it comes to write cycles and a few log files don't result in enough data and write operations to reduce the life span of an SSD significantly. Very few SSDs fail because of write cycle exhaustion.
I suspect that /var/log/syslog still exists, but only on the root file system, because rsyslog starts before /var/log is mounted. When you mount another file system at /var/log, its previous content is hidden underneath.
As a workaround you can bind your root file system somewhere else, which would allow you to inspect its content unshadowed by other mountpoints:
sudo mkdir -p /mnt/root
sudo mount --bind / /mnt/root
You should now see other content in /mnt/root/var/log.
P.S.: If you have an internal hard disk drive in your machine in addition to an SSD, you can mount /var from there. That's what I and many other people do and not mainly because of concerns about write cycles. The main reason was always, that a faulty program may accidentally write heaps of (log) data to /var and nobody would notice until the file system was full, at which point it would be difficult to alleviate the situation, if /var was part of /.