запись логов в файл что это вк

Что как снять логи на Android?

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

Для чего нужны логи? Чаще всего логи нужны для того, чтобы понять причину падения приложений. Нередко случается так, что одно и то же падение может быть вызвано разными факторами и действиями. Есть несколько способов снять лог-файлы.

Способы снять логи для VK

1 способ. Через «Звонилку»

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

5. Закройте приложение, убрав его из недавно открытых.

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

Нередко встречаются случаи, когда 1 способ может не работать. С таким могут столкнуться пользователи Samsung, поэтому следующий способ для них.

2 способ. Через Debug в меню

3. Перезапустите клиент.

4. Откройте настройки вашего профиля.

5. Нажмите на появившийся пункт «Debug».

6. Далее поставьте галку на «Логирование API».

7. Далее нажмите на «Запись логов в файл».

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

9. Закройте приложение, убрав его из недавно открытых.

10. Далее действуйте по той же инструкции.

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

Способы снять логи как для VK, так и для VK Me

1 способ. С помощью Android SDK Platform Tools

Если вы разбираетесь в Android SDK Platform Tools, то вы можете воспользоваться следующей командой:

2 способ. С помощью ADB Logcat

Первое, что нужно сделать, — установить драйверы для утилиты adb:

4. Запустите процесс установки, для этого нажмите Y и Enter при появлении каждого запроса в окне.

Источник

О том, как ВКонтакте собирает информацию о нас

Сегодня, ковыряя отснифеный трафик официального приложения ВКонтакте под Android, пытаясь найти особенности, по которым API отсеивает официальные приложения для получения музыки, я наткнулся на запросы довольно интересного содержания.

Автор: Владислав Велюга (vlad805)

Disclaimer

Update 6

А еще давайте сразу, вот что ответил (где-то) Андрей Рогозов про данную информацию.

Предисловие

Результаты

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

Довольно часто промелькивали запросы к некоему сервису vigo.ru. Сервис позиционирует себя как аналитика в передаче, поиска ошибок, проблем и обработке видео. Но странно, ведь я всего лишь авторизовался, перешел в аудио и пролистал свою стену, где не было ни единого видеоролика (которые должны были автоматически проигрываться?), а запросов скопилось около 5-7 штук. Помимо notify еще был network_status.

Приложение делает бенчмарки и зачем-то передает время запроса к API и время загрузки изображений. Видимо, усредненные данные.

Чуток не негатива: приложение отправляет сообщения об ошибках, если, например, была попытка загрузить изображение (например, оно было прикреплено к посту), но произошла какая-то ошибка. На скрине предоставлен пример, когда изображение просто отсутствовало на сервере (ошибка 404 Not Found). upd: хотя вот попался момент, когда state=success и никаких других «опознавательных знаков» не было.

С видеозаписями обстоят дела еще хуже. Здесь передается информация о таких событиях как «volume_on», «volume_off» (видимо, включение/выключение звука, но это неточно), «fullscreen_on», «fullscreen_off» (переход и выход в/из полноэкранного режима), событие «video_play», которое просто отсылает текущую позицию просмотра видео, где-то с периодичностью 10-20 секунд. upd: хотя вот Андрей подсказал идею, для чего это сделано: для того, чтобы запоминалось место, на котором пользователь остановился при просмотре видео, чтобы он мог переключиться с мобильного на ПК и на ПК продолжить смотреть с места, где был в последний раз на мобильном.

При закрытии страницы (активити) с видео, приложение запрашивает метод video.viewSegments, в параметрах которого передаются рейнжы (отрезки) таймкода, которые были просмотрены пользователем.

В Kate Mobile таких сливов замечено не было. Единственное, после ввода в эксплуатацию нового алгоритма выдачи аудиозаписей, и Kate, и официальному приложению нужно обращаться к Google Accounts для получения некого receipt-токена. И всё.

О том, как работают приложения на iOS, Windows Phone мне только можно догадываться. Их пакеты не перехватывал, и устройств не имею.

Повторюсь, такие данные, как ближайшие точки доступа Wi-Fi, текущее местоположение пользователя, а также все его действия не отправляются сторонними приложениями, такими как Kate Mobile, VK Coffee (модификация официального, с вырезанными метриками и пр.), моим сайтом-клиентом APIdog и пр.

Update 2

Друг-разработчик Андрей добавил ещё скринов того, что сливается официальным приложением под Android.

Название точки доступа, к которой подключено устройство, а также другие, которые находятся в зоне досигаемости, их сигнал в dB, MAC-адреса.

Плюсом от него же, вот что отправляет официальное приложение для Windows

Только версию системы, версию приложения, метод ввода.

Update 3

Эдуард Безменов, разработчик модификации официального приложения VK Coffee, прокомментировал этот пост так:

Update 4

Григорий Клюшников, бывший разработчик этого самого приложения, как оказывается, был сам против включения сервисов Vigo в приложение:

А вот, что на самом деле представляет Vigo по описанию Григория:

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

Update 5: Ответы от ВКонтакте

Мобильная техподдерка

Денис решил всё-таки добиться ответов на наши вопросы и задал их мобильной поддержке ВК (id333)

Оказывается, Ваше местоположение, данные для таргетинговой рекламы, список установленных приложений и сети Wi-Fi жизненно необходимы для приложения и сайта в целом.

В ответ на последний вопрос, поддержка решила отойти от темы.

О том, как это было получено

Подручные средства

Подготовка: создание сертификата SSL

В phrase key вводим что-то типа пароля. Он нам еще понадобится. Затем его еще раз повторить. Остальные поля можно оставить пустыми/не вводить. По окончанию в текущей директории будет создано два файла.

Подготовка: установка нашего сертификата на устройство

Передаем файл cert.pem на устройство и устанавливаем его в систему. Обращу внимание, что для установки сертификата необходимо, чтобы на телефоне был какая-нибудь защита на экране блокировки (графический ключ, пароль или PIN).

Пошаговая установка сертификата на Android 5.1

Подготовка: переброс портов

Возвращаемся на Linux, вбиваем в терминал:

Подготовка: Ettercap

После установки его запускаем.

Снифинг данных

Конец подготовки: SSLSplit

Далее в терминале ставим sslsplit:

Когда установка завершена, создаем директории:

И в текущей директории (где лежат файлы cert.pem и key.pem)

Выходим из аккаунта в приложении на телефоне.

В текущей директории выполняем:

Вводим phrase key, который указывали при создании сертификата.

В logfile.log будут записываться неполные логи (именно домен, адрес, порт), в директорию logs будут записываться подробные запросы, заголовки и ответы.

Далее авторизуемся в приложении и видим, как в терминале, в logfile.log и в директории logs появляются данные. Для остановки снифинга жмем в терминале Ctrl+C.

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

Далее можно просматривать файлы с помощью обычного текстового редактора.

Update

Как позже подсказал Антон, снифинг можно выполнить двумя кликами с помощью приложений для Android, и тогда вот эта длиннющая инструкция не понадобится. Но. кому как удобнее.

Благодарности

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

Источник

Использование ClickHouse в VK, или Зачем мы написали KittenHouse

В начале года мы решили научиться хранить и читать отладочные логи ВКонтакте более эффективно, чем раньше. Отладочные логи — это, к примеру, логи конвертации видео (в основном вывод команды ffmpeg и список шагов по предварительной обработке файлов), которые иногда бывают нам нужны лишь спустя 2-3 месяца после обработки проблемного файла.

На тот момент у нас было 2 способа хранения и обработки логов — наш собственный logs engine и rsyslog, которые мы использовали параллельно. Стали рассматривать другие варианты и поняли, что нам вполне подходит ClickHouse от Яндекса — решили его внедрять.

В этой статье я расскажу о том, как мы начали использовать ClickHouse ВКонтакте, на какие грабли при этом наступили, и что такое KittenHouse и LightHouse. Оба продукта выложены в open-source, ссылки в конце статьи.

Задача сбора логов

Требования к системе:

Возможные решения

Давайте вкратце перечислим варианты, которые мы рассматривали, и их минусы:

Logs Engine

– Умеет отдавать только последние N строк, которые помещаются в RAM.
– Не очень компактное хранение (нет прозрачного сжатия).

Hadoop

– Не во всех форматах есть индексы.
– Скорость чтения могла быть и выше (зависит от формата).
– Сложность настройки.
– Нет возможности вставки с десятков тысяч серверов (нужна Kafka или аналоги).

Rsyslog + файлы

– Нет индексов.
– Низкая скорость чтения (обычный grep/zgrep).
– Архитектурно не поддерживаются строки >4 Кб, по UDP ещё меньше (1,5 Кб).
± Компактное хранение достигается путем logrotate по крону

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

LSD + файлы

– Нет индексов.
– Низкая скорость чтения (обычный grep/zgrep).
– Не особо расчитан на вставку с десятков тысяч серверов.
± Компактное хранение достигается путем logrotate по крону.

Отличия от rsyslog в нашем случае в том, что LSD поддерживает длинные строки, но для вставки с десятков тысяч серверов требуются существенные доработки внутреннего протокола, хотя это и можно сделать.

ElasticSearch

– Проблемы с эксплуатацией.
– Нестабильная запись.
– Нет UDP.
– Плохое сжатие.

ELK стек является уже почти промышленным стандартом для хранения логов. По нашему опыту — всё хорошо со скоростью чтения, а вот с записью бывают проблемы, например, во время слияния индексов.

ElasticSearch прежде всего предназначен для полнотекстового поиска и относительно частых запросов на чтение. Нам же важнее стабильная запись и возможность более-менее быстро прочитать наши данные, причём по точному совпадению. Индекс у ElasticSearch заточен под полнотекстовый поиск, и занимаемый объём на диске довольно велик по сравнению с gzip оригинального содержимого.

ClickHouse

По большому счёту, единственное, что нас не устраивало в ClickHouse — отсутствие общения по UDP. По факту, из перечисленных вариантов оно было только у rsyslog, но при этом rsyslog не поддерживал длинные строки.

По остальным критериям ClickHouse нам подошел, и мы решили использовать его, а проблемы с транспортом решить в процессе.

Зачем нужен KittenHouse

Как Вы, наверное, знаете, ВКонтакте работает на PHP/KPHP, с «движками» (микросервисами) на C/C++ и немножко на Go. У PHP нет концепции «состояния» между запросами, кроме, возможно, общей памяти и открытых соединений.

Поскольку у нас десятки тысяч серверов, с которых мы хотим иметь возможность отправлять логи в ClickHouse, держать открытым соединения из каждого PHP-worker’а было бы накладно (на каждый сервер может приходиться по 100+ воркеров). Поэтому нам нужен какой-то прокси между ClickHouse и PHP. Мы назвали этот прокси KittenHouse.

KittenHouse, v1

Сначала решили попробовать как можно более простую схему, чтобы понять, будет наш подход работать или нет. Если Вам на ум при решении этой задачи приходит Kafka, то Вы не одиноки. Мы, однако, не хотели использовать дополнительные промежуточные сервера — в этом случае можно было легко упереться в производительность этих серверов, а не самого ClickHouse. К тому же, мы собирали логи и нам нужна была предсказуемая и небольшая задержка вставки данных. Схема выглядит следующим образом:

На каждом из серверов ставится наш локальный прокси (kittenhouse), и каждый инстанс держит строго одно HTTP-соединение с нужным ClickHouse-сервером. Вставка осуществляется в буферные таблицы, поскольку в MergeTree часто вставлять не рекомендуется.

Возможности KittenHouse, v1

Первая версия KittenHouse умела довольно мало, однако для тестов этого было достаточно:

Первые проблемы

С первой проблемой мы столкнулись, когда «погасили» ClickHouse сервер на несколько часов и потом включили обратно. Ниже можно видеть load average на сервере после того, как он «поднялся»:

Объясняется это довольно просто: у ClickHouse модель работы по сети — thread per connection, поэтому при попытке сделать INSERT с тысячи узлов одновременно, началась очень сильная конкуренция за ресурсы CPU и сервер еле отвечал. Тем не менее, все данные в конечном счёте вставились и ничего не упало.

Для решения этой проблемы мы поставили nginx перед ClickHouse и, в целом, это помогло.

Дальнейшее развитие

В процессе эксплуатации столкнулись ещё с некоторым количеством проблем, в основном связанных не с ClickHouse, а с нашим способом его эксплуатации. Вот ещё грабли, на которые мы наступили:

Большое количество «кусков» у Buffer таблиц приводит к частым сбросам буфера в MergeTree

В нашем случае было 16 кусков буфера и интервал сброса раз в 2 секунды, а таблиц 20 штук, что давало до 160 вставок в секунду. Это периодически очень плохо сказывалось на производительности вставки — появлялось много фоновых слияний и утилизация дисков достигала 80% и выше.

Решение: увеличили интервал сброса буфера по умолчанию, уменьшили число кусков до 2.

Nginx отдает 502, когда заканчиваются соединения с upstream

Само по себе это не является проблемой, но в сочетании с частым сбросом буфера это давало достаточно высокий фон 502 ошибок при попытке вставки в любую из таблиц, а также при попытке выполнить SELECT.

Решение: написали свою reverse proxy с использованием библиотеки fasthttp, которая группирует вставку по таблицам и очень экономно расходует соединения. Также она различает SELECT и INSERT и имеет раздельные пулы соединений для вставки и для чтения.

Начала заканчиваться память при интенсивной вставке

У библиотеки fasthttp есть свои достоинства и недостатки. Один из недостатков — то, что запрос и ответ полностью буферизуются в памяти перед тем, как отдать управление обработчику запроса. У нас это выливалось в то, что если вставка в ClickHouse «не успевала», то буферы начинали расти и в конечном итоге заканчивалась вся память на сервере, что приводило к убийству reverse proxy по OOM. Коллеги нарисовали демотиватор:

Решение: патчинг fasthttp для поддержки стриминга тела POST-запроса оказался непростой задачей, поэтому решили использовать Hijack() соединения и апгрейдить соединение на свой протокол, если пришел запрос с HTTP-методом KITTEN. Поскольку сервер должен ответить MEOW в ответ, если понимает этот протокол, вся схема называется протоколом KITTEN/MEOW.

Мы читаем только из 50 случайных соединений одновременно, поэтому, благодаря TCP/IP, остальные клиенты «ждут» и мы не расходуем память на буферы, пока до соответствующих клиентов не дошла очередь. Это сократило потребление памяти минимум в 20 раз, и больше подобных проблем у нас не было.

ALTER таблиц может идти долго, если есть долгие запросы

У ClickHouse неблокирующий ALTER — в том смысле, что он не мешает выполняться как SELECT-запросам, так и INSERT-запросам. Но ALTER не может начаться, пока не закончили исполняться запросы в эту таблицу, отправленные до ALTER.

Если у вас на сервере есть фон «долгих» запросов в какие-нибудь таблицы, то вы можете столкнуться с ситуацией, что ALTER на эту таблицу не будет успевать выполняться за дефолтный таймаут в 60 секунд. Но это не значит, что ALTER не пройдет: он выполнится, как только закончат выполняться те самые SELECT-запросы.

Это означает, что вы не знаете, в какой на самом деле момент времени произошел ALTER, и у вас нет возможности автоматически пересоздать Buffer-таблицы, чтобы их схема всегда была одинаковой. Это может приводить к проблемам при вставке.

Решение: Планируем в итоге полностью отказаться от использования буферных таблиц. В целом, у буферных таблиц есть сфера применения, мы пока используем их и не испытываем огромных проблем. Но сейчас мы наконец дошли до момента, когда проще реализовать функциональность буферных таблиц на стороне reverse proxy, чем продолжать мириться с их недостатками. Примерная схема будет выглядеть вот так (пунктирной линией показана асинхронность ACK на INSERT).

Чтение данных

Допустим, мы разобрались со вставкой. Как читать эти логи из ClickHouse? К нашему сожалению, удобных и простых в эксплуатации инструментов для чтения сырых данных (без построения графиков и прочего) из ClickHouse мы не нашли, поэтому написали своё решение — LightHouse. Его возможности довольно скромные:

Просмотр структуры таблицы

Результаты

ClickHouse — практически единственная open-source база данных, которая «прижилась» ВКонтакте. Мы довольны скоростью её работы и готовы мириться с недостатками, о которых ниже.

Сложности в работе

В целом, ClickHouse — очень стабильная база данных и очень быстрая. Однако, как и с любым продуктом, особенно таким молодым, есть особенности в работе, которые нужно учитывать:

Open-source

KittenHouse и LightHouse теперь доступны в open-source в нашем github-репозитории:

Юрий Насретдинов, разработчик в отделе backend-инфраструктуры ВКонтакте

Источник

Какие виды лог-файлов бывают

Вебмастерам нужно получать информацию о том, как работает их сайт и сервер. Это можно узнать из log-файлов.

На виртуальном хостинге владельцы сайтов работают с логами web-сервера, доступ к которым предоставляет провайдер.
На VPS/VDS и выделенных серверах можно работать с самыми разнообразными логами, которые записывают все работающие на сервере службы.

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

На платформе Windows также имеется служба журналирования событий, но там информация записывается не в текстовые файлы, а в журналы специального формата, доступ к информации которых возможен через службу Event Viewer.

Log-файлы и виртуальный хостинг

Провайдер хостинга обеспечивает доступ к лог-файлам web-сервера через панель управления. Например, у провайдера Beget это выглядит так.

Также доступ к лог-файлам конкретного сайта можно получить через файл-менеджер (или по протоколу FTP).

У провайдера Beget в менеджере файлов их можно найти здесь.

При использовании популярной панели ISPmanager log-файлы доступны пользователю и располагаются в каталоге /log. Для каждого из сайтов присутствуют два лог-файла:

Виды лог-файлов

Все программы и сервисы Linux ведут log-файлы.

Log-файлы на сервере хранятся в специальном каталоге /var/log, внутри которого создаются отдельные файлы и папки для того или иного сервиса.

Различие в хранении log-файлов по версиям Linux

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

Конкретная версия операционной системы для VPS/VDS выбирается у провайдера в личном кабинете пользователя перед заказом виртуального сервера.

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

Системные log-файлы

Опишем наиболее важные системные лог-файлы, хранящиеся в каталоге /var/log.

1. Общий системный журнал, в зависимости от версии Linux, записывается в файлы /var/log/syslog (Debian) или /var/log/messages (Redhat). В него пишется информация, начиная от старта системы:

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

3. /var/log/dmesg и /var/log/kern.log— сообщения ядра и драйверов устройств.

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

Как правило, сайты на сервере работают под управлением web-сервера Apache или Nginx. Также их можно применять на сервере вместе, что позволит использовать сильные стороны каждой программы.

Также к логам веб-сервера относятся лог-файлы интерпретатора PHP (php-fpm) и файлы ошибок PHP.

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

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

Для удобства эти файлы могут создаваться по отдельности для каждого сайта, размещенного на сервере. Тогда они имеют названия “domain.name_access.log” и “domain.name_error.log”.

На Linux-системах семейства Debian логи Apache хранятся в каталоге /var/log/apache2, для систем, основанных на RedHat в /var/log/httpd.

Для чтения информации из log-файла можно использовать команду “cat имя-лог-файла” или “tail имя-log-файла”.

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

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

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

Пример: вывод командой “ls *.log” списка log-файлов web-сервера nginx в папке /var/log/nginx/domains (на снимке экрана видно, что там хранятся файлы сразу нескольких сайтов)

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

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

Ротация log-файлов

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

Как это работает?
1. Данные о посетителях (или ошибках) сайта записываются в файл с обычным названием, например, access.log.
2. Раз в сутки (обычно в ночное время) этот файл автоматически переименовывается в “access.log.1” и сжимается архиватором Gzip.
3. Имя файла становится вида “access.log1.gz”.
4. Вместо этого файла web-сервер начинает записывать информацию в новый файл access.log.
5. Еще через сутки архивный файл “access.log.1.gz” переименовывается в “access.log.2.gz”, и вместо него создается новый архив “access.log.1.gz” из текущего log-файла web-сервера и так далее.

Всего на сервере хранятся сжатые log-файлы за последний месяц.

Пример: на снимке экрана виден список log-файлов web-сервера. Среди них присутствуют как текущие файлы access.log и error.log за сегодняшний день, так и файлы за предыдущие дни access.log.1, error.log.1 и так далее.

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

Log-файлы почтовой системы

Log-файлы FTP-сервера

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

Log-файлы сервера базы данных

Популярный сервер базы данных MySQL также ведет log-файл “mysqld.log”. Он располагается в папке /var/log/mysql или /var/log/mariadb, в зависимости от используемой версии MySQL.

Также сервер MySQL может создавать в этой папке файл отладки медленных запросов к базе данных. Обычно он называется “mysql_slow.log”.

Пример: содержимое файла медленных запросов MySQL. Вывод содержимого log-файла командой “tail mysql_slow.log”

Использование log-файлов для отладки работы web-сайтов

Web-сервер Apache (также и Nginx) создают файл, который может называться просто error.log (error_log). В случае большого количества web-сайтов на сервере он будет иметь вид domain.ru.error.log.

Если, например, конкретный web-сайт показывает в браузере ошибку 500, то можно зайти в этот файл и посмотреть, что именно происходит на сервере.

Пример: просмотр лог-файла ошибок web-сервера из панели провайдера Beget через файл-менеджер

После открытия log-файла пользователь видит, что в исходном коде скрипта PHP допущена ошибка, которую надо исправить.

Например, если пользователь применяет панель VestaCP на своем виртуальном сервере, то для просмотра лог-файлов для сайта mysite.ru ему необходимо в командной строке сервера зайти в каталог /home/admin/web/mysite.ru/logs.

Пример: содержимое рабочего каталога панели VestaCP. Виден каталог logs, в котором хранятся log-файлы

Последние строки лог-файла будут содержать сообщение об ошибке, например:

Пример: просмотр сообщения об ошибках в файлах error.log с помощью команды tail: В этом конкретном примере пользователь видит в записях log-файла, что происходит ошибка интерпретатора PHP при обращении к базе данных MySQL.

Использование log-файлов для аналитики

Любому владельцу сайта нужно знать аудиторию своих посетителей. Эта информация содержится в лог-файлах посещений web-сервера (access.log). Для удобной обработки информации провайдеры хостинга, а также панели управления предлагают такие системы: Webalizer и AWStats.

Пример: аналитика посещений web-сайта с использованием системы AWStats

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

Источник