What are server logs
We all want to find ways to improve the performance of our sites so that our end users have the best experience possible and continue to interact with our content.
But what are server logs, and how can they help to realize that goal?
What Server Logs Are
At the most basic level, server logs are records of events that happen on a site, on the server. These events could be anything which occurs in the day-to-day functioning of your site, but the two most common (and the ones that Flywheel keeps for you!) fall into two main categories:
- Access Logs
- Error Logs
As a general rule of thumb, all of these logs will be able to answer these two questions:
- When did this event happen?
- What happened during this event?
Yep. That’s pretty vague, and we’ll get into more concrete examples later on, but before we do that, you might be wondering why you should review the server logs.
Why Review Server Logs
It’s important to note that the information contained in server logs is similar but different than the information you can get from other analytics services like Google Analytics.
The two tools are answering different things, and I recommend making use of both!
A tool like Google Analytics goes to great lengths to distill information about the actual users that are interacting with your site. So if you are trying to ask a question like “How does a user travel through my site?” or “What’s the average viewing time of a user on the site?” you should turn to Google Analytics.
But if your questions are more along the lines of “Can the server physically handle the traffic that is going to it?” – then you should turn to your server logs.
6 best practices to create sustainable websites
The internet. The cloud. It’s easy to think of them as virtual concepts. After all, our connection to them is largely unseen. But the data we fire back and forth all day long is collected, processed...
Remember that these server logs are records of events happening on the site, and they can be analyzed to answer complicated questions.
I often will turn to a site’s server logs when I want answers to questions like:
- How many, and what kinds of requests are being made of the site?
- Are there specific plugins that are negatively impacting the performance of the site?
- Are there pages that are causing performance issues and contributing to bad user experience?
Being able to answer these questions will allow you to make informed decisions about where you apply development time, and how you spend money to improve the functioning of your site.
Obtaining Server Logs
Most hosting companies keep server logs for a little bit of time. Here at Flywheel, we keep three logs for seven days:
- Access Log
- PHP Error Log
- Slow Error Log
You can download these logs by selecting the “Export Logs” button from the “Advanced” tab of your Flywheel dashboard.
These logs contain information in plain text, so you can open them with any text editor to view them.
Reading a Log Entry
Ok great, but how do you read these logs, and aren’t they meant for developers?
4 tips to increase your WordPress site’s speed and performance
It is a proven fact that the slower your site loads, the more likely people are to leave. So if your page is taking forever to load, you’re losing both potential conversions and customers. Especiall...
Sure, if you’ve never seen a server log, then the walls of text can be intimidating and can elicit a desire knock-off for the rest of the day. But if you break them down, it’s like learning to read a new language – it’s arcane at first, but once you get used to the characters, then you can extract meaning!
Let’s start by taking a quick look at a standard log that most hosting companies can make available to you – the
Every time your site is accessed (for example, by an end user or a search engine bot), the server records a line in this log.
Here’s an example of something accessing the “Contact Us” page of a site. Note that it looks like it spans multiple lines, but in the actual log, the text is all on one line.
22.214.171.124 - - [22/Jan/2018:06:26:06 +0000] "GET /contact-us/ HTTP/1.1" 200 7687 "http://www.google.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36"
126.96.36.199– The IP address from where the request originated.
- -– In the early days of the internet, these dashes would have information about the user who made the request. Since these values are easily spoofed, you will rarely see servers fill in this information.
[22/Jan/2018:06:26:06 +0000]– The timestamp of the request along with the UTC offset. Since this timestamp has +0000, it has no offset and is using the UTC timezone.
"GET /contact-us/ HTTP/1.1"– This is the request for an actual page from the server. You can see what kind of a request (GET as opposed to a form submission like POST) as well as the page that was requested, and what version of HTTP was used.
200– This is the HTTP response code. A 200 means that everything about the request was good. Other common response codes are 404, which means that the page doesn’t exist, or 301, which is a redirect to another page.
7687– The size of the page returned as measured in bytes.
"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36"– The user agent string, which is another way of saying “what the browser says it is.” Note that this can also be spoofed, so take it with a grain of salt.
Ok, I know that’s a lot. The goal isn’t to understand all of this yet, and I know that reading one line in the
access.log doesn’t feel like it’s brought us any closer to answering our questions above.
In future posts, we’ll explore different ways of aggregating lines like this along with other information to answer more complex questions.
Enjoyed this post! Looking forward to the other parts. Coming soon?