Как читать логи сервера и что это такое?
Логи – это инструмент, при помощи которого можно отслеживать рабочий процесс сервера или сайта. Поэтому знать, как читать логи это полезное умение для выявления сбоев в работе ПО, быстрого и результативного реагирования на другие проблемы (выявление злонамеренных действий), эффективного анализа рабочий процесс, противодействия DDoS-атакам.
Содержание:
Что такое логи и зачем они нужны
Логи (log) – это специальные текстовые файлы, в которых в хронологическом порядке фиксируется информация обо всех действиях программы или пользователей. Проще говоря, это журнал регистрации всех событий происходивших в системе:
Логи доступа указывают на уязвимые места сайта (в случае взлома), помогают собирать статистику посещаемости, узнавать откуда проводились запросы и какие ресурсы ссылаются на этот сайт, оценивать популярность страниц. По файлам ошибок проще найти источник проблемы и оперативно устранить баги и сбои. Журналы сервера (server logs) облегчают контроль рабочего процесса серверной машины.
В файлах логов записывается и отслеживается история работы всего программного комплекса. Поэтому специалисты рекомендуют периодически просматривать их, даже если никаких подозрительных моментов не произошло. И тем более немедленно обратиться к ним, если резко возросло количество ошибок, посыпался спам или заметно увеличилась нагрузка на сервер.
Типы логов и где их найти
Месторасположение логов зависит от используемого ПО, настроек, прописанного админом пути. Чаще всего server logs сохраняются в var/log/. Однако, не все сервисы помещают файлы регистрации в эту директорию. В любом случае, можно уточнить такую информацию у веб-хостера.
У дистрибутивов Linux CentOS или Fedora логи серверной машины лежат в /var/log/. Там можно найти:
Лог ошибок MySQL ($hostname.err) хранится в /var/lib/mysql/. Для Debian или Ubuntu местоположение логов аналогично, за исключением log file ошибок MySQL: /mysql/error.log. А также – логи веб сервера Apache сохраняются по пути /var/log/apache2.
У ОС Windows дружной метод структурирования log-файлов. События делятся на несколько уровней:
Их можно отсортировать или отфильтровать и выбрать необходимое. 
Запуск и отключение логов осуществляется с административной панели. Как правило, доступ через раздел «журнал» или «логи». При этом стоит учитывать, что файлы не сохраняются годами. Поэтому, при необходимости посмотреть log, это нужно сделать своевременно.
Какая информация хранится в логах и как ее интерпретировать?
Для большинства пользователей содержимое log-файлов это бессмысленный набор символов. Как читать логи, чтобы понять, что в них зашифровано?
Строка access.log сервера содержит:
Как правило, такой информации достаточно, чтобы проанализировать ситуацию и сделать нужные выводы. Например, заблокировать бота, который создал чрезмерную нагрузку на сайт.
Файл ошибок (error.log) регистрирует моменты, когда что-то пошло не так. Из них можно узнать:
Конечно, даже после расшифровки, данных логов еще нужно проанализировать. Для этого существует различное ПО, которое помогает отрабатывать данные из логов – Weblog Expert, WebAlyzer, Analog, Webtrends, Awstats, SpyLOG Flexolyzer и другие платные и бесплатные программы.
Логирование. NLog Platform. Зачем нужны логи в приложении
Здесь мы затронем тему логирования в нашем приложении, что такое логи, и как правильно вести логи, насколько это необходимо и полезно. Рассмотрим систему логирования NLog Platform.
Ведение логов помогает разработчику в процессе создания и последующего сопровождения приложения, при поиске ошибок в коде и в разрешении непонятных ситуаций, когда наше приложение в момент работы ведет себя странным образом, и нам нужно найти причину такого поведения.
Любой разработчик сталкивается с подобными ситуациями, когда какой-то компонент приложения отрабатывает странным образом, выдает не тот результат или вообще перестает работать. Использование логов поможет нам в подобных ситуациях. Время поиска проблемных мест в нашем коде сократится в разы, и мы быстрее сможем решить ту или иную проблему.
Вообще, на сегодняшний момент ни одно более или менее серьезное приложение не обходится без написания логов.
Под таким журналом можно понимать и записи в обычный текстовый файл, и записи в базу данных, и записи на удаленный веб-сервис, и даже email-письма на определенный адрес о тех или иных состояниях нашего приложения.
Какие записи делать в этот журнал, то есть, какую конкретно информацию записывать, определяет сам разработчик. Это могут быть сведения о том, что все работает в штатном режиме, то есть просто ежедневный мониторинг нашего приложения, или что произошла какая-то ошибка, на которую нужно максимально срочно отреагировать и устранить, и так далее.
Всего существует шесть уровней логирования, каждый из которых предназначен для сообщений того или иного типа, той или иной важности:
Trace – максимально детальная информация о том, что происходит с целевым участком кода, по шагам. Например: Попытка открыть подключение к БД, успешно\неуспешно. Сколько времени заняла эта операция. Сколько времени выполнялась выборка из БД, успешно\неуспешно. Сколько записей извлечено. Какая была нагрузка на систему, сколько использовано памяти. Сколько записей прошло нужную фильтрацию. Сколько записей оказалось в результирующей выборке, куда эти записи отправились дальше. Проверка нужных значений в каждой записи.
Debug – это информация для отладки. Логирование крупных операций, менее детально, чем в Trace. Здесь мы не так подробно описываем весь процесс операции, но, тем не менее, заносим в журнал основные операции. Например: Совершено обращение к БД. Из базы выбрано N записей. Записи успешно обработаны и отправлены клиенту.
Info – это более общие информационные сообщения о текущей работе приложения, что происходит с системой в процессе ее использования. Например: Была выгрузка студентов в Excel-файл. На сайте зарегистрирован новый студент. Студент добавил новый отчет. Студент перемещен в другую группу.
Warn – сообщения о странной или подозрительной работе приложения. Это еще не серьезная ошибка, но следует обратить внимание на такое поведение системы. Например: Добавлен студент с возрастом 2 года. Студент получил отрицательный балл. Преподаватель завершил курс, в котором училось 0 студентов. В группе находится больше студентов, чем максимально возможно.
Error – сообщения об ошибках в приложении. Подобные сообщения – это уже большая проблема, которую нужно решить для дальнейшей правильной работы системы. Например: Ошибка сохранения нового студента в БД. Невозможно загрузить студентов в данной группе. Ошибка при входе в личный кабинет студента.
Fatal – сообщения об очень серьезных ошибках в системе. Чаще всего это связано с работоспособностью всего приложения или его окружения на сервере. На такие сообщения следует реагировать МАКСИМАЛЬНО оперативно. Например: Приложение постоянно перезагружается из-за нехватки памяти или места на жестком диске. Приложение завершило работу по неизвестной причине. Нет доступа к базе данных. Нет доступа к сети. Заблокирован какой-то порт.
То есть, прежде чем отправить какое-то сообщение в лог, нам нужно отнести его к той или иной группе.
Например, мы написали новый функционал и хотим его протестировать, как правильно и быстро он работает. Для этого мы будем использовать тип сообщений Trace, то есть все наши сообщения в логе будут помечены как Trace.
Подобным образом мы можем описать, как работает наше приложение в целом, сообщения будут с пометкой Info.
Если же в опасных участках кода мы генерируем исключение, то теперь мы также добавим запись в лог с пометкой Error.
К какой группе отнести то или иное сообщение решает сам разработчик. К данному вопросу следует подойти с максимальной серьезностью. Очевидно, что ошибки не следует помечать как Info, не следует игнорировать ошибки и просто не записывать их в лог. От правильно настроенной системы логирования будет зависеть простота сопровождения всей системы, оперативность реагирования на ошибки и время, затраченное на устранение проблемы.
Иногда разработчики ленятся писать логи, не хотят тратить на это время. В дальнейшем оказывается, что время, затраченное на поиск и исправление ошибок, в разы больше времени, которое потребовалось бы на создание системы логов.
Естественно, многое зависит от сложности проекта. Если вы создаете простейший трехстраничный сайт-визитку или консольное приложение для собственных нужд у себя на локальном компьютере, то написание сложной системы логирования может быть дольше, чем создание самого проекта. В таком случае в логи можно записывать только сообщения об ошибках или почему упал сайт. Но если вы работаете над сложным проектом в команде с другими разработчиками, то грамотное ведение логов просто обязательно.
Для того, чтобы начать логирование, мы подключим в наш проект платформу NLog. Это можно легко сделать посредством менеджера NuGet (прямо из Visual Studio).
Обратите внимание на конфигурационный файл NLog.config. В этом файле находятся настройки логгера (куда будут выводиться логи, формат записи логов и т.д.). Давайте настроим файл следующим образом:
Далее уже в коде объявим новый логгер (здесь код проекта приводится в сокращенном виде, исходный код всего проекта можно скачать в конце статьи):
Чаще всего следует объявлять один статичный логгер в пределах всего класса. Здесь мы посредством класса-менеджера LogManager объявили новый логгер, с которым будем работать.
Начнем логирование с уровня Trace. В методе, где мы выбираем студента по его идентификатору, давайте максимально подробно опишем как это происходит:
Теперь давайте добавим несколько сообщений уровня Debug. Как мы помним, это тоже отладочная информация, но менее детальная. Данный подход мы используем в другом методе, для наглядности:
Идем далее. На уровне Info мы описываем регулярные операции в нашем приложении, то есть поднимаемся еще на уровень выше. Предположим, что мы работаем над ASP.NET MVC приложением, и у нас есть действие в контроллере, которое обращается к ранее описанному методу GetStudentById():
Теперь добавим в логи сообщения уровня Warn. Как мы помним, на этом уровне логирования мы описываем все потенциально опасные ситуации, странное и нелогичное поведение компонентов. Будем заносить в лог запись, если студенту меньше 15 лет:
Далее обработаем ошибку в нашем коде и запишем в лог сообщение уровня Error:
Теперь определим, что же нам записать на уровне Fatal. В нашем простейшем примере просто смоделируем подобную ситуацию:
Мы рассмотрели все шесть уровней логирования и описали процесс работы нашего приложения максимально подробно. Теперь мы можем сразу проанализировать работу сайта, просто изучив логи, и не заглядывать в исходный код.
Подобным образом происходит логирование. В нашем простейшем примере, где мы моделируем работу со студентами, все предельно ясно и прозрачно даже без логов. Но в сложных проектах ведение логов является неотъемлемой частью разработки.
Конечно, это далеко не полные возможности настройки платформы NLog. В конфигурационном файле можно настроить запись логов в другие места, например, в базу данных, на консоль, в оперативную память, отправлять как емаил-сообщение, отправлять сообщения по сети и так далее. Также можно настроить фильтрацию сообщений, более сложный шаблон сообщений. Если вас не устраивает стандартный функционал логгера, то можно написать свое собственное расширение и подключить.
На этом здесь все, давайте подведем небольшой итог. Мы изучили тему логирования в приложении. Посмотрели как правильно логировать те или иные участки кода, а также познакомились с одной из самых популярных платформ логирования – это NLog Platform, также рассмотрели ее возможности и как можно настроить генерацию логов на этой платформе.
Профессиональный подход к ведению логов
Логи можно сравнить с уликами на месте преступления, а разработчиков — с криминалистами. Роль логов трудно переоценить, ведь когда необходимо найти баг или причину сбоя, сразу обращаются к ним. Подобно тому, как отсутствие улик приводит к нераскрытым делам, отсутствие содержательных логов осложняет диагностику и устранение ошибок, превращая их в затянувшийся или вовсе невыполнимый процесс. Мне приходилось наблюдать, как люди мучились с такими инструментами, как Strace и tcpdump, или развертывали новый код в продакшене во время сбоя лишь затем, чтобы получить больше лог-файлов для выявления проблемы.
Как говорится: “Хорошо подготовиться — половину дела сделать”, так что каждому профессиональному разработчику следует научиться эффективно вести логи и быть готовым к работе с ними. В данной статье мы не только рассмотрим список полезных практик логирования в приложении, но и разберем теоретические основы данного процесса: что записываем, когда и кто этим должен заниматься.
Как осуществляется процесс отладки?
Прежде чем начать разговор о логах, необходимо ответить на два вопроса:
Программа как переходы состояний
Программа — это серия переходов между состояниями.
Состояния — это вся информация, которую программа хранит в своей памяти в определенный момент времени, а код программы определяет то, как она переходит от одного состояния к другому. Разработчики, использующие императивные языки программирования, такие как Java, зачастую акцентируют больше внимания на самом процессе (коде), чем состояниях. Однако понимание того, что программа является серией состояний, очень важно, поскольку они существенно ближе к тому, что должна делать программа, а не как.
Отладка
Отладка — это мысленная реконструкция переходов состояний. Разработчики проигрывают в уме сценарий программы: как она принимает вводные данные, проходит через ряд изменений состояний и осуществляет вывод, а затем определяют, что пошло не так. Во время разработки этот мыслительный процесс подкрепляется использованием отладчика. Однако в продакшене делать это уже гораздо сложнее, поэтому на данном этапе чаще прибегают к помощи логов.
Понимая суть процесса отладки, мы с легкостью ответим на этот вопрос:
Логи должны содержать информацию, необходимую для реконструкции переходов состояний.
Невозможно, да и не нужно, фиксировать все состояния во все отрезки времени. Например, полиции достаточно лишь нескольких точных набросков, а не видеоклона, для поимки преступника. Тоже самое относится и к логам: разработчикам нужно только внести в них информацию о том, когда происходит переход в критическое состояние. Кроме того, логи должны содержать ключевые характеристики текущего состояния и причину перехода.
Переход в критическое состояние
Не все переходы состояний стоит записывать в лог. Важно рассмотреть программу как серию изменяемых состояний, разделить их на фазы и затем сосредоточиться на времени, когда выполнение переходит от одной фазы к другой.
Предположим, что существуют 3 фазы запуска приложения:
Было бы очень разумно вести логи в начале и конце каждой фазы. Если бы произошла ошибка на этапе подключения к зависимостям и приложение бы зависло, то логи отчетливо показали бы, что после загрузки настроек оно вошло во вторую фазу процесса, не завершив его. Располагая этой информацией, разработчики смогли бы быстро определить проблему.
Ключевые характеристики
Логирование состояний напоминает создание эскизов программы только с учетом ключевых характеристик основ бизнес-логики. Если есть информация закрытого характера, например персональные данные, то ее также нужно записать в лог, но в завуалированном виде.
Например, когда HTTP-сервер переходит из состояния ожидания запроса в состояние получения запроса, он должен зафиксировать в логе HTTP-метод и URL, так как они описывают основы HTTP-запроса. Остальные его элементы (заголовки или часть тела сообщения) записываются в том случае, если их значения влияют на бизнес-логику. Например, если поведение сервера сильно отличается между состояниями Content-Type:application/json и Content-Type:multipart/form-data, заголовок следует записать.
Причина перехода состояния
Логирование причины перехода состояния чрезвычайно полезно для отладки. Логи должны кратко охватывать содержание предыдущих и следующих состояний, а также объяснять их причины. Они помогают разработчикам получить общую картину и ориентироваться в процессе реконструкции (отладки) выполнения программы.
Пример
Рассмотрим простой пример для обобщения всего сказанного. Предположим, что сервер получает некорректный номер социального страхования, и разработчик намерен внести в лог информацию об этом событии.
Вот несколько анти-шаблонов логов, в которых отсутствуют ключевые характеристики состояния и причины:
Все они содержат определенную информацию, но ее недостаточно для ответов на вопросы, которые могут возникнуть у разработчиков в процессе поиска ошибки. Какой запрос не смог обработать сервер? Почему номер социального страхования был отклонен? Какой пользователь столкнулся с этой ситуацией? Грамотный и полезный для отладки лог будет выглядеть так:
[2020–04–20T03:36:57+00:00] server.go: Received a SSN request(track id: “e4a49a27–1063–4ab3–9075-cf5faec22a16”) from user uuid “123e4567-e89b-12d3-a456–426655440000”(previous state), rejecting it(next state) because the server is expecting SSN format AAA-GG-SSSS but got **-***(why)
([2020–04–20T03:36:57+00:00] server.go: Получен запрос номера социального страхования (трек id: “e4a49a27–1063–4ab3–9075-cf5faec22a16”) от пользователя user uuid “123e4567-e89b-12d3-a456–426655440000” (предыдущее состояние), запрос отклонен (следующее состояние), так как сервер требует номер социального страхования в формате AAA-GG-SSSS, а получил **-*** (причина)
Кто должен записывать логи?
Типичная ошибка, которую многие допускают, связана с тем, “кто” должен фиксировать информацию. Ведение логов не теми функциями оборачивается дублированием или дефицитом информации.
Программа как уровни абстракции
Большинство грамотно созданных программ подобны пирамиде с уровнями абстракции. Классы/функции верхних уровней разбивают сложную задачу на подзадачи, тогда как классы/функции нижних уровней абстрагируют реализацию подзадач, таких как черные ящики, и предоставляют интерфейсы для вызова верхним уровнем. Эта парадигма облегчает программирование, поскольку каждый уровень сосредоточен на своей логике, не беспокоясь о всевозможных деталях.
Например, веб-сайт может состоять из следующих уровней: бизнес-логика, HTTP и TCP/IP. Реагируя на URL-запрос, уровень бизнес-логики решает, какую веб-страницу показать, и отправляет ее контент на уровень HTTP, где он превращается в HTTP-ответ. Следующий уровень TCP/IP преобразует HTTP-ответ в пакеты TCP и рассылает их.
Ведите логи только на правильных уровнях
Как следствие абстракции, разные уровни имеют разные степени понимания выполняемой задачи. В предыдущем примере уровень HTTP не владел данными ни о количестве отправляемых пакетов TCP, ни о намерении пользователей в момент URL-запроса. Предпринимая попытку логирования, разработчикам следует выбрать правильный уровень, который содержит полную информацию о переходах состояний и причинах.
Вернемся к нашему примеру проверки корректности номера социального страхования. Допустим, что логика его проверки обернута в класс Validator следующим образом:
Есть еще другая функция, которая проверяет запрос, обновляющий информацию о пользователе, и вызывает проверку номера социального страхования.
Однако это вовсе не означает, что логирование на нижних уровнях программы совершенно необязательно, особенно когда они не раскрывают ошибки верхним уровням. Например, сетевой уровень может иметь встроенную логику повторных попыток, из чего следует, что верхние уровни не замечают проблем с прерывающимися соединениями. В общем, нижние уровни могут вести логи больше на уровне DEBUG, чем на INFO, в целях сокращения многословности. При необходимости разработчики могут настроить уровень лога для получения большего количества деталей.
Сколько должно быть логов?
Существует очевидное соотношение между объемом логов и их полезностью. Чем более содержательные логи, тем легче реконструировать переходы состояний. Вы можете воспользоваться двумя способами контроля количества логов:
Установите соотношение между логами и рабочей нагрузкой
Для контроля объема логов сначала важно его правильно измерить. Большинство программ имеют 2 типа рабочей нагрузки:
В большинстве случаев процесс логирования запускается рабочей нагрузкой: чем больше ее у программы, тем больше логов она записывает. Могут быть и другие логи, не связанные с рабочей нагрузкой, но они становятся малозначимыми, когда программа начинает работу. Разработчики должны сохранять соотношение # логов и # рабочих элементов линейным. Иначе говоря:
# логов = X * # рабочих элементов+ константы
где X можно определить, изучив код. Разработчики должны иметь хорошее представление об X-факторах для своих программ и приводить их в соответствие с возможностями логирования и бюджетом. Вот еще несколько типичных случаев X:
Используйте уровни логов
Что, если X все еще слишком большой даже после оптимизации? На помощь приходят уровни логов. Если X намного больше, чем 1, то можно поместить логи на уровень DEBUG, тем самым снизив X уровня INFO. В процессе устранения неполадок программа может временно выполняться на этом уровне для предоставления дополнительной информации.
Краткие выводы
Чтобы профессионально писать логи, следует рассматривать программу как серию переходов состояний с уровнями абстракции. Владея теоретическими знаниями, можно ответить на ключевые вопросы о логировании в приложении:
1.Когда писать логи? В момент перехода в критическое состояние.
2.Что записывать в лог? Ключевыехарактеристики текущего состояния и причину перехода состояния.
3.Кто должен записывать логи? Логирование должно происходить на правильном уровне, содержащем достаточно информации.
4.Каким должно быть количество логов? Определите X-фактор (по формуле # логов = X * # рабочих элементов+ константы) и настройте его экономно, но выгодно.
Логи. зачем, почему, как.
Условия:
— в машине не более двух человек (вы — рулите, пассажир — снимает лог. либо вариант — вы рулите а лог снимается сам ).
— двигатель полностью прогрет
— выключен кондиционер (не горит кнопка АС на ручном кондиционере; климат-контроль в положении ECON)
— выключены системы ASR/ESP (на приборной панели горит индикатор в кружочке, кнопка ASR/ESP на центральной консоли горит желтым)
— все боковые стекла закрыты
— имеется кусок прямой дороги ВНЕ населенного пункта протяженностью не менее 1.5км с идеальным, сухим, асфальтовым покрытием, без пешеходных переходов и каких либо препятствий. Скорость на конец записи лога в некоторых случаях может достигать 180 км/ч если не уверены — не подвергайте себя и окружающих опасности! все делаете исключительно на свой страх и риск!
Механика процесса:
1) подключаем диагностический кабель к машине, запускаем vag-com
2) залезаем в контроллер двигателя (Двигатель 01), выбираем канал «измерения 08», вводим номера требуемых для записи групп (максимум — три. какие конкретно — смотрим ниже) с параметрами основных датчиков, внизу на этой же вкладке жмем кнопку Лог (при этом становится доступно меню по названию лог-файла и месту его расположения на жестком диске. если не требуется чего-то дополнительного — оставляем все так как нам предлагает программа). Все, система готова для записи лога (кнопкой старт мы начинаем записывать лог, кнопкой стоп останавливаем запись лога).
3) включаем запись Лога нажатием кнопки старт.
Эта же последовательность действий в видеоинструкции (спасибо Владимиру kishunv ):
качаем инструкцию по этой ссылке
4) трогаемся и разгоняемся по прямой до скорости, при которой на 3 ПЕРЕДАЧЕ на МИНИМАЛЬНО возможных оборотах (примерно в районе 1100-1200 об.) может ехать машина (в случае АКПП — необходимо перевести коробку в режим типтроника, и выбрать третью передачу, либо выставить третью передачу на селекторе и дать переключиться коробке до 3-й передачи). Вдавливаем относительно быстро педаль акселераторав пол до упора (для владельцев АКПП — педаль газа нужно продавить так что бы при этом НЕ сработал режим кик-дауна, когда коробка резко переключится на передачу вниз) и не отжимаем её ни на миллиметр до достижении мотором 6000-6300 оборотов. (для дизеля до 4000-4200 оборотов).
5) бросаем газ, тормозим, останавливаем запись лога нажатием кнопки стоп (там где была кнопка старт до начала записи ).
В процессе снятия лога постоянно контролируйте имеющееся у вас в запасе расстояние для нормального безопасного торможения не отвлекайтесь на ноутбук, там все записывается и без вашего участия
Всё, лог записан. стирайте со лба пот и радуйтесь вновь освоенному ремеслу возвращайтесь домой для того что бы выложить записанный вами лог-файл на форум в профильную ветку и ждать оценки вашего творчества коллегами по цеху (к слову, сказать по логам пора «капиталить» мотор или нет — нельзя…посему — в ожидании оценки можете сильно не волноваться ).
1) для моторов 1.8Т с буквенными кодами APU, ANB, ATW, AUG, AWM, AWT (М7.X, имеющих датчик давления наддува) — 003/114/115 и 003/020/031 (два лога). после записи лога посмотреть на холостом ходу значения в первых двух полях 032-ой группы (запомнить/переписать, указать их в сообщении при выкладывании лога на форуме).
2) для мотора 1.8Т с буквенным кодом АЕВ (М3.X) — 002/013/024 и 002/024/025 (два лога). после записи лога посмотреть на холостом ходу значения в первых двух полях 008-ой группы (запомнить/переписать, указать их в сообщении при выкладывании лога на форуме). для мотора 1.8Т с буквенным кодом АЕВ (М5.Х) — 002/020/114. после записи лога посмотреть на холостом ходу значения в первых двух полях 032-ой группы (запомнить/переписать, указать их в сообщении при выкладывании лога на форуме).
3) для моторов 2.8 V6 с буквенными кодами ACK, APR (М3.X и М7.X) — 002/003/020 и 002/020/021 (два лога). после записи лога посмотреть на холостом ходу значения всех четырех полей 008-ой(ACK)/032-ой(APR) группы (запомнить/переписать, указать их в сообщении при выкладывании лога на форуме).
4) для моторов 2.8 V6 с буквенными кодами ATQ, AMX, BBG (МЕ 7.X) — 003/020/021 и 002/003/031 (два лога). после записи лога посмотреть на холостом ходу значения всех четырех полей 032-ой группы (запомнить/переписать, указать их в сообщении при выкладывании лога на форуме).
5) для моторов 2.0 (20V) с буквенным кодом ALT (МЕ 7.X) — 002/003/020 (один лог). после записи лога посмотреть на холостом ходу в первых двух полях 032-ой группы (запомнить/переписать, указать их в сообщении при выкладывании лога на форуме).
список будет обновляться по мере поступления информации и наличии свободного времени…
помните, что по ЛЮБОМУ из этих параметров вы сможете снять лог и оценить (при наличии знаний и/или добрых людей ) работу интересующей вас системы в требуемых условиях.
Ну и для тех кто дочитал до этого момента, поняв в себе прилив новых сил и знаний, выкладываем программу для самостоятельного просмотра снятых вами логов dp_logview_rus11.zip (если по каким то причинам эта версия не открывает ваши логи — пробуйте более раннюю версию dp_logview_rus.zip), за последнюю, адаптированную под криворукие русификаторы vag-com-а, версию этого вьюера логов уважение и почет Алексею kalex
Те, кто не смог подружиться с установкой/использованием выше указанного вьюера — могут воспользоваться онлайн сервисом для просмотра логов #
Самостоятельный анализ снятых логов на примере мотора 1.8Т:
Немного о той скромной практике расшифровки логов 1.8Т и интерпретации данных с различных датчиков наших авто. Сразу оговорка – все двигатели абсолютно разные по степени износа, качеству обслуживания и т.п. Поэтому материал крайне поверхностный и не претендует на полный объем информации. Итак:
Соленоид N75 – (смотрим в 025 АЕВ /114 APU, ANB, ATW, AUG, AWM, AWT и АЕВ с блоком управления М5.9 (американская версия)) – его сложная работа заключается в поддержании давления наддува (понижении или повышении) во всем диапазоне оборотов двигателя. Управляется ШИМ сигналом (широтно-импульсная модуляция) — соленоид при этом открывает то одну, то другую магистраль в соответствии с управляющим сигналом, степень открытия этого клапана меняется от 5% до 95%. В свою очередь клапан управляет клапаном вестгейта (WG) – «калиткой» — в «горячей» части турбины, приоткрывая ее для снижения наддува или закрывая – для увеличения.
В случае отсутствия сигнала (повреждена проводка, ошибка 01262) клапан N75 открыт и весь наддув подается на актуатор (механизм управления тягой калитки WG), который и стравливает его минуя горячую крыльчатку через клапан весгейта – наддува выше 0.3 не получим. При снятии и расшифровке логов обращать внимание на % тактирования клапана, который косвенно покажет производительность турбины: 90% и выше – система набирает наддув, после 2200 – 2300 об/мин % должен упасть до 50-60, что скажет о том, что турбокомпрессор в хорошем состоянии. Если в рабочем диапазоне от 2400 до 4700 скважность клапана не опустится ниже 75-80 %, можно говорить о том, что турбина уже «уставшая» либо в турботракте до интеркуллера присутствует дыра через которую стравливается не зарегестрированный датчик давления наддув. На чипе процент тактования будет выше: в районе 75% (турбокомпрессор работает с большей нагрузкой).
Еще один важный параметр, который рассматривается при расшифровке логов – лямбда регулирование – (смотрим в 008 АЕВ/031 ANB, ATW, AUG, AWM, AWT) – коррекция топливной смеси по сигналам с лямбда-зондов (ЛЗ). ЛЗ (являющийся датчиком кислорода) передает сигнал в ЭБУД о концентрации кислорода в отработавших газах, по сигналу ЛЗ оптимизируется состав рабочей смеси в сторону обогащения или обеднения. Правильная стехиометрическая смесь (это соотношение воздуха и топлива 14.7: 1 = L) даст не только паспортную мощность двигателя, правильную работу форсунок и катализатора, но и экономию топлива в спокойных режимах. Если L 1, значит налицо избыток воздуха, смесь бедная. Мощность при L=1,05 — 1,3 падает, но зато экономичность растет. При L > 1,3 смесь перестает воспламеняться, и начинаются пропуски в зажигании. Бензиновые двигатели развивают максимальную мощность при недостатке воздуха в 5-15% (L=0,85 — 0,95), тогда как минимальный расход топлива достигается при избытке воздуха в 10-20%% (L=1,1 — 1,2). То есть соотношение L при работе двигателя постоянно меняется и диапазон 0,9 — 1,1 является рабочим диапазоном лямбда-регулирования.
На практике правильной смеси нет — чаще в логах наблюдается обеднение, что говорит о проблемах с подачей топлива, не корректных показаниях ДМРВ, возможной негерметичности турботракта и т.п. Хорошие данные ЛЗ примерно такие: на минимальных оборотах: 1300-1500 – 0.950, постепенно «богатеет» до 0.750 в пике – при 5700 об/мин.
Данные 032 группы, при условии корректно работающих лямбда-зондов, следует рассматривать так (для 008 группы по аналогии):
Аддитив (032 группа 1-ое поле):
положительный (бедная смесь в режиме ХХ) — негерметичность впуского тракта, некорректная работа обратных клапанов в системе ВКГ, недостаточное давление топлива.
отрицательный (богатая смесь в режиме ХХ) — высокое давление топлива, негерметичность форсунок, датчик температуры ОЖ, некорректная работа обратных клапанов в системе ВКГ.
Мультипликатив (032 группа 2-ое поле):
положительный (бедная смесь в режиме нагрузок) — чаще всего недостаточная производительность топливного насоса или низкое давление в топливной рампе (работа РДТ), дыры в турботракте, некорректная работа дмрв.
отрицательный (богатая смесь в режиме нагрузок) — негерметичность впускного тракта после тубины, дмрв, некорректная работа форсунок (текут), датчик температуры ОЖ.