Logs in Linux are stored in the slash var slash log directory. Remember that slash var directory stands for variable, meaning files that constantly change are kept in this directory. And it turns out that logs are constantly changing.
If we look at the slash var slash log directory with an ls, it might seem a little intimidating. Don't worry, each of these log files store specific information that we can figure out by their file names. Let's check out some of the common ones you'll look at. Slash var slash log slash auth dot log. Authorization and security related events are logged here.
Slash var slash log slash kern dot log. Kernel messages are logged here. Slash var slash log slash d message. System startup messages are logged here. If you encounter an issue at, let's say boot up, this is a good place to check for information.
It might get a little tiresome to open up each of these log files to find information about events. Luckily, there are also log files that combine the information of other log files. The downside is that these files are usually very large. If you have a pretty good idea of where a problem might lie, you might want to opt for the smaller and more specific log file. The one log file that logs pretty much everything on your system is the slash var slash log slash syslog file.
The only thing that syslog doesn't log by default are auth events. When troubleshooting issues with user machines, slash var slash log slash syslog will usually contain the most comprehensive information about your system. So that should be your first stop.
Log files output a lot of events. By that logic, they take up a lot of data that has to be stored on our machine somewhere. We generally just want to see the latest events on our system, so we don't need to overload our disk with all this information. Luckily, our systems also do a good job of cleaning out log files to make room for new ones. They use something called log rotation to do this.
In Linux, the utility to rotate logs is called log rotate. You might want to investigate an event that happened a month ago, so you can change your log rotation settings to make sure not to delete events that are that old. We've talked about logging in the context of a single machine, but if you find yourself managing many systems and want to be able to parse their logs in one central location, you can use something called centralized logging.
Okay, enough talk about what logs are. Let's actually look at some real ones. Well, this looks super intimidating, but don't worry. We're not going to be reading all of this. In the next lesson, we'll teach you how to troubleshoot using logs.
But for now, let's just read one line in syslog and parse what it says. The first field here is the timestamp when the event occurred. Pretty straightforward.
But depending on the log, you might see a time format you aren't familiar with, like a long string of numbers such as 1501538594. Timestamps found in a format like this are referred to as Unix or Epoch time. At first, you might be baffled by this. Why would you represent time in this way? And just what exactly is the Unix Epoch?
The Unix Epoch time is used to represent then. It's the number of seconds since midnight on January 1, 1970, a sort of zero hour for Unix-based computers to anchor their concept of time.