Содержание материала
Где можно найти логи сервера
Посмотреть логи сервера можно:
- непосредственно в каталоге на жёстком диске, где они лежат. Доступ ко всем логам есть только на виртуальном или выделенном сервере. Если у вас виртуальный хостинг, доступ будет только к тем логам, которые находятся непосредственно в вашем каталоге;
- из панели хостинга;
- на FTP-сервере;
- запросив логи у техподдержки хостинг-провайдера.
Что касается панели хостинга, то здесь логи часто размещают прямо в веб-интерфейсе панели, в разделах с аналогичным названием: «лог FTP-сервера», «лог ошибок сайта». Точное расположение разделов можно посмотреть в справке или уточнить у техподдержки.
На виртуальном или выделенном сервере журналы сервера ищем на жёстком диске. В зависимости от типа сервера, операционной системы, настроек программного обеспечения точное местоположение может быть разным — уточните у техподдержки, где искать тот или иной лог. Но есть универсальные моменты, которые помогут вам найти логи самостоятельно:
- папка с логами называется logs или log;
- файл с логами содержит в названии log (access_log, error_log).
Видео
Различие в хранении log-файлов по версиям Linux
Дистрибутивы Linux имеют разный набор программного обеспечения и различные правила хранении log-файлов. В настоящее время наибольшее распространение получили два семейства дистрибутивов Linux:
- системы, основанные на Debian (например, Ubuntu);
- основанные на RedHat (Centos, Fedora).
Конкретная версия операционной системы для VPS/VDS выбирается у провайдера в личном кабинете пользователя перед заказом виртуального сервера.
Общие принципы для всех систем Linux одинаковы: log-файлы хранятся в папке /var/log. Разница проявляется лишь в наименовании отдельных файлов и каталогов для определенных подсистем, что зависит не только от версии Linux, но и от используемой панели управления хостингом.
Ведите логи только на правильных уровнях
Как следствие абстракции, разные уровни имеют разные степени понимания выполняемой задачи. В предыдущем примере уровень HTTP не владел данными ни о количестве отправляемых пакетов TCP, ни о намерении пользователей в момент URL-запроса. Предпринимая попытку логирования, разработчикам следует выбрать правильный уровень, который содержит полную информацию о переходах состояний и причинах.
Вернемся к нашему примеру проверки корректности номера социального страхования. Допустим, что логика его проверки обернута в класс Validator следующим образом:
Есть еще другая функция, которая проверяет запрос, обновляющий информацию о пользователе, и вызывает проверку номера социального страхования.
Существует два местоположения (A и B) для записи логов об ошибке проверки номера социального страхования, но только B владеет достаточной для этого информацией . В A программа не знает, ни какой запрос она обрабатывает, ни от какого пользователя он поступает. Логирование просто добавляет деталей. Будет лучше, если validateUserUpdateRequest выбросит ошибку из вызывающего компонента (validateRequest), содержащего больше контекста для лога.
Однако это вовсе не означает, что логирование на нижних уровнях программы совершенно необязательно, особенно когда они не раскрывают ошибки верхним уровням. Например, сетевой уровень может иметь встроенную логику повторных попыток, из чего следует, что верхние уровни не замечают проблем с прерывающимися соединениями. В общем, нижние уровни могут вести логи больше на уровне DEBUG, чем на INFO, в целях сокращения многословности. При необходимости разработчики могут настроить уровень лога для получения большего количества деталей.
Существует очевидное соотношение между объемом логов и их полезностью. Чем более содержательные логи, тем легче реконструировать переходы состояний. Вы можете воспользоваться двумя способами контроля количества логов:
Отладка
Отладка — это мысленная реконструкция переходов состояний. Разработчики проигрывают в уме сценарий программы: как она принимает вводные данные, проходит через ряд изменений состояний и осуществляет вывод, а затем определяют, что пошло не так. Во время разработки этот мыслительный процесс подкрепляется использованием отладчика. Однако в продакшене делать это уже гораздо сложнее, поэтому на данном этапе чаще прибегают к помощи логов.
Понимая суть процесса отладки, мы с легкостью ответим на этот вопрос:
Логи должны содержать информацию, необходимую для реконструкции переходов состояний.
Невозможно, да и не нужно, фиксировать все состояния во все отрезки времени. Например, полиции достаточно лишь нескольких точных набросков, а не видеоклона, для поимки преступника. Тоже самое относится и к логам: разработчикам нужно только внести в них информацию о том, когда происходит переход в критическое состояние. Кроме того, логи должны содержать ключевые характеристики текущего состояния и причину перехода.
Уровни логирования
Чем больше информации выводится в логах, тем лучше и проще отладка, но когда данных слишком много, то в них тяжело искать нужное. В особо сложных случаях логи могут генерироваться с огромной скоростью и в гигантских размерах. Работать в такой ситуации нелегко. Чтобы как-то сгладить ситуацию, системы логирования вводят разные уровни. Обычно это:
- debug
- info
- warning
- error
Поддержка уровней осуществляется двумя способами. Во-первых, внутри самой программы расставляют вызовы библиотеки логирования в соответствии с уровнями. Если произошла ошибка, то логируем как error, если это отладочная информация, которая не нужна в обычной ситуации, то уровень debug.
// Пример логирования внутри программы // Логер: https://github.com/pinojs/pino import buildLogger from ‘pino‘; const logger = buildLogger(/* возможная конфигурация */); logger.info(‘тут что то полезное‘);
Во-вторых, во время запуска программы указывается уровень логирования, необходимый в конкретной ситуации. По умолчанию используется уровень info, который используется для описания каких-то ключевых и важных вещей. При таком уровне будут выводиться и warning, и error. Если поставить уровень error, то будут выводиться только ошибки. А если debug, то мы получим лог, максимально наполненный данными. Обычно debug приводит к многократному росту выводимой информации.
Уровни логирования, обычно, выставляются через переменную окружения во время запуска программы. Например, так:
# https://github.com/fastify/fastify-cli#options FASTIFY_LOG_LEVEL=debug fastify-server.js
Существует и другой подход, основанный не на уровнях, а на пространствах имен. Этот подход получил широкое распространение в JS-среде, и является там основным. Фактически, он построен вокруг одной единственной библиотеки debug для логирования, которой пронизаны практически все JavaScript-библиотеки как на фронтенде, так и на бекенде.
Принцип работы здесь такой. Под нужную ситуацию создается специализированная функция логирования с указанием пространства имен, которая затем используется для всех событий одного процесса. В итоге библиотека позволяет легко отфильтровать только нужные записи, соответствующие нужному пространству.
import debug from ‘debug‘; // Пространство имен http const logHttp = debug(‘http‘); const logSomethingElse = debug(‘another-namespace‘); // Где-то в коде logHttp(/* информация о http запросе */);
Запуск с нужным пространством:
DEBUG=http server.js
Какие есть виды логов?
На практике видов логов может быть несколько. Рассмотрим каждый из них.
- Логи системы — это логи, связанные с системными событиями.
- Логи сервера — логи, отвечающие за обращения к серверу и за возникшие ошибки.
- Логи баз данных — специальные логи, которые имеют отношение к запросам баз данным и возникших ошибках.
- Логи почты отвечают за отправленные и принятые письма, ошибки и причины по которым письма не были доставлены.
- Логи cron (планировщика задач).
- Логи панели управления хостингом, где размещен сайт.
- Лог основного файла, например, фаервола, днс сервера и др.
Использование log-файлов для отладки работы web-сайтов
Web-сервер Apache (также и Nginx) создают файл, который может называться просто error.log (error_log). В случае большого количества web-сайтов на сервере он будет иметь вид .error.log.
Если, например, конкретный web-сайт показывает в браузере ошибку 500, то можно зайти в этот файл и посмотреть, что именно происходит на сервере.
Пример: просмотр лог-файла ошибок web-сервера из панели провайдера Beget через файл-менеджер
После открытия log-файла пользователь видит, что в исходном коде скрипта PHP допущена ошибка, которую надо исправить.
При работе с лог-файлами web-сервера на виртуальном сервере необходимо знать, в каком каталоге находятся log-файлы для того или иного сайта. Это зависит от установленного на сервере программного обеспечения, в частности, — от конкретной панели управления.
Например, если пользователь применяет панель VestaCP на своем виртуальном сервере, то для просмотра лог-файлов для сайта ему необходимо в командной строке сервера зайти в каталог /home/admin/web//logs.
Пример: содержимое рабочего каталога панели VestaCP. Виден каталог logs, в котором хранятся log-файлы
Там он обнаружит нужные log-файлы, конкретно — .error.log.
Последние строки лог-файла будут содержать сообщение об ошибке, например:
- проблему с файлом .htaccess;
- ошибку подключения к серверу базы данных;
- ошибку языка PHP.
Пример: просмотр сообщения об ошибках в файлах error.log с помощью команды tail: В этом конкретном примере пользователь видит в записях log-файла, что происходит ошибка интерпретатора PHP при обращении к базе данных MySQL.
Как читать логи
Логи в панели управления хостингом представлены в удобном виде в виде таблиц. Например, лог FTP-сервера на хостинге содержит колонки:
- дата;
- IP, с которого подключались;
- логин пользователя;
- действия пользователя.
Логи сервера на жестком диске представляют собой текстовые файлы, в которых в хронологическом порядке записывается информация. Открыть их можно любым текстовым редактором, предпочтительно специализированным, например, Notepad+++. Данные представлены в виде строк с разделителями и на первый взгляд часто выглядят как непонятное смешение символов.
Для удобного чтения можно скачать логи и просмотреть их через специальные программы: Analog, Weblog Expert и другие.
Логи сервера Windows более структурированы и понятны для изучения. В них есть несколько уровней событий: ошибка, предупреждение, информация, подробные сведения. Отдельно выделяются критические события.
Почему логирование нужно каждой компании
Логирование — еще один способ эффективно контролировать состояние инфраструктуры. В ITGLOBAL.COM оно входит в пакет услуг Managed IT. Вместе с сервисами мониторинга логирование существенно экономит время инженеров при расследовании тех или иных инцидентов. А главное, с помощью анализа логов можно предотвратить инциденты в будущем.
Компании, которые используют логирование в рамках услуги Managed IT, уменьшают общее количество инцидентов и получают принципиально другой уровень контроля над инфраструктурой.
Также сервис удобен для разработчиков, которые с помощью простых интерфейсов могут в режиме реального времени отслеживать работу своих приложений.