Где почитать логи службы сервера 1с

Записки IT специалиста

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

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Что такое технологический журнал? Это собственный формат логов 1С собирающий всю информацию о работе установленных на данном ПК приложениях 1С:Предприятие. По умолчанию технологический журнал настроен на сохранение минимальных дампов, возникающих при аварийном завершении программы.

Однако, давайте честно, многие из читающих данную статью имеют знания и опыт чтобы работать с дампами? А те, кто все-таки умеют это делать, будут этим заниматься? Нет, так как практического смысла в этом немного. Процитирую В. Гилева:

В дампах могут разобраться только разработчики платформы! (только у них исходники 🙂 )

Поэтому сразу забываем о дампах и сосредотачиваемся на гораздо более простых и понятных вещах — логах. Для чтения логов не нужно иметь специфических знаний, достаточно просто инженерного опыта и общих представлений о работе операционной системы и непосредственно 1С:Предприятия.

Платформа Windows

Для включения и настройки технологического журнала в среде Windows необходимо в папке C:\Program Files (x86)\1cv8\conf создать специальный файл настроек logcfg.xml. В самом простейшем случае он может выглядеть так:

Разберем структуру файла подробнее:

log location — расположение файлов лога, указанная директория должна существовать, и пользователь от имени которого запускается 1С должен иметь право записи в нее.
history — время хранения логов в часах, в нашем примере 168 часов равно 7 суткам или неделе.
event — таких секций может быть много, соответствуют фиксируемым событиям. В данном случае фиксируются все события.
property — определяет попадание в журнал свойств событий. Конструкция property name=»all» включает записи в журнал всех свойств событий.

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

Внимание! 1С категорически не рекомендует включать подобный тип журнала на рабочих серверах!

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

В данном примере фиксируются следующие события:

PROC — события, относящиеся к процессу целиком и влияющие на дальнейшую работоспособность процесса. Например, старт, завершение, аварийное завершение и т.п.
SCOM — события создания или удаления серверного контекста, обычно связанного с информационной базой.
CONN — установка или разрыв клиентского соединения с сервером.
EXCP — исключительные ситуации приложений системы 1С:Предприятие, которые штатно не обрабатываются и могут послужить причиной аварийного завершения серверного процесса или подсоединенного к нему клиентского процесса.
ADMIN — управляющие воздействия администратора кластера серверов системы 1С:Предприятие.
QERR — события, связанные с обнаружением ошибок компиляции запроса или ограничения на уровне записей и полей базы данных.

Этого набора вполне хватает, для разбора ошибок в повседневной деятельности администратора. С полным перечнем настроек технологического журнала с пояснениями и примерами можно ознакомиться в разделе 3.17 Руководства администратора (та самая толстая желтая книжка, которую никто не читает).

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

Это позволит фиксировать события обращения к ключам защиты в том виде, в котором они фиксируются системой защиты HASP, в то время как 1С подменяет их своими сообщениями, типа «ключ защиты не обнаружен», обладающими крайне низкой информативностью.

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

Для каждого процесса создается отдельная папка с его именем и ID, каждая из которых содержит внутри текстовые файлы с именем формата ггммддчч, т.е. год-месяц-день-час, каждый час создается новый файл лога. Так, например, лог за 12 января 2016 года с 15 до 16 часов будет иметь имя 16011215.log, затем 16011216.log и т.д.

Для примера приведем участок лога:

25:25.282004-0,EXCP,0,process=ragent,Exception=81029657-3fe6-4cd6-80c0-36de78fe6657,Descr='src\ServerAgentImpl.cpp(697):
81029657-3fe6-4cd6-80c0-36de78fe6657: server_addr=W81-TEST descr=11001(0x00002AF9): Этот хост неизвестен. line=1102 file=src\DataExchangeCommon.cpp'
25:35.876000-0,EXCP,1,process=ragent,ClientID=0,Exception=NetDataExchangeException,Descr='server_addr=W81-TEST descr=11001(0x00002AF9): Этот хост неизвестен. line=1102 file=src\DataExchangeCommon.cpp'

Сразу видно, что система не может разрешить имя сервера W81-TEST, возможно из-за проблем в DNS. Как видим, логи вполне читабельны и понятны, что позволяет осмысленно подходить к разбору ошибок, особенно в тех случаях, когда явного сообщения об ошибке не выводится, скажем не стартует процесс сервера.

Платформа Linux

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

Прежде всего расположение файла настроек. Он должен находиться в /home/usr1cv8/.1cv8/1C/1cv8/conf, по умолчанию данная директория не существует и ее нужно будет создать. Также, если вы предпочитаете графические инструменты настройки, учтите, что директория .1cv8 скрытая (на это указывает точка в начале имени) и просто так в файловом менеджере вы ее не увидите.

Мы предпочитаем работу в консоли, как более привычную и удобную для данной платформы. Поэтому создадим данную директорию:

mkdir /home/usr1cv8/.1cv8/1C/1cv8/conf

а в ней файл настроек:

touch /home/usr1cv8/.1cv8/1C/1cv8/conf/logcfg.xml

После чего можно приступать к его редактированию, содержимое должно быть полностью идентичным Windows-версии, за исключением пути хранения логов. В файловой системе Linux они традиционно располагаются в /var/log и мы не рекомендуем отступать от традиций, потому, что если с данным сервером придется работать другому специалисту, то он будет искать логи именно там.

Изменим строку конфигурационного файла logcfg.xml следующим образом:

Затем создадим папку для логов 1С

mkdir /var/log/1C

А чтобы 1С могла писать туда, установим пользователя и группу 1С владельцем этого каталога:

chown usr1cv8:grp1cv8 /var/log/1C

Теперь перезапускаем процесс сервера 1С

service srv1cv83 restart

и отмечаем создание в директории папок и файлов с логами.

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

Так как клиентская платформа работает от имени запустившего его пользователя, то файлы настройки платформы хранятся в домашнем каталоге этого пользователя. Если таких пользователей несколько, то у каждого из них будет свой вариант настроек. Структура каталогов при этом полностью повторяет серверную, что не удивительно, в случае с сервером настройки хранятся в каталоге служебного пользователя от имени которого работает сервер 1С.

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

Попытка использовать для записи логов эту папку не приведет к успеху, папки процессов будут создаваться, но логи появляться не будут. Можно, конечно, перенастроить место хранения логов на любую папку в домашней директории, но лучше продолжить использовать для этого /var/log/1C.

Чтобы запущенное от имени пользователя приложение могло писать в данную папку надо предоставить ему соответствующие права. Если вы единственный пользователь компьютера и серверной версии 1С у вас не установлено, то можно просто сделать текущего пользователя владельцем данной папки, если пользователей несколько, либо на этом же ПК стоит серверная часть и вы хотите включить журнал и для нее, то нужно настроить совместный доступ.

Прежде всего добавим нужных пользователей в группу 1С:

usermod -a -G grp1cv8 andrey

Затем изменим права на папку логов, чтобы писать в нее мог не только владелец, но и группа:

chmod 775 /var/log/1C

Для применения прав нужно завершить сеанс пользователя и войти заново, после этого можно запустить клиентское приложение и убедиться, что в каталоге /var/log/1C создаются нужные папки логов.

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Работа с логами (журналами) сервера

Как правило, в 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 вы не обнаружите, скорее всего, он все равно ведется, но уже в системных логах, упомянутых выше, это:

Также некоторые 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, то лог ведется по следующему пути:

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

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

Для сайтов, имеющих активную посещаемость или большое количество уведомлений и ошибок 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 имя.лога | 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, по большей части, все создается единообразно, разобравшись с базовыми элементами и основными логами, вам не составит труда в будущем найти и поработать с логами каких-либо других служб, установленных на сервер.

Администрирование сервера 1С под Linux

Правильное название группы и пользователя можно увидеть:

cat /etc/group | grep 1c

Список запущенных процессов сервера

pstree -a usr1cv8, при это процессы сворачиваются

или в несвернутом виде с выводом pid

pstree -a -p usr1cv8

или альтернативный вариант:

ps -ef | grep usr1cv8

Где искать логи, если сервер 1C не запускается

Все основные логи расположены в /var/log

Просмотреть события, связанные с процессом srv1cv83

less /var/log/syslog | grep srv1cv83 (вместо syslog может быть syslog.1, syslog.2 и т.д.)

cat /var/log/syslog | grep srv1cv83

Логи сервера

Что такое logs server или логи сервера? Это текстовые файлы, в которых протоколируется информация о всех событиях на сервере. Log server переводится как «журнал сервера». Запись информации проводится автоматически.

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

Виды логов

Существует несколько типов логов сервера:

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

Каждое ПО часто ведет свои собственные логи. Так, на сервере хостинга отдельно протоколируются события:

операционной системы сервера;
главных компонентов системы (работа DNS, Firewall);
базы данных (SQL-сервера);
FTP-сервера;
веб-сервера;
панели управления хостингом (хронология использования ресурсов хостинга, авторизации);
доменной почты (почтовые логи) и других программ.

Где можно найти логи сервера

Посмотреть логи сервера можно:

непосредственно в каталоге на жёстком диске, где они лежат. Доступ ко всем логам есть только на виртуальном или выделенном сервере. Если у вас виртуальный хостинг, доступ будет только к тем логам, которые находятся непосредственно в вашем каталоге;
из панели хостинга;
на FTP-сервере;
запросив логи у техподдержки хостинг-провайдера.

Что касается панели хостинга, то здесь логи часто размещают прямо в веб-интерфейсе панели, в разделах с аналогичным названием: «лог FTP-сервера», «лог ошибок сайта». Точное расположение разделов можно посмотреть в справке или уточнить у техподдержки.

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

папка с логами называется logs или log;
файл с логами содержит в названии log (access_log, error_log).

Зачем нужно смотреть логи?

Часто о логах никто не вспоминает, пока не появляются проблемы: сайт тормозит, сайт взломали. Правильнее смотреть логи сервера регулярно. Тем более, многие хостеры хранят некоторые виды логов непродолжительное время: 2 недели, месяц, 3 месяца.

Просматривая логи, можно увидеть:

попытки взлома сайта, внедрения вредоносного ПО;
рост нагрузки на сервер с определенных IP-адресов;
превышение допустимой нагрузки на сервер и другие предвестники проблем.

Обнаружив начинающиеся проблемы заранее, можно предпринять соответствующие меры: заблокировать зловредные IP-адреса, оптимизировать SQL-запросы, перейти на тариф с большим количеством ресурсов.

Как читать логи

Логи в панели управления хостингом представлены в удобном виде в виде таблиц. Например, лог FTP-сервера на хостинге содержит колонки:

дата;
IP, с которого подключались;
логин пользователя;
действия пользователя.

Логи сервера на жестком диске представляют собой текстовые файлы, в которых в хронологическом порядке записывается информация. Открыть их можно любым текстовым редактором, предпочтительно специализированным, например, Notepad+++. Данные представлены в виде строк с разделителями и на первый взгляд часто выглядят как непонятное смешение символов.

Для удобного чтения можно скачать логи и просмотреть их через специальные программы: Analog, Weblog Expert и другие.

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

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

Пользователям, арендующим VPS-сервер, для доступа к логам можно:

подключиться к серверу по SSH;
по очереди ввести команды cd logs, ls —all;
вы увидите список лог-файлов в папке logs — открывайте нужный и смотрите.

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

Расскажем, как найти логи сервера в разных типах панели управления хостингом. Будем искать файлы логов, а не их представление в веб-интерфейсе панели.

В ISPmanager

В Менеджере файлов зайдите в папку logs, найдите и скачайте нужный файл. Просматривайте логи на своем ПК или ноуте.

В CPanel

Аналогично описанному выше, только внутренний файл-менеджер называется «Диспетчер файлов».

В Plesk

Здесь, чтобы зайти в папку logs и загрузить на свой ПК логи, вам нужно войти на вкладку «Файлы».