Помимо стандартной статистики сайта, которая включает в себя количество уникальных посетителей, открытых страниц и еще массу другой полезной информации, веб-мастер должен знать еще множество других вещей о таком сайте, и именно это раскрывают ему логи. При этом начинающие веб-мастера достаточно часто даже не знают, что такое лог и что он дает.
Какая информация еще нужна?
Как говорилось выше, помимо стандартных параметров, владелец сайта должен знать еще массу других данных:
- Какие страницы являются наиболее посещаемыми.
- По каким поисковым запросам пользователи чаще попадают на сайт.
- Какие браузеры или же операционные системы являются наиболее востребованными у посетителей.
- Какое разрешение экрана используют посетители чаще всего.
- И многое другое.
Как это узнать?
В преимущественном большинстве случаев на сайтах устанавливается платный или же бесплатный счетчик, при этом ресурс, который его предоставляет, осуществляет тщательный анализ сайта и ведет статистику посещений, с которой можно в любой момент ознакомиться. Особенно использование таких счетчиков является востребованным в том случае, если человек размещает собственный сайт на бесплатном хостинге. Рассматривая, что такое лог, важно научиться работать и с такими счетчиками, так как, по сути, они включают в себя большинство нужных данных.
Преимущественное большинство хостеров, предоставляющих платный хостинг, изначально дают своим клиентам возможность использовать средства анализа, которые уже установлены в созданный сайт. К примеру, в серверах Apache применяется специализированная утилита под названием Webalizer, которая используется в роли дополнительного модуля сервера.
Те, кто пользуются платными хостингами, могут также полностью самостоятельно обрабатывать все данные касательно своего сайта, так как веб-мастер, который знает, что такое лог сайта и как им пользоваться, имеет полный доступ ко всей нужной информации.
Что это?
На любом сайте ведется собственный лог, в который веб-мастер может заглянуть в любой удобный ему момент. Что такое лог? Это отдельный текстовый файл, в котором находится информация касательно всех запросов к сайту, а также касательно различных ошибок, относящихся к этим запросам.
Как данные записываются в лог?
Первоначально пользователь набирает в собственном браузере адрес определенного сайта и переходит на него. После этого браузер пользователя начинает передавать на сервер, на котором располагается данный сайт, запрос на выдачу интересующей пользователя веб-страницы. Вместе с этим серверу предоставляется следующая информация:
- IP-адрес посетителя.
- Точное время осуществления запроса.
- Браузер, который использует пользователь.
- Операционная система, которую использует пользователь.
- Интересующая его страница.
- Адрес страницы, с которой был осуществлен переход на целевую.
После этого посетителю выдается сервером интересующий его запрос, и вся информация касательно проведенной транзакции оформляется в журнале событий, создавая так называемый лог-файл.
Грамотный анализ логов сайта позволяет веб-мастеру определить, как именно используется его ресурс и в каком направлении его более актуально развивать.
Какую информацию дают логи?
Просматривая логи сайта, можно найти огромнейшее количество полезной информации, которая позволит улучшить дальнейшее продвижение ресурса и сделать его более эффективным:
- Посещаемость. Конечно, такой показатель определяется и стандартным счетчиком, который может присутствовать на каждой странице, но в логе эти данные предоставлены более подробно, включая посещаемость по дням, часам или месяцам. Также посредством использования логов можно определить часы всплеска или же затишья посещаемости, что крайне важно знать, занимаясь обслуживанием сайта.
- Трафик. В данном случае предоставляется как трафик каждой отдельной страницы, так и суммарный трафик сайта за определенный период времени.
- Конверсия. Данный параметр позволяет определить, каким образом посетители перемещаются по вашему ресурсу, то есть они просмотрели одну страницу и закрыли или же все-таки начали «путешествовать» по вашему сайту, просматривая одну страницу за другой. Уровень конверсии позволяет косвенно определить качество работы вашего сайта.
- Заброшенные страницы. Рассматривая, что такое логи сервера, часто можно определить, что в них находятся заброшенные страницы, то есть те, которые посещаются чрезвычайно редко. В такой ситуации веб-мастер должен провести тщательный анализ ситуации, ведь может быть так, что страницы перестали интересовать людей или же их стало трудно найти среди множества других на вашем сайте.
- Популярные страницы. Веб-страницы, которые являются наиболее посещаемыми. Можно применять их в качестве образца в процессе создания других страниц, а в случае необходимости можно также направлять с этих страниц пользователей к каким-либо другим, которые являются заброшенными или менее популярными.
- Поисковые запросы. Помимо всего прочего, в логах сайта присутствует также эффективность тех метатегов, ключевых слов и самих названий веб-страниц, которые были вами использованы и по которым ваш сайт смогли найти те или иные поисковые системы. Соответственно, в логах находятся данные и о том, какой именно поисковик по определенному запросу нашел ваш сайт.
fb.ru
Автор — я 🙂
Лог — это данные с компьютера владельце, который содержит в себе куки, пассы, информацию о железе, айпи, а так же, файлы с рабочего стола.
Приведу пример лога со стиллера AzorUlt.
Вот так выглядит лог. Смысл, примерно одинаковый, с разных стиллеров логи могу выглядеть по разному. Дата, которая указана на логе, является той датой, когда произошла загрузка к вам в панель. Таким образом, при покупке логов, открыв на начальном этапе этот файлик, вы можете понять как срок его давности. Обычно, добросовестные селлеры продают логи давностью максимум 3 недели — месяц. Если же дата совсем старая, то лог считается не качественным.
Главная задача в работе с логом, это его ковыряние. В целом, логи содержат в себе достаточно информации, которая подойдет для различных целей. Тут уже личное дело каждого, кому и счем нравится работать. Можно брать шантажем, вбивами, можно красть чужие акки и после чего просить за них выкуп, можно работать с криптой, с биржами, с холодными кошельками, с акками ебей, амазон и т.д. Кому на что хватит фантазии)
В целом, самое главное в работе с логами, это чтобы система воспринимала нас за своего человека. Я использую простую доступную связку, при работе, а именно Chrome+editthiscoockie+webrtc+vpn+user agent. На данный момент использую Windscribe и Ip Vanish. За частую, айпи не особо много значит для нас, можно использовать любой, главное, чтобы у него не было блеков. На отдельные страны, к примеру, при работе с палкой желательно подстраиваться под зип, либо брать чистый носок)
Основное требование в работе с логами, это не пароли, как думают многие, а наличие куков. Имея куки, ты можешь вытащить максимум.
ЧАСТЬ 1. Где взять логи?
Есть несколько вариантов получения логов. Самый простой, это их покупка. На форумах достаточное количество селлеров, которые продают логи, и разные расценки.
Есть логи и по 20р за штуку, есть и по 20$. Цена лога зависит от его качества, страны, а так же сервисов, которые там внутри. Дороже всего в продаже логи США. За счет того, что там огромное количество банков, а так же paypal аккаунты. Логи, которые стоят по 20р, чаще всего без выборки, и в основном там всяких хлам, по типу соц сетей или игрушек, хотя бывает что везёт и попадаются стоящие вещи.
К примеру, покупая лог с пейпал аккаунтом, важно проверить не только наличие пароля к нему, но и есть ли он в куках. Проверяем обычным поиском в текстовике с куками, по запросу paypal. Если же там есть строчки и не одна, то этот лог считается хорошим.
Вот так выглядит нормальный лог))
Чаще всего, при встраивании куков с такого лога, тот же самый пейпал выдаёт автоматом нужную нам почту, на которой зарегистрирован аккаунт. Потому, что за частую бывает так, что у владельца куча почт, а пароля или же логина к paypal у нас нет. С таким логом, получив хотя бы логин, мы можем попытаться подобрать пароль от аккаунта из тех, что у нас имеется. Так же, плюс такого лога в том, что система Пейпала воспринимает нас за своего человека, за счёт наличия куков и может дать вбить что-либо без предварительной его раскачки.
Что ещё нужно знать о купленном логе, так это то, а не продался ли он в 10 рук. Самая простая проверка, это проверка через почту. Первым делом при проверке, мы встраиваем куки в браузер и топаем на почту владельца.
В случае, с gmail почтой, достаточно просто проверить логирования в ней.
Матаем почту в самый низ и нажимаем кнопочку "Детали".
Нам откроется окошко с последними активностями в почте. Таким образом, можно понять, были ли другие посторонние логирования помимо нашего
Это хороший лог)
По IP и стране, можно понять, что за последние 3 дня, кроме меня и владельца никто не заходил на аккаунт. Так же, можно посмотреть письма в корзине, а то мало ли, кто-то уже пытался его "поломать". Забегая немного вперед, сразу скажу, что владельцу не приходит никаких оповещений о стороннем логировании, всё дело в том, что система приняла нас за своего человека потому, что у нас были куки.
Отлично, теперь имея на руках целый лог с куками, пассами можно начинать работу)
Второй вариант получения логов, это покупка своего стиллера/ботнета с функцией лоадера.
Имея свой собственный стиллер, в целом ты можешь не беспокоится о том, что твой лог уже кто-то расковырял уже до тебя. В чем отличие стиллеров? В их функционале. Стиллеры, которые тырят пассы с Фаерфокса и с Хрома, а так же есть настройка форм-граббера (тырит файлики с рабочего стола), и wallet.dat — это хорошие стиллеры. Хотя, есть и недорогие в продажах, без фаерфокса, а только с Хромом, ну в целом и с этого тоже можно поиметь) Покупая свой собственный стиллер, нужно позаботится о хостинге, бесплатные или дешевые не протянут долго и есть риск после пролива остаться ни с чем, в связи с тем, что твоя панелька просто на просто слетит, его заблочат и ты попрощаешься со своими логами. Поэтому, можно приобрести либо стиллер уже на готовом абузоустойчивым хостингом, таким как Nocturnal, либо же ставить панель на отдельный абузоустойчивый хостинг самому.
Так выглядит панель стиллера AzorUlt
Так выглядит Nocturnal
Так выглядит Arkei
Скрины панелек, не мои, а честно спизженные.)))
Как мы можем увидеть на примере 3-х панелей стиллеров, выглядят они примерно одинаково. Содержание пассов, логов в целом, страны или айпи, валет даты, данные с сс и файлы и т. д.
Как же получить заветные логи в нашу панельку? Есть 2 варината. Купить инсталлы, а точнее установки нашего вируса, либо распространять самому.
При покупке инсталлов, логи мы получаем в ограниченом и указаном изначально количестве. Главное правило — 1000 иснталлов — НЕ РАВНО 1000 ЛОГОВ!!! В целом, важен какой будет отстук, а отстук зависит от многих факторов. От, например, крипта(маскировки), нашего файла, или же от настройки форм-граббера. Если мы хотим застиллить всё подряд, что имеется на рабочем столе, то отстук может составлять 20%, проверено на себе)))
В целом, при покупе 1000 инсталлов, средний отстук это 70-80%, т.е в панельке у нас появится 700-800 логов. Но и это ещё не всё! Часть из них может быть пустая, часть из них может быть только с куками, часть с 1-2 паролями и это абсолютно нормально. В конечном итоге, жирненьких хороших логов может получится около 250-300.
Рассмотрим вариант распространения самому. Можно просто пихать наш закриптованный .exe под видом читов(школологи)))), или же супер-пупер новой программы, для чего-либо.
к получится, что после установки и запуска стиллера, это отобразится в нашей панельке в виде того самого лога.) В дополнение, можно попросить хорошего человека объеденить ваш стиллер с настоящей программой, тогда получится так, что наш .exe не вызовет никаких подозрений и никто не побежит переустанавливать винду)) Распространять, как уже было понятно, можно по различным форумам, на ютубе, на торрентах, в форумах, в вк, в конце концов) Да, этот способ получается практически бесплатным, но трудоёмким, если вы не хотите тратить деньги на инсталлы, или же, у вас их попросту нет, то можно использовать этот вариант.
Что при первом, что при втором варианте итог будет одинаковый — получение логов. Но тут уже многое будет зависеть от качества. Понятное дело, что распространяя в вк, о качестве речи может не идти.
ЧАСТЬ 2. Настройка системы.
Как я уже было написано выше, я использую для работы обычный Хром. Я не работаю с дедиков, не работаю с виртуалки, сферы и прочих радостей. Просто Хром, обычный хром.
- На него, мы устанавливаем расширения Editthiscoockie — это необходимо для встройки куки в браузер.
- Так же, устанавливаем WebRTC
- И User-agent, который подменяет наш браузер, под браузер владельца, если это необходимо
- Ну и конечно же VPN.
Раньше работа была только с Winscribe, но в последние пару месяцев, стало его не хватать, либо нет нужной мне страны, либо есть, но айпи в блэках до невозможности. Потому и в дополнении могу посоветовать использовать так же Ip Vanish. Ip Vanish удобен тем, что у него достаточно большое количество серверов, под любую страну.
После установки всех расширений и подключения к VPN, идём проверять наш IP на
На выходе, должны иметь примерно такую картину.
Далее, как же встроить куки в браузер. Мы находим в логе наш файлик с куками, нажимаем CTRL+A CTRL+C и конвертируем куки в формат Json. У стиллеров AzorUlt в панелях есть встроенный конвертер.
— тут есть скрипт и подробная инструкция о том, как конвертировать куки.
После чего, копируем то, что нам выдал конвертер, идём в наш основной браузер и вставляем куки в нашу "Печеньку".
И всё, куки в браузере, можно начинать шариться
Первым делом, я всегда проверяю почты. Потому, что имея доступ к почте, ты можешь вытащит много чего, даже не имея пассов. В целом, нужно терпение, желание и широкие глаза, чтобы ненароком не пропустить что-нибудь годное.
vlmi.su
Содержание
- 1 Виды логов
- 2 Расположение
- 2.1 CentOS / Fedora
- 2.2 Debian / Ubuntu
Виды логов
Поскольку основное программное обеспечение, установленное на сервере, чаще всего производит запись в системные журналы, то для каждой из таких программ будет свой журнал. В частности, можно выделить такие наиболее распространенные логи:
- основной файл лога (общая информация — данные о действиях с ядром системы, работе FTP-сервисов, DNS-сервера, файервола);
- лог загрузки системы (помогает выполнить отладку системы в случае, если она не загружается, сохраняет основные системные события (например, сбои оборудования));
- логи веб-сервера (данные об обращениях к серверу, информация об ошибках веб-сервера);
- логи сервера баз данных (запросы к базам данных, ошибки сервера);
- логи хостинговой панели, через которую осуществляется управление сайтом на хостинге (попытки входа в панель, обновления лицензии и панели, статистика использования ресурсов сервера);
- логи почтового сервера (записи о всех отправленных и доставленных сообщениях, ошибки почтового сервера, причины отклонения писем);
- логи планировщика задач — cron (протоколирование выполнения задач, ошибок при запуске крона).
Расположение
Месторасположение журналов зависит от программного обеспечения, реализации настроек по умолчанию или пути, заданного администратором. То есть, в зависимости от того, что вы используете (возможно, это виртуальный хостинг, доступный VPS-план или аренда серверов в Европе или США), доступность и расположение логов будут значительно отличаться. Как правило, большая часть логов сервера хранится по пути /var/log/, но некоторые сервисы могут хранить логи в других каталогах. Для удобства всегда можно задать подходящий путь в конфигурационных файлах нужного программного обеспечения. Например, на сервере можно настроить демон syslog/rsyslog, который будет упорядочивать поступающие в него записи о работе сервисов и сохранять их в заданные пользователем файлы логов.
Рассмотрим расположение основных логов для наиболее распространенных дистрибутивов Linux. По умолчанию журналы в Linux хранятся в /var/log.
CentOS / Fedora
Для распространенного веб-сервера Apache файлы журналов называются access.log (журнал доступа к серверу) и error.log (журнал ошибок и уведомлений). Путь по умолчанию для журнала ошибок Apache — /var/log/httpd/error_log.
Логи nginx сохраняются по пути /var/log/nginx. Журнал ошибок MySQL — /var/lib/mysql/$hostname.err, где вместо $hostname указан хостнейм (имя) сервера.
Основной файл лога — /var/log/syslog.
Лог загрузки системы — /var/log/dmesg.
Debian / Ubuntu
По умолчанию логи Apache будут сохраняться по пути /var/log/apache2.
Логи nginx — /var/log/nginx.
Журнал ошибок MySQL — /var/log/mysql/error.log.
Основной файл лога — /var/log/syslog.
Лог загрузки системы — /var/log/dmesg.
Вам нужно купить Wildcard SSL-сертификат? У нас вы найдете лучшие предложения от Центров сертификации Comodo, GeoTrust и Symantec.
hostiq.ua
Что такое логи?
Для чего нужны логи?
Обычно при нормально работающем сайте лог-файлами мало кто интересуется, но когда начинает расти нагрузка на сервер, начинается рассылка спама, и вообще сайт начинает вести себя довольно странно или изобиловать ошибками, без логов не обойтись.
Как включить запись логов?
Обычно, по умолчанию, для экономии дискового пространства ведение логов на хостинге выключено.
Приведу включение записи на примере панели управления хостингом Таймвеб.
В панели управления переходим во вкладку «Логи», выбираем из выпадающего сайта нужный (если их несколько) и активируем ползунок «Лог доступа (access_log)»
Примерно через час, когда накопится достаточное количество записей, переходим в директорию сайта и скачиваем файл.
Открываем в любом текстовом редакторе (на примере второй столбец, с адресом сайта закрашен).
Разберем для примера строку № 49
site.ru 85.93.93.102 - - [28/Sep/2017:06:33:04 +0300] "GET /page/2/ HTTP/1.0" 200 80195 "-" "Linguee Bot (http://www.linguee.com/bot; bot@linguee.com)"
site.ru – адрес нашего сайта
85.93.93.102 – IP-адрес посетителя, с датой и вренем посещения, а также его часовой пояс
GET – тип запроса, возможен вариант POST, чем отличается GET и POST можно почитать в сети, если говорить упрощено, GET – получение данных, POST – отправка, например авторизация
page/2 – к какой странице было обращение, в нашем случае это site.ru/ page/2
HTTP/1.0 – протокол, по которому пришел посетитель
200 – код ответа сервера, более подробную информацию о кодах состояния можно прочитать в Википедии — https://ru.wikipedia.org/wiki/Список_кодов_состояния_HTTP
80195 – количество байт полученных посетителем
Linguee Bot (http://www.linguee.com/bot; bot@linguee.com) – данные о посетителе, тут также может быть информация о браузере, операционной системе, устройстве и так далее
Итог
Даже при беглом взгляде видно, что с адреса 85.93.93.102 идет множество запросов, обращение было как раз по чрезмерной нагрузке на сайт, как только адрес бота Linguee Bot был запрещен, нагрузка практически сразу вернулась в норму.
И все за несколько минут, благодаря логам; без них на выяснение причины понадобилось бы гораздо больше времени. Также были замечены обращения по адресам, содержавшим вставки типа — xd0xbexd1x82xd0xb7 …
Кто занимается «лечением» сайтов, знает, что подобные запросы могут создавать запредельные нагрузки на сервер.
Иногда самые простые методы – самые действенные, а защита на уровне сервера самая надежная.
Засим прощаюсь
Мой профиль в Marketplace — https://timeweb.com/ru/community/marketplace/bashkov-vladislav
timeweb.com
Понятие
Логи сервера (лог-файлы, журнал сервера) — фалы, хранящиеся на сервере, которые содержат системную информацию сервера, а так-же протоколирующие все возможные данные о посетителе веб-ресурса.
Логи используются системными администраторами для анализа посетителей, изучения закономерности поведения определенных групп пользователей, а так-же получения различной информации о них, такой как: используемый браузер, IP адрес, данные о географическом положение клиента и многое другое. По мимо анализа, таким образом можно узнать о несанкционированных доступах к сайту, точнее узнать, кем именно он был произведен, и передать данные о данном случае в соответствующие органы.
Данные в лог-файле, в чистом виде, будут не понятным рядовым пользователям, которые увидят во всем этом всего-лишь набор символов в непонятном порядке. Но для системных администраторов и веб-разработчиков, это является вполне читабельным текстом, и довольно полезной информацией.
Последовательность событий
При каждом обращении клиента к веб-ресурсeсе, срабатывают сразу несколько событий, о последовательности которых мы и поговорим.
1. Осуществление запроса страницы. При вводе адреса в браузерную строку, либо при переходе по активный веб-ссылке, допустим, со страницы поисковой выдачи, браузер осуществляет поиск и соединение с сервером, на котором расположена страницы, и осуществляет ее запрос. При этом, он передает серверу такую информацию:
— IP-адрес компьютера клиента, который запрашивает страницу (в случае использования прокси-сервера, IP адрес вашего прокси);
— адрес запрашиваемой пользователем интернет-страницы (IP-адрес);
— точное время и дата, когда был осуществлен запрос;
— данные о фактическом местонахождении клиента (в случае если используется прокси-сервер, то фактический адрес прокси);
— информация об используемом клиентом браузере (название, версия и т.д.);
— данные о веб-страницы, с которой был осуществлен переход клиента.
2. Передача запрашиваемых данных. Происходит передача запрашиваемых данных (интернет-страница, файлы, cooki, и др.) от сервера на компьютер пользователя.
3. Запись в журнал сервера. После всего, происходит запись в журнал, в котором указываются все данные, которые фигурировали в прошлых двух событиях. Это вся информация отправленная в первом пункте, а так-же информация о переданных данных.
Как посмотреть логи сервера
Лог-файлы, хранятся в файле access.log не зависимо от того, каким типом веб-сервера вы пользуетесь (Apache, Nginx, прокси-сервером squid и т. д.) Данный файл является текстовым документом, на каждой строчке которого, записывается по одному обращению. Форматов записи в access.log довольно много, но наиболее популярным является combined, при котором, запись имеет следующий вид и последовательность:
- Код: Выделить всё
%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"
Где:
%h — хост/IP-адрес, с которого произведён запрос;
%t — время запроса к серверу и часовой пояс сервера;
%r — версия, содержимое и тип запроса;
%s — код состояния HTTP;
%b — количество отданных сервером байт;
%{Referer} — URL-источник запроса;
%{User-Agent} — HTTP-заголовок, с информацией о запросе (клиентское приложение, язык и т.д.);
%{Host} — имя Virtual Host, к которому идет обращение.
в готовом виде данная строка имеет примерно следующий вид:
На чтение логов в ручную, уйдет довольно много времени и сил. Поэтому, опытные веб-мастера используют специальное программное обеспечение, которые называют «Анализаторы лог-файлов». Они анализируют все данные, которые довольно сложны к прочтению человеком, и выдают структурированные данные. Это такие программы как: Analog, WebAnalizer, Webalizer, Awstats, Webtrends, и т.д. Видов специального программного обеспечения довольно много, среди них есть как платные программы, так и бесплатные. Поэтому я уверен, что каждый найдет себе что-то по душе.
Где найти логи сайта
Если у вас обычный хостинг, то скорей всего вам придется написать своему хостеру и запросить у него логи. Так-же, довольно часто, вы можете запросить их через панель хостера. У разных хостеров — по разному. Для примера, что бы запросить у моего хостера, достаточно сделать один клик на главной странице панели:
Если у вас есть доступ к системным папкам сервера, то вы можете найти логи по адресу /etc/httpd/logs/access_log в 99 случаях из 100.
Журнал ошибок error.log
Error.log — файл, в котором так-же ведутся логи. Но не посетителей, а возникших на сервере ошибок. Как и в случае с access.log, каждая строка файла — отвечает за одну возникшую ошибку. Запись ведется с учетом такой информации, как: точная дата и время возникновения ошибки, IP-адрес которому была выдана ошибка, тип ошибки, а так-же причина ее возникновения.
Заключение
Логи являются довольно мощным и информативным инструментом, с которыми необходимо работать. Но в наше время, их заменяют такие инструменты, как Яндекс.Метрика, Google Analytics и т.д., тем самым упрощая нам жизнь. Однако, если вы планируете развиваться, расти и познавать что-то новое, несомненно рекомендую вам познакомиться с данной темой поближе.
ruseo.net
Что это такое лог-файлы?
Лог-файлы (logs или логи) — это текстовый файл, в котором ведется запись абсолютно всех событий, которые происходили на сервере (на котором расположен Ваш сайт). Запись событий ведется так — каждому событию соответствует определенная строчка, с указанием времени события и прочих сведений. Обычно все логи сортируются по датам — одним суткам соответствует один файл.
Как их посмотреть?
Чаще всего хостинг-провайдеры позволяют скачать эти файлы по FTP. Где именно они находятся зависит только от хостера, поэтому ищите это в FAQ или обращайтесь в поддержку. Также доступ к лог-файлам можно получить из панели управления хостингом.
Зачем нужны логи?
Все лог-файлы можно разделить на три группы:
- логи доступа (access_log) записывают информацию о посетителях сайта (IP-адрес, время запроса, страница которую он запросил)
- логи ошибок (error_log) сохраняют все ошибки, которые происходили на сайте, и показывают файлы в которых они случились
- логи FTP-авторизаций собирают данные о попытках входа по FTP-соединению
Как их использовать?
Все эти файлы в первую очередь помогают найти следы взлома, и понять как именно хакер получил доступ к Вашему сайту. Но будьте внимательны, т.к. хостинг-провайдеры хранят логи определенное время (как правило 1-2 недели) и затем удаляют. Поэтому, если сайт взломан месяц назад, то из логов уже не удастся понять как взломали сайт.
Для того, чтобы собирать лог-файлы автоматически существуют программы-анализаторы, которые устанавливаются на сервер, сохраняют информацию, и потом в удобном виде показывают пользователю. Из бесплатных программ популярными являются Webalizer и AWStats. Также хороший функционал несет NetPromoter, но эта программа платная.
Важно
Если Вы попали на эту статью из-за того, что Ваш сайт взломали, то мы подготовили материал о том, как лечить сайты от вирусов, и как улучшить безопасность сайта.
ru.hostings.info
Что такое логи сервера
Прежде всего, давайте разберемся, что вообще такое логи сервера. Абсолютно все действия, которые проводятся на сервере его посетителями, документируются в специальном журнале. Под посетителями сервера в данном случае мы подразумеваем посетителей сайта, размещенного на рассматриваемом нами сервере. Современные тарифы хостинга позволяют размещать 10 и более сайтов на виртуальных серверах за небольшую ежемесячную плату. С развитием технологий и с увеличением конкуренции, мощности серверов будут расти, а стоимость снижаться. Если на вашей хостинг-площадке размещено несколько сайтов, то все их логи будут храниться в одном месте, но не переживайте, вы сможете их легко идентифицировать по названиям файлов.
Логи сервера, о которых сегодня пойдет речь — это записанные в интуитивно понятном и легко читаемом формате данные о всех действиях, производимых на сервере. Данные эти записываются в виртуальный журнал, который представляет собой файл с расширением access_log, error_log и т.д. Довольно часто логи не хранятся на сервере в первоначальном виде, а подвергаются сжатию в формате GZIP (GZIP compressed archive file), но это происходит со старыми логами. Такие файлы имеют расширение GZ и занимают значительно меньше места, чем занимали бы несжатом виде. Сжатие логов происходит на стороне хостинг-провайдера в автоматическом режиме и от вас тут никаких действий не требуется. Особенно сжатие логов актуально для высокопосещаемых проектов, подверженных большой нагрузке. Логи же за текущий день пишутся в режиме реального времени и не подвергаются сжатию для достижения максимального быстродействия, но в ущерб физической памяти на сервере.
Файлы имеющие расширение access_log и error_log не должны вас пугать своей загадочностью, ведь их можно открыть обычным блокнотом, а представленная в них текстовая информация понятна на интуитивном уровне даже тем людям, которые только недавно узнали о существовании этих файлов.
Как видно из расширений этих файлов, access_log хранит в себе данные, связанные с обращением к серверу, а error_log — данные с возможными ошибками, произошедшими на его стороне.
Обычно названия этих файлов совпадают с доменным именем сайта, к которому относятся, поэтому ориентироваться в них довольно просто. Каждый файл содержит логи за один день, что делает просмотр и анализ логов еще более удобным. Как только наступает следующий день, создается новый файл, в который записываются новые данные. По прошествии некоторого времени (зависит от того, какой используется хостинг, но обычно 1-2 дня), старые логи архивируются и хранятся еще какое то время, после чего окончательно удаляются. Чаще всего, на виртуальном хостинге вы сможете посмотреть логи не более чем двухнедельной давности, поэтому начинать заниматься поиском возможных проблем стоит как можно раньше и не откладывать это дело в долгий ящик.
Как смотреть логи сервера
А теперь давайте обсудим, что же можно увидеть в логах сервера и как их смотреть, чтобы вы смогли убедиться в их важности и необходимости проведения данного мероприятия на регулярной основе. Каждый лог в журнале записывается с новой строки и имеет следующий формат записи:
87.242.64.204 - - [14/Sep/2015:00:00:19 +0300] "POST /wp-cron.php?doing_wp_cron=1442178018.1021161079406738281250 HTTP/1.0" 200 0 "-" "WordPress/4.3; http://makeasite.ru"
Как видите, все довольно просто и интуитивно понятно. Из этой строки можно по порядку выделить следующие данные:
- IP-адрес (по нему можно вычислить адрес посетителя, если это необходимо);
- точная дата и время обращения к серверу в формате GMT;
- метод (GET или POST)
- URL;
- версия протокола;
- код ответа сервера;
- User agent + ссылка (опционально).
А теперь давайте немного подробней рассмотрим каждый из этих пунктов.
IP-адрес может понадобиться для идентификации компьютера в сети. Речь идет об айпи адресе узла, который подключался к вашему серверу.
Дата — дата и время в формате GMT (время гринвичского меридиана), когда происходило обращение к серверу.
Метод принимает значения GET или POST, которые означают передачу данных в очевидном виде (GET) или зашифрованном (POST).
URL — адрес страницы, к которой обратились.
Версия протокола, которая используется сервером сервером (в данном случае HTTP/1.0). Подробнее смотрите в статье о 404 ошибке и ее настройке, там был момент, когда мы немного подробней обсудили возможные версии протоколов и способы их определения средствами PHP.
Код ответа сервера (в данном случае он имеет значение 200, что означает успешный ответ).
User agent — заголовок, передающий информацию об устройстве, с которого происходит обращение к серверу. Иногда, к этой информации добавляется ссылка, что чаще всего указывает на то, что посетитель является поисковым ботом:
"Mozilla/5.0 (compatible; YandexMetrika/2.0; +http://yandex.com/bots)"
Кстати, сами файлы логов чаще всего находятся в корневой директории вашего сервера, в папке _logs или с похожим и понятном на интуитивном уровне названием (не перепутаете). Иногда бывает так, что логов изначально нет и их запись нужно включить опционально, активировав бесплатную услугу в контрольной панели вашего хостинга. Если же у вас возникли проблемы с поиском директории логов и их просмотром, лучше всего будет обратиться в техническую поддержку вашего хостинга, где вам обязательно помогут разобраться с этой проблемой.
makeasite.ru
Ведение логов помогает разработчику в процессе создания и последующего сопровождения приложения, при поиске ошибок в коде и в разрешении непонятных ситуаций, когда наше приложение в момент работы ведет себя странным образом, и нам нужно найти причину такого поведения.
Любой разработчик сталкивается с подобными ситуациями, когда какой-то компонент приложения отрабатывает странным образом, выдает не тот результат или вообще перестает работать. Использование логов поможет нам в подобных ситуациях. Время поиска проблемных мест в нашем коде сократится в разы, и мы быстрее сможем решить ту или иную проблему.
Вообще, на сегодняшний момент ни одно более или менее серьезное приложение не обходится без написания логов.
Под таким журналом можно понимать и записи в обычный текстовый файл, и записи в базу данных, и записи на удаленный веб-сервис, и даже email-письма на определенный адрес о тех или иных состояниях нашего приложения.
Какие записи делать в этот журнал, то есть, какую конкретно информацию записывать, определяет сам разработчик. Это могут быть сведения о том, что все работает в штатном режиме, то есть просто ежедневный мониторинг нашего приложения, или что произошла какая-то ошибка, на которую нужно максимально срочно отреагировать и устранить, и так далее.
Всего существует шесть уровней логирования, каждый из которых предназначен для сообщений того или иного типа, той или иной важности:
Trace – максимально детальная информация о том, что происходит с целевым участком кода, по шагам. Например: Попытка открыть подключение к БД, успешнонеуспешно. Сколько времени заняла эта операция. Сколько времени выполнялась выборка из БД, успешнонеуспешно. Сколько записей извлечено. Какая была нагрузка на систему, сколько использовано памяти. Сколько записей прошло нужную фильтрацию. Сколько записей оказалось в результирующей выборке, куда эти записи отправились дальше. Проверка нужных значений в каждой записи.
Debug – это информация для отладки. Логирование крупных операций, менее детально, чем в Trace. Здесь мы не так подробно описываем весь процесс операции, но, тем не менее, заносим в журнал основные операции. Например: Совершено обращение к БД. Из базы выбрано N записей. Записи успешно обработаны и отправлены клиенту.
Info – это более общие информационные сообщения о текущей работе приложения, что происходит с системой в процессе ее использования. Например: Была выгрузка студентов в Excel-файл. На сайте зарегистрирован новый студент. Студент добавил новый отчет. Студент перемещен в другую группу.
Warn – сообщения о странной или подозрительной работе приложения. Это еще не серьезная ошибка, но следует обратить внимание на такое поведение системы. Например: Добавлен студент с возрастом 2 года. Студент получил отрицательный балл. Преподаватель завершил курс, в котором училось 0 студентов. В группе находится больше студентов, чем максимально возможно.
Error – сообщения об ошибках в приложении. Подобные сообщения – это уже большая проблема, которую нужно решить для дальнейшей правильной работы системы. Например: Ошибка сохранения нового студента в БД. Невозможно загрузить студентов в данной группе. Ошибка при входе в личный кабинет студента.
Fatal – сообщения об очень серьезных ошибках в системе. Чаще всего это связано с работоспособностью всего приложения или его окружения на сервере. На такие сообщения следует реагировать МАКСИМАЛЬНО оперативно. Например: Приложение постоянно перезагружается из-за нехватки памяти или места на жестком диске. Приложение завершило работу по неизвестной причине. Нет доступа к базе данных. Нет доступа к сети. Заблокирован какой-то порт.
То есть, прежде чем отправить какое-то сообщение в лог, нам нужно отнести его к той или иной группе.
Например, мы написали новый функционал и хотим его протестировать, как правильно и быстро он работает. Для этого мы будем использовать тип сообщений Trace, то есть все наши сообщения в логе будут помечены как Trace.
Подобным образом мы можем описать, как работает наше приложение в целом, сообщения будут с пометкой Info.
Если же в опасных участках кода мы генерируем исключение, то теперь мы также добавим запись в лог с пометкой Error.
К какой группе отнести то или иное сообщение решает сам разработчик. К данному вопросу следует подойти с максимальной серьезностью. Очевидно, что ошибки не следует помечать как Info, не следует игнорировать ошибки и просто не записывать их в лог. От правильно настроенной системы логирования будет зависеть простота сопровождения всей системы, оперативность реагирования на ошибки и время, затраченное на устранение проблемы.
Иногда разработчики ленятся писать логи, не хотят тратить на это время. В дальнейшем оказывается, что время, затраченное на поиск и исправление ошибок, в разы больше времени, которое потребовалось бы на создание системы логов.
Естественно, многое зависит от сложности проекта. Если вы создаете простейший трехстраничный сайт-визитку или консольное приложение для собственных нужд у себя на локальном компьютере, то написание сложной системы логирования может быть дольше, чем создание самого проекта. В таком случае в логи можно записывать только сообщения об ошибках или почему упал сайт. Но если вы работаете над сложным проектом в команде с другими разработчиками, то грамотное ведение логов просто обязательно.
Для того, чтобы начать логирование, мы подключим в наш проект платформу NLog. Это можно легко сделать посредством менеджера NuGet (прямо из Visual Studio).
Обратите внимание на конфигурационный файл NLog.config. В этом файле находятся настройки логгера (куда будут выводиться логи, формат записи логов и т.д.). Давайте настроим файл следующим образом:
<targets> <target xsi:type="File" name="main" fileName="${basedir}/logs/${shortdate}.log" layout="${longdate} | ${callsite} | ${uppercase:${level}} | ${message} ${newline}" /> <target xsi:type="File" name="error" fileName="${basedir}/logs/errors/${shortdate}.log" layout="${longdate} | ${callsite} | ${uppercase:${level}} | ${message} ${newline}" /> </targets> <rules> <logger name="*" maxlevel="Warn" writeTo="main" /> <logger name="*" minlevel="Error" writeTo="error" /> </rules>
Здесь мы описали два правила и цели, к которым они применяются. Мы хотим чтобы отладочная информация была записана в один файл, а информация об ошибках — в другой (в поддиректории errors). Оба лога будут писаться в текстовый файл. Также мы используем специальные теги (директивы), которые понимает NLog. На их место будут подставлены соответствующие значения в процессе выполнения. Опишем теги, которые используются у нас в конфигурации (описание всех тегов и любую другую информацию можно найти на официальном сайте проекта NLog):
- ${basedir} — корневой каталог нашего приложения
- ${shortdate} — текущая дата в формате yyyy-MM-dd
- ${longdate} — текущая дата в формате yyyy-MM-dd HH:mm:ss.ffff
- ${callsite} — место вызова лога (название класса, название метода)
- ${uppercase:${level} — уровень логирования
- ${message} — непосредственно сообщение, которое будет записано в лог
- ${newline} — символ новой строки
Далее уже в коде объявим новый логгер (здесь код проекта приводится в сокращенном виде, исходный код всего проекта можно скачать в конце статьи):
public class StudentsRepository { private static Logger logger = LogManager.GetCurrentClassLogger(); //... }
Чаще всего следует объявлять один статичный логгер в пределах всего класса. Здесь мы посредством класса-менеджера LogManager объявили новый логгер, с которым будем работать.
Начнем логирование с уровня Trace. В методе, где мы выбираем студента по его идентификатору, давайте максимально подробно опишем как это происходит:
public Student GetStudentById(int id) { //здесь моделируется ситуация реальной выборки студента из базы данных... logger.Trace("Запрашиваемый id студента: " + id); logger.Trace("Попытка подключения к источнику данных"); logger.Trace("Подключение к источнику данных прошло успешно. Затраченное время(мс): " + new TimeSpan(0, 0, 0, 0, 20).Milliseconds); var student = _studentsList.FirstOrDefault(x => x.Id == id); logger.Trace("Выборка прошла успешно. Выбран студент с id==" + student.Id); return student; }
Обратите внимание, что мы на объекте logger вызываем метод Trace(). Он имеет соответствующее значение — запись в лог сообщения типа Trace. Если обратиться к определению класса Logger, то можно обнаружить, там также присутствуют и другие методы для всех уровней лога, которые мы будем использовать далее.
Теперь давайте добавим несколько сообщений уровня Debug. Как мы помним, это тоже отладочная информация, но менее детальная. Данный подход мы используем в другом методе, для наглядности:
public List<Student> GetStudents() { //здесь моделируется ситуация реальной выборки студентов из базы данных... logger.Debug("Произведено подключение к базе данных"); logger.Debug("Произведена выборка всех студентов"); return _studentsList; }
Идем далее. На уровне Info мы описываем регулярные операции в нашем приложении, то есть поднимаемся еще на уровень выше. Предположим, что мы работаем над ASP.NET MVC приложением, и у нас есть действие в контроллере, которое обращается к ранее описанному методу GetStudentById():
public ActionResult GetStudent(int id) { logger.Info("Преподаватель запросил студента с id == " + id); StudentsRepository repository = new StudentsRepository(); Student student = repository.GetStudentById(id); return View(student); }
Теперь добавим в логи сообщения уровня Warn. Как мы помним, на этом уровне логирования мы описываем все потенциально опасные ситуации, странное и нелогичное поведение компонентов. Будем заносить в лог запись, если студенту меньше 15 лет:
//... Student student = repository.GetStudentById(id); logger.Trace("Выборка прошла успешно. Выбран студент с id==" + student.Id); if (student.Age < 15) logger.Warn("Выбран студент моложе 15 лет"); //...
Далее обработаем ошибку в нашем коде и запишем в лог сообщение уровня Error:
var student = _studentsList.FirstOrDefault(x => x.Id == id); if (student == null) logger.Error("Ошибка. Не найден студент с id == " + id); logger.Trace("Выборка прошла успешно. Выбран студент с id==" + student.Id); if (student.Age < 15) logger.Warn("Выбран студент моложе 15 лет");
Теперь определим, что же нам записать на уровне Fatal. В нашем простейшем примере просто смоделируем подобную ситуацию:
//... logger.Fatal("Достигнут максимально допустимый в приложении предел использования оперативной памяти 90%"); //...
Мы рассмотрели все шесть уровней логирования и описали процесс работы нашего приложения максимально подробно. Теперь мы можем сразу проанализировать работу сайта, просто изучив логи, и не заглядывать в исходный код.
Подобным образом происходит логирование. В нашем простейшем примере, где мы моделируем работу со студентами, все предельно ясно и прозрачно даже без логов. Но в сложных проектах ведение логов является неотъемлемой частью разработки.
Конечно, это далеко не полные возможности настройки платформы NLog. В конфигурационном файле можно настроить запись логов в другие места, например, в базу данных, на консоль, в оперативную память, отправлять как емаил-сообщение, отправлять сообщения по сети и так далее. Также можно настроить фильтрацию сообщений, более сложный шаблон сообщений. Если вас не устраивает стандартный функционал логгера, то можно написать свое собственное расширение и подключить.
На этом здесь все, давайте подведем небольшой итог. Мы изучили тему логирования в приложении. Посмотрели как правильно логировать те или иные участки кода, а также познакомились с одной из самых популярных платформ логирования – это NLog Platform, также рассмотрели ее возможности и как можно настроить генерацию логов на этой платформе.
alekseev74.ru