Error log apache где находится

Для эффективного управления веб-сервером необходимо получить обратную связь об активности и производительности сервера, а также о всех проблемах, которые могли случиться. Apache HTTP Server обеспечивает очень полную и гибкую возможность ведения журнала. В этой статье мы разберём, как настроить логи Apache и как понимать, что они содержат.

HTTP-сервер Apache предоставляет множество различных механизмов для регистрации всего, что происходит на вашем сервере, от первоначального запроса до процесса сопоставления URL-адресов, до окончательного разрешения соединения, включая любые ошибки, которые могли возникнуть в процессе. В дополнение к этому сторонние модули могут предоставлять возможности ведения журналов или вставлять записи в существующие файлы журналов, а приложения, такие как программы CGI, сценарии PHP или другие обработчики, могут отправлять сообщения в журнал ошибок сервера.

В этой статье мы рассмотрим модули журналирования, которые являются стандартной частью http сервера.

Логи Apache в Windows

В Windows имеются особенности настройки имени файла журнала — точнее говоря, пути до файла журнала. Если имена файлов указываются с начальной буквы диска, например «C:/«, то сервер будет использовать явно указанный путь. Если имена файлов НЕ начинаются с буквы диска, то к указанному значению добавляется значение ServerRoot — то есть «logs/access.log» с ServerRoot установленной на «c:/Server/bin/Apache24″, будет интерпретироваться как «c:/Server/bin/Apache24/logs/access.log«, в то время как «c:/logs/access.log» будет интерпретироваться как «c:/logs/access.log«.

Также особенностью указания пути до логов в Windows является то, что нужно использовать слэши, а не обратные слэши, то есть «c:/apache» вместо «c:apache«. Если пропущена буква диска, то по умолчанию будет использоваться диск, на котором размещён httpd.exe. Рекомендуется явно указывать букву диска при абсолютных путях, чтобы избежать недоразумений.

Apache error: ошибки сервера и сайтов

Путь до файла журнала с ошибками указывается с помощью ErrorLog, например, для сохранения ошибок в папке «logs/error.log» относительно корневой папки веб-сервера:

ErrorLog "logs/error.log"

Если не указать директиву ErrorLog внутри контейнера <VirtualHost>, сообщения об ошибках, относящиеся к этому виртуальному хосту, будут записаны в этот общий файл. Если в контейнере <VirtualHost> вы указали путь до файла журнала с ошибками, то сообщения об ошибках этого хоста будут записываться там, а не в этот файл.

С помощью директивы LogLevel можно установить уровень важности сообщений, которые должны попадать в журнал ошибок. Доступные варианты:

• debug
• info
• notice
• warn
• error
• crit
• alert
• emerg

Журнал ошибок сервера, имя и местоположение которого задаётся директивой ErrorLog, является наиболее важным файлом журнала. Это место, куда Apache httpd будет отправлять диагностическую информацию и записывать любые ошибки, с которыми он сталкивается при обработке запросов. Это первое место, где нужно посмотреть, когда возникает проблема с запуском сервера или работой сервера, поскольку он часто содержит подробности о том, что пошло не так и как это исправить.

Журнал ошибок обычно записывается в файл (обычно это error_log в системах Unix и error.log в Windows и OS/2). В системах Unix также возможно, чтобы сервер отправлял ошибки в системный журнал или передавал их программе.

Формат журнала ошибок определяется директивой ErrorLogFormat, с помощью которой вы можете настроить, какие значения записываются в журнал. По умолчанию задан формат, если вы его не указали. Типичное сообщение журнала следующее:

[Fri Sep 09 10:42:29.902022 2011] [core:error] [pid 35708:tid 4328636416] [client 72.15.99.187] File does not exist: /usr/local/apache2/htdocs/favicon.ico

Первый элемент в записи журнала — это дата и время сообщения. Следующим является модуль, создающий сообщение (в данном случае ядро) и уровень серьёзности этого сообщения. За этим следует идентификатор процесса и, если необходимо, идентификатор потока процесса, в котором возникло условие. Далее у нас есть адрес клиента, который сделал запрос. И, наконец, подробное сообщение об ошибке, которое в этом случае указывает на запрос о несуществующем файле.

В журнале ошибок может появиться очень большое количество различных сообщений. Большинство выглядит похожим на пример выше. Журнал ошибок также будет содержать отладочную информацию из сценариев CGI. Любая информация, записанная в stderr (стандартный вывод ошибок) сценарием CGI, будет скопирована непосредственно в журнал ошибок.

Если поместить токен %L в журнал ошибок и журнал доступа, будет создан идентификатор записи журнала, с которым вы можете сопоставить запись в журнале ошибок с записью в журнале доступа. Если загружен mod_unique_id, его уникальный идентификатор запроса также будет использоваться в качестве идентификатора записи журнала.

Во время тестирования часто бывает полезно постоянно отслеживать журнал ошибок на наличие проблем. В системах Unix вы можете сделать это, используя:

tail -f error_log

Apache access: логи доступа к серверу

Журнал доступа к серверу записывает все запросы, обработанные сервером. Расположение и содержимое журнала доступа контролируются директивой CustomLog. Директива LogFormat может быть использована для упрощения выбора содержимого журналов. В этом разделе описывается, как настроить сервер для записи информации в журнал доступа.

Различные версии Apache httpd использовали разные модули и директивы для управления журналом доступа, включая mod_log_referer, mod_log_agent и директиву TransferLog. Директива CustomLog теперь включает в себя функциональность всех старых директив.

Формат журнала доступа легко настраивается. Формат указывается с использованием строки формата, которая очень похожа на строку формата printf в стиле C. Некоторые примеры представлены в следующих разделах. Полный список возможного содержимого строки формата смотрите здесь: https://httpd.apache.org/docs/current/mod/mod_log_config.html

Общий формат журнала (Common Log)

Типичная конфигурация для журнала доступа может выглядеть следующим образом.

LogFormat "%h %l %u %t "%r" %>s %b" common
CustomLog logs/access_log common

В первой строке задано имя (псевдоним) common, которому присвоено в качестве значения строка «%h %l %u %t «%r» %>s %b«.

Строка формата состоит из директив, начинающихся с символа процента, каждая из которых указывает серверу регистрировать определённый фрагмент информации. Литеральные (буквальные) символы также могут быть помещены в строку формата и будут скопированы непосредственно в вывод журнала. Символ кавычки («) должен быть экранирован путём размещения обратной косой черты перед ним, чтобы он не интерпретировался как конец строки формата. Строка формата также может содержать специальные управляющие символы «n«для новой строки и «t» для обозначения таба (табуляции).

В данной строке значение директив следующее:

• %h — имя удалённого хоста. Будет записан IP адрес, если HostnameLookups установлен на Off, что является значением по умолчанию.
• %l — длинное имя удалённого хоста (от identd, если предоставит). Это вернёт прочерк если не присутствует mod_ident и IdentityCheck не установлен на On.
• %u — удалённый пользователь, если запрос был сделан аутентифицированным пользователем. Может быть фальшивым, если возвращён статус (%s) 401 (unauthorized).
• %t — время получения запроса в формате [18/Sep/2011:19:18:28 -0400]. Последнее показывает сдвиг временной зоны от GMT
• «%r» — первая строка запроса, помещённая в буквальные кавычки
• %>s — финальный статус. Если бы было обозначение %s, то означало бы просто статус — для запросов, которые были внутренне перенаправлены это обозначало бы исходный статус.
• %b — размер ответа в байтах, исключая HTTP заголовки. В формате CLF, то есть ‘—‘ вместо 0, когда байты не отправлены.

Директива CustomLog устанавливает новый файл журнала, используя определённый псевдоним. Имя файла для журнала доступа относительно ServerRoot, если оно не начинается с косой черты (буквы диска).

Приведённая выше конфигурация будет сохранять записи журнала в формате, известном как Common Log Format (CLF). Этот стандартный формат может создаваться многими различными веб-серверами и считываться многими программами анализа журналов. Записи файла журнала, созданные в CLF, будут выглядеть примерно так:

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

Каждая часть этой записи журнала описана ниже.

127.0.0.1 (%h)

Это IP-адрес клиента (удалённого хоста), который сделал запрос к серверу. Если для HostnameLookups установлено значение On, сервер попытается определить имя хоста и зарегистрировать его вместо IP-адреса. Однако такая конфигурация не рекомендуется, поскольку она может значительно замедлить работу сервера. Вместо этого лучше всего использовать постпроцессор журнала, такой как logresolve, для определения имён хостов. Указанный здесь IP-адрес не обязательно является адресом машины, на которой сидит пользователь. Если между пользователем и сервером существует прокси-сервер, этот адрес будет адресом прокси, а не исходной машины.

— (%l)

«Дефис» в выходных данных указывает на то, что запрошенная часть информации недоступна. В этом случае информация, которая недоступна, является идентификационной информацией клиента RFC 1413, определённой с помощью id на клиентском компьютере. Эта информация крайне ненадёжна и почти никогда не должна использоваться, кроме как в жёстко контролируемых внутренних сетях. Apache httpd даже не будет пытаться определить эту информацию, если для IdentityCheck не установлено значение On.

frank (%u)

Это идентификатор пользователя, запрашивающего документ, как определено HTTP-аутентификацией. Такое же значение обычно предоставляется сценариям CGI в переменной среды REMOTE_USER. Если код состояния для запроса равен 401, то этому значению не следует доверять, поскольку пользователь ещё не аутентифицирован. Если документ не защищён паролем, эта часть будет «—«, как и предыдущая.

[10/Oct/2000:13:55:36 -0700] (%t)

Время получения запроса. Формат такой:

[день/месяц/год:час:минута:секунда зона]

день = 2*цифры

месяц = 3*цифры

год = 4*цифры

час = 2*цифры

минута = 2*цифры

секунда = 2*цифры

зона = (`+’ | `-‘) 4*цифры

Можно отобразить время в другом формате, указав %{format}t в строке формата журнала, где формат такой же, как в strftime(3) из стандартной библиотеки C, или один из поддерживаемых специальных токенов. Подробности смотрите в строках формате строки mod_log_config.

«GET /apache_pb.gif HTTP/1.0» («%r»)

Строка запроса от клиента указана в двойных кавычках. Строка запроса содержит много полезной информации. Во-первых, клиент использует метод GET. Во-вторых, клиент запросил ресурс /apache_pb.gif, и в-третьих, клиент использовал протокол HTTP/1.0. Также возможно зарегистрировать одну или несколько частей строки запроса независимо. Например, строка формата «%m %U%q %H» будет регистрировать метод, путь, строку запроса и протокол, что приведёт к тому же результату, что и «%r«.

200 (%>s)

Это код состояния, который сервер отправляет обратно клиенту. Эта информация очень ценна, потому что она показывает, привёл ли запрос к успешному ответу (коды начинаются с 2), к перенаправлению (коды начинаются с 3), к ошибке, вызванной клиентом (коды начинаются с 4), или к ошибкам в сервер (коды начинаются с 5). Полный список возможных кодов состояния можно найти в спецификации HTTP (RFC2616 раздел 10).

2326 (%b)

Последняя часть указывает размер объекта, возвращаемого клиенту, не включая заголовки ответа. Если контент не был возвращён клиенту, это значение будет «—«. Чтобы записать «0» без содержимого, вместо %b используйте %B.

Логи комбинированного формата (Combined Log)

Другая часто используемая строка формата называется Combined Log Format. Может использоваться следующим образом.

LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-agent}i"" combined
CustomLog log/access_log combined

Этот формат точно такой же, как Common Log Format, с добавлением ещё двух полей. Каждое из дополнительных полей использует директиву начинающуюся с символа процента %{заголовок}i, где заголовок может быть любым заголовком HTTP-запроса. Журнал доступа в этом формате будет выглядеть так:

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (Win98; I ;Nav)"

Дополнительными полями являются:

«http://www.example.com/start.html» («%{Referer}i»)

Referer — это часть заголовок HTTP-запроса, которая называется также Referer. В этой строке содержится информация о странице, с которой клиент был прислан на данный сайт. (Это должна быть страница, которая ссылается или включает /apache_pb.gif).

«Mozilla/4.08 [en] (Win98; I ;Nav)» («%{User-agent}i»)

Заголовок HTTP-запроса User-Agent. Это идентифицирующая информация, которую клиентский браузер сообщает о себе.

По умолчанию в главном конфигурационном файле Apache прописаны следующие настройки логов:

<IfModule log_config_module>
    LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combined
    LogFormat "%h %l %u %t "%r" %>s %b" common

    <IfModule logio_module>
      LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i" %I %O" combinedio
    </IfModule>

    CustomLog "logs/access.log" common   
</IfModule> 

Как можно увидеть, установлены три псевдонима: combined, common и combinedio. При этом по умолчанию используется common. При желании вы без труда сможете переключиться на combined или настроить формат строки лога под свой вкус.

Например, если вы предпочитаете, чтобы в файле лога доступа также присутствовала информация о пользовательском агенте и реферере, то есть Combined Logfile Format, то вы можете использовать следующую директиву:

CustomLog "logs/access.log" combined

Today features another post about the nuts and bolts of logging.  This time, I’ll be talking about the Apache error log in some detail.

Originally, I had a different plan and outline for this post.  But then I started googling for good reference material.

And what I found were way more questions than answers about the topic, many on various Stack Exchange sites.  It seems that information about the Apache error log is so scarce that people can’t agree on where to ask questions, let alone get answers to them.

So let’s change that.  I’m going to phrase this as a Q&A-based outline, hopefully answering all of the questions you might have come looking for—if you googled the term—while also providing a broad narrative for regular readers.

First of All, What Is the Apache Error Log?

First things first.  What exactly is this thing we’re talking about here?  To understand that, you first need to understand what Apache is.  Apache is a web server, in the software sense of the term.  As briefly as possible, this means that it’s the application in which you put your website’s files, and it manages inbound HTTP requests.

Now as you might imagine, something that manages the websites you build is a fairly involved and fairly important piece of software.  And, as such, it produces a lot of log data.

Apache’s error log is part of that log data that it produces.  It’s a standalone file that specifically contains information about errors produced as the Apache web server starts up and runs. 

According to Apache’s section on the subject, it is “the most important log file.”

Is the Apache Error Log a Different Thing from the Apache Access Log?

So there you have it.  The Apache error log is a log file (and the most important log file) of Apache’s runtime errors.

The next thing people seem to wonder about a lot has to do with differentiating between the access log and the error log.  Are these two different things?  Or is it just kind of two names for the same thing?

They’re two different, distinct things.  The error log is not the same thing as the access log.

For those who follow the blog, you may recall that I’ve posted in detail about the Apache access log.  The access log keeps track of all of the requests that come into the web server and who has sent them.  You can think of it as the really geeky equivalent of an event guest log.  It keeps track of things like IP addresses of visitors, the URL requested, the response, etc.

Now, while the access log may have information related to problems that happen, the error log—the subject of our focus today—is specifically dedicated to logging errors and problems that occur with the running of the server.  You can mine the access log for general information about web requests but look in the error log for, well, errors.

Where Do You Find the Apache Error Log?

The question about where you find the error log seems to cause absolutely the most confusion.  The reason there’s so much confusion?  Well, there are actually several contributing factors:

• Apache is a cross-platform web server that will run on just about any OS you might use.  Just figuring out which version to download will confuse you, let alone finding some log file it produces.
• Most Apache installations occur on Unix and Linux system, which have even further fragmentation as to where you might find things.
• Apache is extremely configurable.  And while that makes it extremely flexible and powerful, it also makes things even harder to find, since you can put them anywhere.

What does all of this add up to?  Well, when you type “where is the Apache error log” into Google, Google could save you a lot of clicking and bouncing by just popping up a message saying, “No one actually knows where yours is.”

All is not lost, though.

You could google your operating system to see where it tends to keep log files or where default Apache log files generally go.  Understand that you’ll have to search by your specific operating system. On *nix systems, a typical location for the log files would be under the ‘/var/log’ directory.

But what I’d do instead is actually figure out where your Apache config files are.  Once you’ve got that, you can find the location of the error log (and other logs) because they’re configurable Apache settings.

For instance, this is a typical example of the log’s location configuration:

ErrorLog "/var/log/apache2/error.log"

By the way, you’re not forced to use “error.log” as the file name. Instead, any valid name you inform will do. If the name informed refers to an existent file, new log entries will be appended to it.

How Do You Check the Apache Error Log?

Once you’ve found it, how do you go about actually checking it?  Well, to understand that, understand what it is.

The Apache error log is a text file.  So you can open it with any text editor or with a command line utility like tail or cat.  Those will give you a quick peek at the contents and let you scroll through to find what you’re looking for.  The file’s entries will be in chronological order.

Suppose you want to use the “tail” utility. How would you go about that in practice? Easy. First, you open a shell session. You then type the following command:

tail ?f /path-to/log

After running the command above you’ll see the file’s last few entries. You’ll also continue seeing new entries, as they occur.

Now, hopefully, your log file is small since it contains errors.  But it might be big—too big to search easily.  In that case, you might want to search the error log’s contents using grep and regex.  Or you might consider employing a log aggregator to parse and turn the contents into data that you can query easily.

What Are the Apache Error Log Levels?

Since the Apache error log is a log file, not that different in concept from any other log file, it doesn’t come as a surprise that it also makes use of logging levels.

If you aren’t familiar with the concept of logging levels, we invite you to read the post we’ve published about it.

In a nutshell, logging levels are labels that can be applied to log entries. Then can then be used to filter the messages sent to the log file, effectively adjusting the verbosity in each message.

You can specify the desired level using the LogLevel directive, like in the following example:

LogLevel warn

The default level is indeed “warn”, but there are many other levels available:

Level, emerg , alert , crit , error , warn , notice, info , debug , trace1, trace2, trace3, trace4, trace5, trace6, trace7, trace8

You can head to Apache’s documentation if you want to learn about each level in detail.

Let’s talk try to compare the two logging levels here. We will compare warning and debug log levels. Warning, you only receive warning logs when the system is working as expected but something doesn’t seem right. If these warnings are not attended to on time, they might bring some real errors as time go on. On the other hand, debug log level logs almost everything that is happening on the server. It can be errors and just any other important message that can be helpful to you as a website administrator.

You can enable debug log level writing the flowing command in the main configuration file.

LogLevel alert rewrite:trace6

How to Use Grep to Get Information from the Apache Error Log?

As we’ve just mentioned, it’s possible to use the grep command to search the contents of your Apache error log file. So, let’s see some quick examples of how that can be done.

Suppose you want to filter your log entries with the warn level. This is the command you should run, based on the example location for an Apache error log mentioned a few sections back:

grep warn /var/log/apache2/error.log

Similarly, if you wanted to retrieve log entries marked with the notice level, you’d just have to replace warn with notice in the command above. Easy peasy.

Keep in mind, though, that Apache logs—the error log included—tend to be extremely long. Let’s say you only wanted to output the last 15 lines of your log. You can use the command tail to accomplish that.

Tail is a command that outputs the tail—that is, the end—of a file. By default, it outputs the last 10 lines. You can specify the number of lines using the -n option:

tail -n 5 /var/log/apache2/error.log

You can use tail along with grep in order to get a subset of log entries, then filter them. That’s what we do in the following example: we get five lines from the log file, then feed them to the grep command, which filters for entries containing “warn.’

tail -n 5 /var/log/apache2/error.log | grep warn

Now, suppose you want to do negative filtering. You want to see all log entries except those with the warn level. Can you do it using the grep command? You bet you can! You’d only have to add the -v option to the grep command:

grep -v warn /var/log/apache2/error.log

How You Should View the Apache Error Log—The ErrorLogFormat Directive

That covers how you can get at the file’s contents in the broadest sense.  But how do you actually view and interpret the thing, semantically?  What does each entry actually mean?

Well, let’s consider an example, taken from this page.  This is representative of what an error log file entry could look like:

#Simple example
ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client %a] %M"

#And the output:

[Fri Dec 16 01:46:23 2005] [error] [client 1.2.3.4] Directory index forbidden by rule: /home/test/
[Fri Dec 16 01:54:34 2005] [error] [client 1.2.3.4] Directory index forbidden by rule: /apache/web-data/test2
[Fri Dec 16 02:25:55 2005] [error] [client 1.2.3.4] Client sent malformed Host header
[Mon Dec 19 23:02:01 2005] [error] [client 1.2.3.4] user test: authentication failure for "/~dcid/test1": Password Mismatch

You can probably infer the format here of each entry: timestamp, log level, remote host, error message.

Unlike the access log that I mentioned earlier, you don’t have endless customization options here.  The format of this particular file is actually fixed.  But entries in this file will also correspond to entries in the access log, which you can configure. 

You can also create custom log files of your choosing.

Managed Dedicated Servers

If you are using a managed dedicated server, there are a number of directories where you can find the Apache error logs. On cPanel server, you can find the apache access_logs in the following directory.

/usr/local/apache/logs/access_log

Now  the access_log is where all the http requests are logged to.

Apache errors can be found in this directory /usr/local/apache/logs/error_log. All the Apache errors are logged in the error_log.

Another important folder you can look for is the demolog folder. Demologs are logs of domains, they are generated from the requests made to the domain. The directory can look like the following

/usr/local/apache/domlogs

Unmanaged Dedicated Servers

Like the name suggests, this is a type of server that is not managed by the hosting company and having that said, you have full control of this server and can decide where the Apache server can be writing the logs. The directories and folders will be up to your tech team.

How Do You Clear the Apache Error Log?

I’ll bookend this post by answering a question that seems logical to wrap up.  We’ve looked at what the error log is, where you find it, how you view it, and how you interpret it.  How do you clear it?  And why would you want to?

Well, let’s answer that second question first. 

Simply put, over the course of a lot of time, that log file is going to get pretty unwieldy.  And at some point, you’re not going to need error messages from two years ago anymore.  So you want to clear it out to clean up some disk space, either truncating it outright or backing up a copy somewhere else.

As for clearing the logs themselves, there’s an interesting issue to contend with there.  As long as the server is running, it holds a handle to the file for writing.  So you can’t just open it and start editing it, and you can’t just back it up and delete it.

Perhaps the simplest technique is to have root access and do something like this—overwriting the file contents with nothing.  I’d suggest making a copy of the file first, though.

Alternatively, you can follow the instructions here, on Apache’s site, related to log rotation and piped logs.  These are more involved but more “proper” and less hack-y solutions. 

But however you approach clearing the logs or logging in general, my recommendation would be always to err on the side of preserving as much information as you possibly can.

Apache Error Log: No Longer a Stranger

Today’s post was another installment of our series that covers different aspects of logging. Thematically, this post doesn’t differ dramatically from the previous ones. After all, it covers the Apache error log, which is a special kind of log file. Structurally, though, this post was a novelty, since we’ve adopted a Q&A format for it.

Throughout the post, we’ve walked you through a list of common questions about the Apache error log. You’ve learned, among other things:

• what the Apache error log is
• where can you find it
• how to check the log
• the best way to visualize the log’s content

By now, you should have a solid grasp of the Apache error log fundamentals.

Hopefully, you can apply the knowledge you’ve obtained from this post to troubleshoot issues quickly, accessing the precious data contained on your apache log files and turning them into valuable insights for your organization.

Learn more about Scalyr by checking out a demo here.

Apache has been around since 1995 and is the most important web technology. The majority of businesses nowadays run-on Apache servers. Different servers operate in different ways and have different features and functions. For simple debugging, several servers keep server logs. Understanding how the server works is essential.

All errors encountered by the server while receiving or processing requests are recorded in the Apache error logs. These logs are accessible to admin users, who can troubleshoot them for immediate solutions.

These logs will provide you with useful information about the traffic to your application, errors that occur, and performance. This article will cover Apache web server logs, including log levels, format, and formatting as JSON.

We will cover the following:

1. What are Apache Logs?
2. What is the Apache Error Log?
3. Apache Error Log vs Apache Access Log
4. Where Do You Find the Apache Error Log?
5. How Do You Check the Apache Error Log?
6. Configuring Apache Logs
7. Apache Error Log Levels
8. Apache Error Log Format
9. Apache Request Tracking
10. Managed Dedicated Servers
11. Unmanaged Dedicated Servers
12. Assigning Nicknames
13. Formatting as JSON
14. How Do You Clear the Apache Error Log?

What are Apache Logs?

The Apache server keeps a record of all server actions in a text file known as Apache logs. These logs provide useful information about what resources are used and released. Additionally, the logs contain information about who visited those resources and for how long and all related data.

Not only that, but you’ll get all of the details on all of the errors that occurred. The admins can use these logged errors to look into fixing the errors and determining the root cause to eliminate the possibility of the error occurring again.

There isn’t a single Apache logging process. It involves several steps, including saving the logs in a specified area for future reference, analyzing and parsing the logs to extract the relevant information, and producing the graph for a better visual representation. There isn’t a single log type that Apache keeps track of. However, we’ll be concentrating on Apache error logs.

Types of Apache Log

There are two types of logs produced by Apache: Access logs and Error logs.

1. Access Log
   The access log keeps track of the requests that come into the webserver. This data could include what pages visitors are looking at, the status of requests, and how long it took the server to respond.
2. Error Log
   The error log records any errors encountered by the web server when processing requests, such as missing files. It also contains server-specific diagnostic information.

What is the Apache Error Log?

If you can’t figure out what’s wrong with your server and it keeps throwing errors, it will become unreliable. We must keep information about the errors affecting the server’s performance for easy and seamless server operation.

As a result, Apache keeps error logs in a specific location. For simple troubleshooting, the server administrator sets up these log files and other details such as file size, error time, type of error, error message, and so on.

The Apache log keeps track of events handled by the Apache web server, such as requests from other computers, Apache responses, and internal Apache server operations.

These logs will continue to be created and stored at that location, making them accessible in the future. You must understand where these errors are saved, how to access them, and how to use the information they provide.

Apache Error Log vs. Apache Access Log

The next thing that people appear to be confused about is the difference between the access log and the error log. Are these two different concepts? Or do they refer to the same thing under different names?

They’re two very different things. The access log is not the same as the error log.

The access log keeps an account of all requests made to the web server, as well as who made them. You can think of it as a geekier version of an event guest log. It keeps track of information like visitor IP addresses, URL requests, responses, and so on.

While the access log may contain information about difficulties that arise, the error log—the subject of our discussion today—is dedicated to logging errors and problems that occur during the server’s operation. You can search for general information about web requests in the access log, but errors should be found in the error log.

Where do you find the Apache Error Log?

Several factors have a role in this:

• Apache is a cross-platform web server that can run on nearly any operating system. It’ll be difficult enough to figure out which version to download, let alone locate any log files it generates.
• The majority of Apache installations take place on Unix and Linux systems, which are even more fragmented in terms of where you can find stuff.
• Apache is highly customizable. While this gives it a lot of flexibility and power, it also makes items more difficult to find because you can put them everywhere.

So, what does it all add up to?

When you Google «where is the Apache error log,» Google could simply pop up a message saying, «No one knows where yours is.» This would save you a lot of clicking and bounce.

However, everything is not lost.

You could look up your operating system’s log file location or the default Apache log file location using Google. Keep in mind that you’ll have to search for your operating system. The ‘/var/log‘ directory is a common destination for log files on *nix systems.

Instead, we did investigate the location of your Apache configuration files. Because these are configurable Apache settings, you can identify the location of the error log (and other logs) once you have that.

For instance, consider the following example of log location configuration:

Update the below log path and log levels in the default configuration file — /etc/apache2/apache2.conf.

ErrorLog "/var/log/apache2/error.log"

By the way, you’re not obligated to name the file «error.log.» Instead, any legal name you provide would suffice. If the specified file already exists, additional log entries will be appended to it.

You can also use a Syslog server to send log messages. Use the Syslog directive instead of a filename.

ErrorLog syslog

There are numerous options for the logging facility and the application name in the Syslog option. Details can be found here.

Finally, you can use a Linux command to redirect logs.

ErrorLog "|/usr/local/bin/httpd_errors"

The pipe character tells Apache that the messages should be piped to the specified command.

Access logs for apache can be found in the following directory on the cPanel server.

/usr/local/apache/logs/access_log

How do you check the Apache Error Log?

How do you go about really checking it once you’ve located it?

You must first understand what it is to understand how it is.

A text file contains the Apache error log. So you can use any text editor or a command-line application like Cat or Tail to open it. These will offer you a quick preview of the contents and allow you to navigate through to find what you need. The entries in the file will be in reverse chronological order.

Let’s say you wish to utilize the «tail» command. In practice, how would you go about doing that?

Easy. To begin, start a shell session.

After that, you type the command:

tail -f /path-to/log

You’ll see the file’s last few entries after running the command above. You’ll also see new entries as they become available.

Since your log file contains errors, it should now be small. However, it could be large—too large to search quickly. In that situation, you might wish to use grep and regex to scan the contents of the error log. Alternatively, you may use a log aggregator to parse and turn the contents into data that you can readily query.

Configuring Apache Logs

The logging framework in Apache is highly flexible, allowing you to change logging behavior globally or for each virtual host. To adjust logging behavior, you can use several directives. The log level and log format directives are two of the most popular directives.

Apache Error Log Levels

It’s no surprise that the Apache error log, like any other log file, uses logging levels.

If you’re unfamiliar with the concept of logging levels, we recommend reading our post on the log levels.

In short, logging levels are labels that can be applied to log entries. The messages transmitted to the log file can then be filtered, thereby changing the verbosity of each message.

The LogLevel directive can be used to specify the desired level, as shown in the following example:

LogLevel warn

The default level is «warn,» although there are a variety of alternative options.

The levels are described as follows in the Apache documentation:

If you want to understand more about each level in-depth, go to Apache’s documentation.

Let’s look at how the two logging levels compare. We’ll compare the levels of warning and debug logs.

1. Warning: You will only receive warning logs if the system is functioning normally but something does not appear to be correct. If these warnings are not addressed promptly, they may result in serious problems over time.
2. Debug log level, on the other hand, logs practically everything that happens on the server. It might be errors or any other essential notification that you as a website administrator could find useful.

The following command in the main configuration file can be used to enable debug log level.

LogLevel alert rewrite:trace6

Apache Error Log Format

You can also modify the format of log messages. We have been using the default format thus far. The ErrorLogFormat setting controls the message composition.

Let’s try a different setting to see what happens. We are going to utilize this example from the Apache documentation.

ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client %a] %M"

This is how a request appears right now:

[Thu Jun 09 11:46:18 2022] [fuga:error] [pid 6157:tid 4946] [client 144.110.67.126:20151] You can't copy the port without navigating the haptic SMTP card!
[Thu Jun 09 11:46:18 2022] [pariatur:info] [pid 5946:tid 7137] [client 35.8.11.82:2909] We need to transmit the primary SQL interface!

Let’s go over how to use this format. The format string contains parameters that correspond to fields in a logging event.

The fields we used above are as follows:

For new connections and requests, you can define alternative formats. When a new client connects to the server, it is called a connection. A request is a communication that asks for something, such as a page or an image.

Apache uses connection and request formats when a new client connects or makes a web request. It records a message indicating that a client has established a connection or made a new request.

Apache Request Tracking

You can go a step further with logging messages for new connections and requests. Every new request or connection will generate a unique identifier in the Apache error log. This parameter can be used to group log entries. For identifiers, use the %L field.

Assigning Nicknames

You can give LogFormat strings nicknames, which you can use with the CustomLog directive to write logs in the format you specify. This allows you to use the same log format across multiple log files without having to change it each time. This is especially beneficial when many virtual hosts are utilizing separate log files.

Let’s say you want to build an example format called «vhost_combined.» Then, using the vhost_combined format, we’ll create a CustomLog directive that writes logs to a file.

LogFormat "%v:%p %h %l %u %t "%r" %>s %O "%{Referer}i" "%{User-Agent}i"" vhost_combined
CustomLog /var/log/apache2/vhost.log vhost_combined

Formatting as JSON

If you save your logs as plain text, they’ll be easy to scan if you ever need to read them. This makes it difficult to understand your logs with tools like log management solutions, which require knowledge of how your logs are formatted. The default Apache log format is supported by most log management solutions, but if it isn’t, you should consider adopting a structured format like JSON.

JSON is a lightweight data storage format. JSON holds practically any data type and structure as a set of nestable name/value pairs. JSON is also self-documenting because the key name describes the data it contains. Strings, numbers, booleans, arrays, and null values are among the basic data types supported by JSON.

A LogFormat that saves logs in JSON format looks like this:

LogFormat "{ "time":"%t", "remoteIP":"%a", "host":"%V", "request":"%U", "query":"%q", "method":"%m", "status":"%>s", "userAgent":"%{User-agent}i", "referer":"%{Referer}i" }"

Read must-know tips for JSON logging.

How Do You Clear the Apache Error Log?

Simply put, the log file will get quite large throughout a long period. You won’t need error messages from two years ago at some point. So you’d like to get rid of it to free up some disk space, either by truncating it or backing it up somewhere else.

When it comes to deleting the logs, there’s an interesting problem to solve. The server keeps a handle on the file for writing as long as it is operating. You can’t just open it and start editing it, or back it up and delete it.

Having root access and doing something like this—overwriting the file contents with nothing—might be the simplest method. However, we would recommend making a backup of the file first.

Alternatively, you can follow the instructions for log rotation and piped logs on Apache’s website. These solutions are more complicated, but they are more «proper» and less hacky.

However, regardless of how you approach deleting the logs or logging in general, our advice is to always err on the side of keeping as much information as possible.

Conclusion

The Apache error logs may appear to be simple. More than grepping log files or other ad hoc approaches are required to achieve uptime SLA. You should create a system for storing and analyzing Apache error logs. Tracking and analyzing HTTP error codes, finding outlier IP addresses, listing pages with slow response times, and other metrics that might improve uptime and MTTR.

Atatus

Logs Monitoring and Management

Atatus offers a
Logs Monitoring
solution which is delivered as a fully managed cloud service with minimal setup at any scale that requires no maintenance. It monitors logs from all of your systems and applications into a centralized and easy-to-navigate user interface, allowing you to troubleshoot faster.

We give a cost-effective, scalable method to centralized logging, so you can obtain total insight across your complex architecture. To cut through the noise and focus on the key events that matter, you can search the logs by hostname, service, source, messages, and more. When you can correlate log events with

APM

slow traces and errors, troubleshooting becomes easy.

Try your 14-day free trial of Atatus.