Где искать логи ошибок на сервере

Блоги, форумы, посадочные страницы и другие интернет-ресурсы представляют собой совокупность графического, текстового, аудио- и видео-контента, размещенного на веб-страницах в виде кода. Чтобы обеспечить к ним доступ пользователей через интернет, файлы размещают на серверах. Это аппаратное обеспечение (персональный компьютер или рабочая станция), на жестком диске которого и хранится код. Ключевые функции выполняются без участия человека, что актуально для всех типов оборудования, включая виртуальный выделенный сервер. Но это не означает, что контроль не осуществляется. Большинство событий, которые происходят при участии оборудования, пользователей и софта, включая ошибки, логи сервера фиксируют и сохраняют. Из этой статьи вы узнаете, что они собой представляют, зачем нужны, и как их читать.

Что такое логи

Это текстовые файлы, которые хранятся на жестком диске сервера. Создаются и заполняются в автоматическом режиме, в хронологическом порядке. В них записываются:

• системная информация о переданных пользователю данных;
• сообщения о сбоях и ошибках;
• протоколирующие данные о посетителях платформы.

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

Классификация логов

Для каждой разновидности софта предусмотрены соответствующие файлы. Все логи сервера могут храниться на одном диске или даже на отдельном сервере. Существует довольно много разновидностей логов, вот наиболее распространенные:

• доступа (access_log) — записывают IP-адрес, время запроса, другую информацию о пользователях;
• ошибок (error_log) — показывают файлы, в которых выявлены ошибки и классифицируют сбои;
• FTP-авторизаций — отображают данные о попытках входа по FTP-соединению;
• загрузки системы — с его помощью выполняется отладка при появлении проблем, в файл записываются основные системные события, включая сбои;
• основной — содержит информацию о действиях с файерволом, DNS-сервером, ядром системы, FTP-сервисом;
• планировщика задач — в нем выполняется протоколирование задач, отображаются ошибки при запуске cron;
• баз данных — хранит подробности о запросах, сбоях, ошибки в логах сервера отображаются наравне с другой важной информацией;
• хостинговой панели — включает статистику использования ресурсов сервера, время и количество входов в панель, обновление лицензии;
• веб-сервера — содержит информацию о возникавших ошибках, обращениях;
• почтового сервера — в нем ведутся записи о входящих и исходящих сообщениях, отклонениях писем.

Записи в системные журналы выполняет установленный софт.

Зачем нужны логи

Анализ логов сервера — неотъемлемая часть работы системного администратора или веб-разработчика. Обрабатывая их, специалисты получают массу полезных сведений. Используются в следующих целях:

• поиск ошибок и сбоев в работе системы;
• выявление вредоносной активности;
• сбор статистики посещения веб-ресурса.

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

Где посмотреть логи

Расположение определяется хостинг-провайдером или настройками установленного софта. На виртуальном хостинге доступ к лог-файлам предоставляется из панели управления хостингом. Если администратор не открыл его для владельца сайта, получить информацию не получится. Но большинство провайдеров разрешают свободно пользоваться журналами и проводить анализ логов сервера. Независимо от разновидности сервера лог-файлы хранятся в текстовом документе. По умолчанию он называется access.log, но настройки позволяют переименовать файл. Это актуально для Nginx, Apache, прокси-разновидностей squid, других типов. Для просмотра их надо скачать и открыть в текстовом редакторе. В качестве альтернативы можно использовать Grep и схожие утилиты. Они позволяют открыть и отфильтровать логи прямо на сервере.

Как читать логи. Пример

Существует довольно много форматов записи, combined — один из наиболее распространенных. В нем строчка кода может выглядеть так:

%h %l %u %t \»%r\» %>s %b \»%{Referer}i\» \»%{User-Agent}i\»

Директивы имеют следующее значение:

• %h — IP-адрес, с которого был сделан запрос;
• %l — длинное имя удаленного хоста;
• %u — удаленный пользователь, если запрос был сделан аутентифицированным юзером;
• %t — время запроса к серверу и его часовой пояс;
• %r — тип и содержимое запроса;
• %s — код состояния HTTP;
• %b — количество байт информации, отданных сервером;
• %{Referer} — URL-источник запроса;
• %{User-Agent} — HTTP-заголовок.

Еще один пример чтения логов можно посмотреть в статье «Как читать логи сервера».

Опытные веб-мастера для сбора и чтения лог-файлов используют программы-анализаторы. Они позволяют читать логи сервера без значительных временных затрат. Вот некоторые из наиболее востребованных:

• Analog. Один из самых популярных анализаторов, что во многом объясняется высокой скоростью обработки данных и экономным расходованием системных ресурсов. Хорошо справляется с объемными записями, совместим с любыми ОС.
• Weblog Expert. Программа доступна в трех вариациях: Lite (бесплатная версия), Professional и Standard (платные релизы). Версии отличаются функциональными возможностями, но каждая позволяет анализировать лог-файлы и создает отчеты в PDF и HTML.
• SpyLOG Flexolyzer. Простой аналитический инструмент, позволяющий получать отчеты с высокой степенью детализации. Интегрируется c системой статистики SpyLOG, позволяет решать задачи любой сложности.

Логи сервера с ошибками error.log

Это журнал с информацией об ошибках на сайте. В нем можно посмотреть, какие страницы отсутствуют, откуда пришел пользователь с конкретным запросом, имеются ли «битые» ссылки, другие недочеты, включая те, которые не удалось классифицировать. Используется для выявления багов и погрешностей в коде.

Каждая ошибка в логе сервера error.log отображается с новой строки. Идентифицировав и устранив ее, программист сможет наладить работу сайта. Используя журнал, можно выявить и слабые места веб-платформы. Это простой и удобный инструмент анализа, которым должен уметь пользоваться каждый веб-мастер, системный администратор и программист.

Практически любое ПО или служба в Linux ведут или могут вести логи.

Логи (лог-файлы) — это журналы, куда в процессе работы ПО или службы вносится служебная информация (события, уведомления, примечания, подробности, ошибки и др.), которая может потребоваться в будущем для анализа работы этого ПО или службы.

Относительно сервера чаще всего требуются логи:

• веб-сервера (стоит учитывать, что у связок веб-сервера, например, nginx+php-fpm, свои логи у каждой службы);

• почтового сервера;

• FTP-сервера;

• сервера базы данных (рассмотрим MySQL и PostgreSQL);

• подсистемы авторизации;

• системные логи.

Как правило, в Linux логи хранятся в специальном каталоге /var/log, внутри которого создаются отдельные файлы и папки для того или иного сервиса. Однако стоит учитывать, что для служб и ПО не запрещено задавать специальные каталоги для хранения логов. Например, для виртуальных хостов (сайтов) панель ISPmanager задает специальный каталог (/var/www/htttpd-logs) для удобного анализа логов по каждому сайту отдельно. А, например, стороннее ПО, устанавливаемое в директорию /opt, чаще всего будет вести логи также внутри этого каталога.

Стоит отметить, что несмотря на общую структуру, наименования отдельных файлов и каталогов могут отличаться в зависимости от определенной версии ОС, чаще всего разделяют на Debian-based (Debian/Ubuntu) и RedHat-based (Centos, Rocky Linux, AlmaLinux и т.д.), в статье мы будем разделять именно так.

Далее рассмотрим подробнее особенности вышеназванных наиболее популярных категорий журналов.

Системные логи

Начнем с системных логов как наиболее важных (система — основа работы сервера:)).

• Системный журнал, как правило, записывается в файлы:
  Debian-based:
  /var/log/syslog

  RedHat-based:
  /var/log/messages
  Там находится много различной информации о событиях, процессах и ошибках практически от всех системных служб сервера и, в частности, сообщения от ядра Linux.

  Также к системному логу можно отнести:
  /var/log/dmesg (для удобного просмотра этого журнала можно просто выполнить команду dmesg -T)
  /var/log/kern.log
  в этих файлах ведется журнал с сообщениями ядра и драйверов всех устройств сервера.

  Обратите внимание, что эти логи ведутся с момента старта системы, поэтому часто после ее аварийной перезагрузки довольно сложно узнать, что было, так как этого события уже нет в логе.

• Логи авторизации.
  Сюда вносится информация о входах в систему, в том числе и о неудачных попытках (полезно для отслеживания попыток подбора пароля к системе и выяснения, кто был на сервере)
  Debian-based:
  /var/log/auth.log

  RedHat-based:
  /var/log/secure

• Лог загрузки ОС:
  /var/log/boot.log

• Лог планировщика (CRON) системы:
  /var/log/cron

Логи веб-сервера

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

У Apache и Nginx есть свои логи, как правило, двух категорий:  первая — хранит журнал посещений, вторая — хранит информацию об ошибках, уведомлениях, примечаниях, предупреждениях и т. д.

Также в связке с Nginx довольно часто устанавливается интерпретатор PHP (php-fpm), соответственно, он тоже имеет свой лог с ошибками и уведомлениями.

Логи веб-сервера Apache

Apache создает два лог-файла:

• лог посещений (доступа) (access.log/access_log);

• лог ошибок (error.log/error_log).

Конфигурация Apache позволяет задать хранение этих файлов отдельно для каждого сайта, размещенного на сервере. Хороший пример — реализация журналов веб-сервера в панели ISPmanager — логи хранятся в директории /var/www/httpd-logs и называются domain.name.access.log и domain.name.error.log, где вместо domain.name — имя определенного домена. Могут быть и другие реализации хранения логов, это всегда отражено в конфигурационных файлах веб-сервера.

Что касается стандартной реализации, то логи на Debian-based системах хранятся в каталоге /var/log/apache2, а у RedHat-based систем в каталоге /var/log/httpd.

Логи веб-сервера Nginx

Nginx создает тоже два файла, хранящих журнал посещений и журнал ошибок. Файлы находятся в каталоге /var/log/nginx. В случае конфигурации веб-сервера как связки Nginx с Apache, журналы Nginx иногда пишутся в одном файле с логами Apache, с одной стороны, это может быть удобно, но в некоторых случаях для обнаружения ошибок это может создать трудности.

Также как и в Apache, Nginx может быть настроен для ведения логов каждого сайта отдельно.

Пример отображения стандартных логов Nginx в консоли:

Файлы  .gz — это архивы логов, созданные в результате ротации логов, о ней расскажем позже.

Логи PHP-интерпретатора

Стандартно PHP-интерпретатор входит в конфигурацию Apache как модуль PHP. В таком случае все ошибки PHP хранятся там же, где основной лог Apache.
Если интерпретатор PHP работает в виде службы PHP-FPM (например, для связки веб-сервера Nginx+PHP-fpm), то логи хранятся отдельно, в каталоге /var/log/php-fpm.

В PHP (через конфигурационный файл php.ini) возможно настроить запись ошибок в определенный лог-файл, либо задать запись ошибок на определенной странице в отдельный файл (это уже осуществляется через файл .htaccess в соответствующем каталоге сайта). Чаще всего для таких случаев задают имя файла php_error.log или просто error.log, располагаться они могут как в каталоге сайта, так и любом другом каталоге пользователя, проверить лучше непосредственно в конфигурации PHP и веб-сервера.

Логи почтовой службы

На серверах довольно часто, помимо веб-сервера, присутствует и почтовая служба для отправки и приема писем все с тех же сайтов или отдельно через электронные почтовые ящики. Наиболее популярной конфигурацией почты сейчас является связка Exim (отправка и прием писем по протоколу SMTP) и Dovecot с сортировщиком sieve (для доступа пользователей к почтовым ящикам по протоколу IMAP/POP3).

В этом случае логи Exim находятся в каталоге /var/log/exim, чаще всего интересует файл mainlog (в нем хранятся все события почтовой службы), еще есть panic.log (там находятся сообщения об ошибках).

У Dovecot же логи, как правило, пишутся в файл /var/log/maillog или /var/log/mail.log, в него заносится информация о доставке, приеме и сортировке писем.

Логи FTP

В качестве FTP-службы в Linux есть несколько вариантов ПО, но в целом методика ведения логов у каждого ПО примерно схожая.  В папке /var/log создаются журналы FTP-сервера, в случае использования vsFTPd это будет файл vsftpd.log, а в случае proFTPd — proftpd.log. В случае PURE-FTPd поищите файл /var/log/pureftpd.log. Если лога FTP вы не обнаружите, скорее всего, он все равно ведется, но уже в системных логах, упомянутых выше, это:

• Debian-based:

/var/log/syslog

• RedHat-based:

/var/log/messages

Также некоторые FTP-службы имеют файл лога xferlog, в котором пишется информация обо всех передачах по протоколу FTP.

Логи сервера базы данных

Рассмотрим сначала наиболее распространенный сервер баз данных MySQL. В стандартной настройке он ведет лог в файле mysqld.log или mysql.log. Файл располагается в папке /var/log/mysql или /var/log/mariadb, в зависимости от используемой версии MySQL.

Однако чаще всего в этот файл задается ведение general log, он же лог запросов, но так как этот лог очень быстро заполняется и начинает занимать много места на диске, то без особой необходимости его ведение не включают, а в лог если что и пишется, то ошибки и уведомления. Они заносятся, как правило, в файл error.log или mysql_error.log.

Также сервер MySQL может создавать в этой папке файл отладки медленных запросов к базе данных. Обычно он называется mysql_slow.log.
Иногда, в случае если настроена репликация баз данных, включают и ведение бинарных логов, они заносятся в файл mysql-bin.log. Этот лог, помимо большого своего объема на диске, также может снизить производительность сервера баз данных, поэтому также без особой необходимости включать его ведение не стоит.

Относительно сервера баз данных PostgreSQL можно отметить, что ведение логов задается в разных случаях в совершенно разные директории. Стоит посмотреть значение переменной log_filename в конфигурационном файле PostgreSQL, если этот параметр не задан, но при этом параметр logging_collector в статусе on, то лог ведется по следующему пути:

• Debian-based:

/var/log/postgresql/postgresql-x.x.main.log
где x.x — номер версии PostgreSQL

• RedHat-based:

/var/lib/pgsql/data/pg_log

Ротация логов

Для сайтов, имеющих активную посещаемость или большое количество уведомлений и ошибок PHP на многих страницах сайта, размеры журналов могут очень быстро разрастись и в конечном итоге заполнить диск сервера. Для предотвращения этих ситуаций в Linux есть стандартный инструмент ротации логов — logrotate.

На примере логов веб-сервера работает он так. Раз в сутки (время можно задавать) файл лога, например, access.log переименовывается logrotate’ом в access.log.1 и проходит через gzip-сжатие, после чего получает имя access.log.1.gz. А вместо переименованного access.log тут же создается новый пустой файл с этим именем, куда и продолжает писаться информация о посещениях. На следующие сутки, уже при наличии файла access.log.1.gz, аналогично создается файл уже с именем access.log.2.gz, таким же образом далее все дни. Количество хранимых архивов и период можно настроить.

По такому же принципу ротируются логи и других служб — FTP, почтовой службы, системные логи.

Главная задача ротации логов — экономить место на диске, а также иметь понятную логику доступа к архивам логов. Однако в случае бесконтрольной и объемной записи в лог, пространство диска может очень быстро закончиться еще до момента срабатывания ротации логов. В этом случае необходимо настроить ротацию логов на более частый период, но, как правило, такие ситуации случаются нечасто, и можно вручную очистить лог — эту ситуацию мы рассматривали в другой нашей статье.

Чтение лог-файлов

Логи бывают разные, как и способы их чтения.

Стандартным советом для просмотра содержимого текстового файла был бы совет использовать команду:

cat имя.лога

Однако, в случае когда логи объемны и, например, активно ведутся целый день, команда cat вывалит на вас гору информации, неудобную для просмотра.

Она может быть полезна, только если вы ищите сразу в логе что-то определенное, например, ошибку:

cat имя.лога | grep err

Но даже в этом случае ошибку можно поискать сразу командой grep:

grep 'err' имя.лога

Без поиска же более логичен в данном случае просмотр лога через инструмент tail:

• tail имя.лога — выведет последние 10 строк журнала,
• tail -n 100 имя.лога — выведет последние 100 строк журнала, числовое значение можно менять в зависимости от необходимого числа строк,
• tail -f имя.лога — просмотр лога в «прямом эфире», т. е. все поступаемые в лог записи тут же обновляются на экране, удобно для отслеживания ошибок, появляющихся после определенных действий.

Ну, а если все же требуется прочитать весь объемный лог или как минимум пробежаться глазами для отслеживания событий, для этого есть более удобный, чем cat, инструмент less:

less имя.лога — покажет первую страницу лога (те строки, которые поместятся на экран консоли), пролистывать можно клавишами «вверх»/«вниз» (построчно) и PageUp/PageDown (постранично).

Важно, для выхода из просмотра в less, просто нажмите клавишу q.

Также можно, не листая текст, найти в логе определенный фрагмент, просто начав печатать искомую фразу или фрагмент в поле с мигающим курсором, в начале напечатав символ / (для поиска вниз по тексту) и ? (для поиска вверх по тексту).

После ввода необходимой части текста, нажмите Enter, все участки текста, которые подходят условиям поиска, будут подсвечены.

Для быстрого перехода в конец файла, нажмите клавишу G, для перехода в начало файла — g.

В этой статье мы разобрали лишь базовые логи и базовые инструменты для работы с журналами сервера. Так как в системах Linux, по большей части, все создается единообразно, разобравшись с базовыми элементами и основными логами, вам не составит труда в будущем найти и поработать с логами каких-либо других служб, установленных на сервер.

Как посмотреть логи

• Что такое логи сервера
• Как проверить логи сервера
• Как посмотреть логи хостинга

В этой статье мы расскажем, что такое логи сервера, где они хранятся и как посмотреть их на разных операционных системах и веб-серверах.

Что такое логи сервера

Логи сервера (англ. Server Logs ― журнал сервера) ― это текстовые файлы, в которые в хронологическом порядке записывается информация. Обычно это системная информация о работе сервера и взаимодействии пользователей с ним.

Логи отличаются тем, к каким приложениям они относятся, и тем, какую информацию они несут. Вот несколько типов логов:

• логи доступа (access.log) — в них фиксируются обращения к сайтам, 
• логи ошибок (error.log) — в них веб-сервер фиксирует ошибки при обращении к сайтам, 
• логи баз данных — в них фиксируются действия с базами данных, 
• почтовые логи — в них содержится информация о недоставленных, отправленных и принятых письмах. 

Логи могут храниться как на самом сервере, чьи события логируются, так и на отдельном файловом сервере.

Как проверить логи сервера

Рассмотрим несколько вариантов логов на серверах с операционными системами Ubuntu и CentOS. И в Ubuntu, и в CentOS директория /var/log ― это место, где хранятся логи сервера. Мы расскажем о некоторых лог-файлах из этой папки.

Обратите внимание: чтобы выполнить команды, приведённые ниже, подключитесь к серверу по SSH.

Логи SSH CentOS

Логи авторизаций (в том числе SSH-подключений) на сервере с CentOS находятся в файле /var/log/secure. Чтобы открыть этот файл, воспользуйтесь командой:

sudo nano /var/log/secure

Чтобы получить из файла только неудачные попытки подключений по SSH, введите:

grep -a "Failed password" /var/log/secure

Чтобы вывести логи только SSH-подключений:

grep -a “sshd” /var/log/secure

Если вы хотите посмотреть логи подключений конкретного пользователя: 

grep -a “username” /var/log/secure

Вместо username введите имя пользователя.

Логи SSH Ubuntu

Журнал авторизации пользователей в Ubuntu находится в файле /var/log/auth.log.

Открыть всё содержимое файла:

sudo nano /var/log/auth.log

Вывести неудачные попытки подключений:

grep -a "Failed password" /var/log/auth.log

Вывести логи всех SSH-подключений:

grep -a "sshd" /var/log/auth.log

Логи подключений конкретного пользователя:

grep -a "username" /var/log/auth.log

Вместо username введите имя пользователя.

Как посмотреть логи хостинга

Посмотреть логи хостинга можно через панель управления ISPmanager или через подключение по FTP или SSH.

ISPmanager

1. Откройте панель управления хостингом ISPmanager.
2. В левом меню нажмите Менеджер файлов:
3. Откройте директорию logs:
4. 
   В этой папке вы найдёте лог-файлы ваших сайтов:
   
   В названии каждого файла указано имя сайта и тип логов:

• domain-name.ru.access.log ― это логи доступа к сайту domain-name.ru,
• domain-name.ru.error.log ― это логи ошибок сайта domain-name.ru. 

Готово, теперь вы знаете, как посмотреть логи ваших сайтов через панель управления ISPmanager. 

FTP

1. Подключитесь к хостингу по FTP.
2. Откройте директорию /logs:
   
3. Чтобы, не скачивая, открыть лог-файл в текстовом редакторе, кликните правой кнопкой мыши на нужный файл и нажмите на Просмотр/правка:
   

Готово, теперь вы знаете, как проверить логи сайтов на хостинге через FTP. 

SSH

1. Подключитесь к услуге хостинга по SSH.
2. Перейдите в директорию /logs при помощи команды:

   cd logs

3. Выведите список файлов на экран:

   ls -la

4. Откройте нужный файл при помощи текстового редактора Vim:

   vim log-file-name

   Вместо log-file-name введите имя лог-файла. 

5. Чтобы закрыть редактор без сохранения изменений в файле, нажмите ESC и введите:

   :q!

Готово, теперь вы знаете, как проверить логи сайтов на хостинге через SSH.

In this tutorial, you will learn everything you need to know about logging in
NGINX and how it can help you troubleshoot and quickly resolve any problem you
may encounter on your web server. We will discuss where the logs are stored and
how to access them, how to customize their format, and how to centralize them in
one place with Syslog or a log management service.

Prerequisites

To follow through with this tutorial, you need the following:

• A Linux server that includes a non-root user with sudo privileges. We tested
  the commands shown in this guide on an Ubuntu 20.04 server.
• The
  NGINX web server installed
  and enabled on your server.

Step 1 — Locating the NGINX log files

NGINX writes logs of all its events in two different log files:

• Access log: this file contains information about incoming requests and
  user visits.
• Error log: this file contains information about errors encountered while
  processing requests, or other diagnostic messages about the web server.

The location of both log files is dependent on the host operating system of the
NGINX web server and the mode of installation. On most Linux distributions, both
files will be found in the /var/log/nginx/ directory as access.log and
error.log, respectively.

A typical access log entry might look like the one shown below. It describes an
HTTP GET request to the server for a favicon.ico file.

217.138.222.101 - - [11/Feb/2022:13:22:11 +0000] "GET /favicon.ico HTTP/1.1" 404 3650 "http://135.181.110.245/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.87 Safari/537.36" "-"

Similarly, an error log entry might look like the one below, which was generated
due to the inability of the server to locate the favicon.ico file that was
requested above.

2022/02/11 13:12:24 [error] 37839#37839: *7 open() "/usr/share/nginx/html/favicon.ico" failed (2: No such file or directory), client: 113.31.102.176, server: _, request: "GET /favicon.ico HTTP/1.1", host: "192.168.110.245:80"

In the next section, you’ll see how to view both NGINX log files from the
command line.

Step 2 — Viewing the NGINX log files

Examining the NGINX logs can be done in a variety of ways. One of the most
common methods involves using the tail command to view logs entries in
real-time:

sudo tail -f /var/log/nginx/access.log

You will observe the following output:

107.189.10.196 - - [14/Feb/2022:03:48:55 +0000] "POST /HNAP1/ HTTP/1.1" 404 134 "-" "Mozila/5.0"
35.162.122.225 - - [14/Feb/2022:04:11:57 +0000] "GET /.env HTTP/1.1" 404 162 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0"
45.61.172.7 - - [14/Feb/2022:04:16:54 +0000] "GET /.env HTTP/1.1" 404 197 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36"
45.61.172.7 - - [14/Feb/2022:04:16:55 +0000] "POST / HTTP/1.1" 405 568 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36"
45.137.21.134 - - [14/Feb/2022:04:18:57 +0000] "GET /dispatch.asp HTTP/1.1" 404 134 "-" "Mozilla/5.0 (iPad; CPU OS 7_1_2 like Mac OS X; en-US) AppleWebKit/531.5.2 (KHTML, like Gecko) Version/4.0.5 Mobile/8B116 Safari/6531.5.2"
23.95.100.141 - - [14/Feb/2022:04:42:23 +0000] "HEAD / HTTP/1.0" 200 0 "-" "-"
217.138.222.101 - - [14/Feb/2022:07:38:40 +0000] "GET /icons/ubuntu-logo.png HTTP/1.1" 404 197 "http://168.119.119.25/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.87 Safari/537.36"
217.138.222.101 - - [14/Feb/2022:07:38:42 +0000] "GET /favicon.ico HTTP/1.1" 404 197 "http://168.119.119.25/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.87 Safari/537.36"
217.138.222.101 - - [14/Feb/2022:07:44:02 +0000] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.87 Safari/537.36"
217.138.222.101 - - [14/Feb/2022:07:44:02 +0000] "GET /icons/ubuntu-logo.png HTTP/1.1" 404 197 "http://168.119.119.25/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.87 Safari/537.36"

The tail command prints the last 10 lines from the selected file. The -f
option causes it to continue displaying subsequent lines that are added to the
file in real-time.

To examine the entire contents of an NGINX log file, you can use the cat
command or open it in your text editor:

sudo cat /var/log/nginx/error.log

If you want to filter the lines that contain a specific term, you can use the
grep command as shown below:

sudo grep "GET /favicon.ico" /var/log/nginx/access.log

The command above will print all the lines that contain GET /favicon.ico so we
can see how many requests were made for that resource.

Step 3 — Configuring NGINX access logs

The NGINX access log stores data about incoming client requests to the server
which is beneficial when deciphering what users are doing in the application,
and what resources are being requested. In this section, you will learn how to
configure what data is stored in the access log.

One thing to keep in mind while following through with the instructions below is
that you’ll need to restart the nginx service after modifying the config file
so that the changes can take effect.

sudo systemctl restart nginx

Enabling the access log

The NGINX access Log should be enabled by default. However, if this is not the
case, you can enable it manually in the Nginx configuration file
(/etc/nginx/nginx.conf) using the access_log directive within the http
block.

http {
  access_log /var/log/nginx/access.log;
}

This directive is also applicable in the server and location configuration
blocks for a specific website:

server {
   access_log /var/log/nginx/app1.access.log;

  location /app2 {
    access_log /var/log/nginx/app2.access.log;
  }
}

Disabling the access log

In cases where you’d like to disable the NGINX access log, you can use the
special off value:

You can also disable the access log on a virtual server or specific URIs by
editing its server or location block configuration in the
/etc/nginx/sites-available/ directory:

server {
  listen 80;

  access_log off;

  location ~* \.(woff|jpg|jpeg|png|gif|ico|css|js)$ {
    access_log off;
  }
}

Logging to multiple access log files

If you’d like to duplicate the access log entries in separate files, you can do
so by repeating the access_log directive in the main config file or in a
server block as shown below:

access_log /var/log/nginx/access.log;
access_log /var/log/nginx/combined.log;

Don’t forget to restart the nginx service afterward:

sudo systemctl restart nginx

Explanation of the default access log format

The access log entries produced using the default configuration will look like
this:

127.0.0.1 alice Alice [07/May/2021:10:44:53 +0200] "GET / HTTP/1.1" 200 396 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4531.93 Safari/537.36"

Here’s a breakdown of the log message above:

• 127.0.0.1: the IP address of the client that made the request.
• alice: remote log name (name used to log in a user).
• Alice: remote username (username of logged-in user).
• [07/May/2021:10:44:53 +0200] : date and time of the request.
• "GET / HTTP/1.1" : request method, path and protocol.
• 200: the HTTP response code.
• 396: the size of the response in bytes.
• "-": the IP address of the referrer (- is used when the it is not
  available).
• "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4531.93 Safari/537.36" —
  detailed user agent information.

Step 4 — Creating a custom log format

Customizing the format of the entries in the access log can be done using the
log_format directive, and it can be placed in the http, server or
location blocks as needed. Here’s an example of what it could look like:

log_format custom '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"';

This yields a log entry in the following format:

217.138.222.109 - - [14/Feb/2022:10:38:35 +0000] "GET /favicon.ico HTTP/1.1" 404 197 "http://192.168.100.1/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.87 Safari/537.36"

The syntax for configuring an access log format is shown below. First, you need
to specify a nickname for the format that will be used as its identifier, and
then the log format string that represents the details and formatting for each
log message.

log_format <nickname> '<formatting_variables>';

Here’s an explanation of each variable used in the custom log format shown
above:

• $remote_addr: the IP address of the client
• $remote_user: information about the user making the request
• $time_local: the server’s date and time.
• $request: actual request details like path, method, and protocol.
• $status: the response code.
• $body_bytes_sent: the size of the response in bytes.
• $http_referer: the IP address of the HTTP referrer.
• $http_user_agent: detailed user agent information.

You may also use the following variables in your custom log format
(see here for the complete list):

• $upstream_connect_time: the time spent establishing a connection with an
  upstream server.
• $upstream_header_time: the time between establishing a connection and
  receiving the first byte of the response header from the upstream server.
• $upstream_response_time: the time between establishing a connection and
  receiving the last byte of the response body from the upstream server.
• $request_time: the total time spent processing a request.
• $gzip_ratio: ration of gzip compression (if gzip is enabled).

After you create a custom log format, you can apply it to a log file by
providing a second parameter to the access_log directive:

access_log /var/log/nginx/access.log custom;

You can use this feature to log different information in to separate log files.
Create the log formats first:

log_format custom '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer"';
log_format agent "$http_user_agent";

Then, apply them as shown below:

access_log /var/log/nginx/access.log custom;
access_log /var/log/nginx/agent_access.log agent;

This configuration ensures that user agent information for all incoming requests
are logged into a separate access log file.

Step 5 — Formatting your access logs as JSON

A common way to customize NGINX access logs is to format them as JSON. This is
quite straightforward to achieve by combining the log_format directive with
the escape=json parameter introduced in Nginx 1.11.8 to escape characters that
are not valid in JSON:

log_format custom_json escape=json
  '{'
    '"time_local":"$time_local",'
    '"remote_addr":"$remote_addr",'
    '"remote_user":"$remote_user",'
    '"request":"$request",'
    '"status": "$status",'
    '"body_bytes_sent":"$body_bytes_sent",'
    '"request_time":"$request_time",'
    '"http_referrer":"$http_referer",'
    '"http_user_agent":"$http_user_agent"'
  '}';

After applying the custom_json format to a log file and restarting the nginx
service, you will observe log entries in the following format:

{
  "time_local": "14/Feb/2022:11:25:44 +0000",
  "remote_addr": "217.138.222.109",
  "remote_user": "",
  "request": "GET /icons/ubuntu-logo.png HTTP/1.1",
  "status": "404",
  "body_bytes_sent": "197",
  "request_time": "0.000",
  "http_referrer": "http://192.168.100.1/",
  "http_user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.87 Safari/537.36"
}

Step 6 — Configuring NGINX error logs

Whenever NGINX encounters an error, it stores the event data in the error log so
that it can be referred to later by a system administrator. This section will
describe how to enable and customize the error logs as you see fit.

Enabling the error log

The NGINX error log should be enabled by default. However, if this is not the
case, you can enable it manually in the relevant NGINX configuration file
(either at the http, server, or location levels) using the error_log
directive.

error_log /var/log/nginx/error.log;

The error_log directive can take two parameters. The first one is the location
of the log file (as shown above), while the second one is optional and sets the
severity level of the log. Events with a lower severity level than set one will
not be logged.

error_log /var/log/nginx/error.log info;

These are the possible levels of severity (from lowest to highest) and their
meaning:

• debug: messages used for debugging.
• info: informational messages.
• notice: a notable event occurred.
• warn: something unexpected happened.
• error: something failed.
• crit: critical conditions.
• alert: errors that require immediate action.
• emerg: the system is unusable.

Disabling the error log

The NGINX error log can be disabled by setting the error_log directive to
off or by redirecting it to /dev/null:

error_log off;
error_log /dev/null;

Logging errors into multiple files

As is the case with access logs, you can log errors into multiple files, and you
can use different severity levels too:

error_log /var/log/nginx/error.log info;
error_log /var/log/nginx/emerg_error.log emerg;

This configuration will log every event except those at the debug level event
to the error.log file, while emergency events are placed in a separate
emerg_error.log file.

Step 7 — Sending NGINX logs to Syslog

Apart from logging to a file, it’s also possible to set up NGINX to transport
its logs to the syslog service especially if you’re already using it for other
system logs. Logging to syslog is done by specifying the syslog: prefix to
either the access_log or error_log directive:

error_log  syslog:server=unix:/var/log/nginx.sock debug;
access_log syslog:server=[127.0.0.1]:1234,facility=local7,tag=nginx,severity=info;

Log messages are sent to a server which can be specified in terms of a domain
name, IPv4 or IPv6 address or a UNIX-domain socket path.

In the example above, error log messages are sent to a UNIX domain socket at the
debug logging level, while the access log is written to a syslog server with
an IPv4 address and port 1234. The facility= parameter specifies the type of
program that is logging the message, the tag= parameter applies a custom tag
to syslog messages, and the severity= parameter sets the severity level of
the syslog entry for access log messages.

For more information on using Syslog to manage your logs, you can check out our
tutorial on viewing and configuring system logs on
Linux.

Step 8 — Centralizing your NGINX logs

In this section, we’ll describe how you can centralize your NGINX logs in a log
management service through Vector, a
high-performance tool for building observability pipelines. This is a crucial
step when administrating multiple servers so that you can monitor all your logs
in one place (you can also centralize your logs with an Rsyslog
server).

The following instructions assume that you’ve signed up for a free
Logtail account and retrieved your source
token. Go ahead and follow the relevant
installation instructions for Vector
for your operating system. For example, on Ubuntu, you may run the following
commands to install the Vector CLI:

curl -1sLf \ 'https://repositories.timber.io/public/vector/cfg/setup/bash.deb.sh' \ | sudo -E bash

After Vector is installed, confirm that it is up and running through
systemctl:

You should observe that it is active and running:

● vector.service - Vector
     Loaded: loaded (/lib/systemd/system/vector.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2022-02-08 10:52:59 UTC; 48s ago
       Docs: https://vector.dev
    Process: 18586 ExecStartPre=/usr/bin/vector validate (code=exited, status=0/SUCCESS)
   Main PID: 18599 (vector)
      Tasks: 3 (limit: 2275)
     Memory: 6.8M
     CGroup: /system.slice/vector.service
             └─18599 /usr/bin/vector

Otherwise, go ahead and start it with the command below.

sudo systemctl start vector

Afterward, change into a root shell and append your Logtail vector configuration
for NGINX into the /etc/vector/vector.toml file using the command below. Don’t
forget to replace the <your_logtail_source_token> placeholder below with your
source token.

wget -O ->> /etc/vector/vector.toml \
    https://logtail.com/vector-toml/nginx/<your_logtail_source_token>

Then restart the vector service:

sudo systemctl restart vector

You will observe that your NGINX logs will start coming through in Logtail:

Conclusion

In this tutorial, you learned about the different types of logs that the NGINX
web server keeps, where you can find them, how to understand their formatting.
We also discussed how to create your own custom log formats (including a
structured JSON format), and how to log into multiple files at once. Finally, we
demonstrated the process of sending your logs to Syslog or a log management
service so that you can monitor them all in one place.

Thanks for reading, and happy logging!

Next article

→

Логи сервера

Если вы хотите знать всё про логи сервера, читайте нашу статью. Мы расскажем, что такое logs, для чего они нужны и покажем, как посмотреть их.

Что такое логи

Чтобы объяснить, что такое логи сервера, скажем несколько слов о самих серверах.

На серверах хранятся файлы сайтов. Чтобы перейти на сайт, пользователь заходит в браузер и вбивает запрос. Затем браузер обращается к серверу, получает файлы нужного сайта и отображает их пользователю. Попадая на сайт, посетитель совершает различные действия — переходит на страницы, оформляет заказ, совершает оплату и другое. При каждом действии посетитель и сервер взаимодействуют друг с другом на уровне интернет-системы.

Логи — это текстовые файлы, в которых хранится информация о пользователях, их взаимодействии с сервером, а также системная информация о работе сервера. Логи формируются в автоматическом режиме и сохраняются в хронологическом порядке. Поэтому их также называют журналом сервера (Server Logs).

Можно выделить несколько основных типов логов:

• сведения о каждом обращении (IP-адрес и тип браузера посетителя) — access_log,
• протоколы действий каждого посетителя (из какого источника перешел на сайт, сколько на нём находился, какие совершал операции и другое),
• записи о сбоях и ошибках — error_log,
• записи о входящих и исходящих сообщениях — почтовые логи,
• сведения о загрузках и основные события в системе,
• данные о количестве входов по FTP-соединению,
• данные о действиях с файерволом, DNS-сервером, ядром системы,
• статистика использования ресурсов сервера, время и количество входов в панель, обновление лицензии.

Где хранятся логи сервера

В некоторых случаях для хранения логов используют отдельный файловый сервер. Но чаще всего логи хранятся на жёстком диске основного сервера. Они располагаются в корневой директории хостинга в системной папке logs. Точный путь до лога будет зависеть от операционной системы сервера. Например, логи SSH Ubuntu хранятся в /var/log/auth.log, а логи SSH CentOS в /var/log/secure.

Зачем проверять логи

Чаще всего обращаться к содержимому логов и анализировать его приходится системным администраторам. Анализ логов необходим в следующих ситуациях:

• сбои в работе сервера,
• резкое повышение нагрузки,
• подозрение на спам-атаки и другое.

Однако уметь анализировать журнал полезно не только админам, но и владельцам сайтов и другим пользователям с доступом в админку. Для этого нужно понимать, как устроены логи.

Как устроены логи

Каждый тип logs имеет свою структуру. В качестве примера разберём структуру access_log:

123.123.123.123 - - [01/Janr/2021:10:00:00 +0300] "GET /wp-includes/feed.php HTTP/1.0" 200 - "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36"

Здесь:

• 123.123.123.123 — IP-адрес, с которого был сделан запрос,
• [01/Janr/2021:10:00:00 +0300] — дата и время запроса,
• GET — метод запроса,
• /wp-includes/feed.php — объект запроса,
• HTTP/1.0 — протокол, по которому прошёл запрос,
• 200 — код ответа,
• Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36 — информация о посетителе.

Также структура логов зависит от операционной системы сервера. Например, логи сервера Windows устроены в виде структурированной таблицы. Поэтому, чтобы научиться «читать» логи, нужна практика.

Если вы разобрались со структурой logs, можно приступать к их просмотру. Существует несколько способов, с помощью которых можно посмотреть журнал сайта. Выбор способа будет зависеть от типа платформы, на которой расположен ваш сайт — VPS-сервер или хостинг.

Как проверить логи сервера VPS

Чтобы посмотреть логи:

Готово.

Как проверить логи хостинга

Чтобы посмотреть содержимое журнала, нужно открыть папку и скачать нужный файл на локальный ПК. Это можно сделать одним из двух способов:

• в хостинг-панели управления, если вы являетесь клиентом Рег.ру,
• через подключение по FTP.

В панели управления хостингом

По FTP

Чтобы скачать логи:

Теперь вы знаете, что такое журнал сайта и где можно посмотреть логи сервера.