Лог данные что это
Как читать логи сервера
Что такое логи?
Краткая справка из Википедии:
Файл регистрации, протокол, журнал или лог (англ. log) — файл с записями о событиях в хронологическом порядке. Различают регистрацию внешних событий и протоколирование работы самой программы, источника записей (хотя часто всё записывается в единый файл). Например, в лог-файлы веб-сервера записывается информация, откуда пришёл тот либо иной посетитель, когда и сколько времени он провел на сайте, что там смотрел и скачивал, какой у него браузер и какой IP-адрес у его компьютера.
Для чего нужны логи?
Обычно при нормально работающем сайте лог-файлами мало кто интересуется, но когда начинает расти нагрузка на сервер, запускается рассылка спама, а сайт начинает вести себя довольно странно или изобиловать ошибками, без логов не обойтись.
Как включить запись логов?
Обычно для экономии дискового пространства ведение логов на хостинге выключено.
Приведу включение записи на примере панели управления хостингом Timeweb.
В панели управления переходим во вкладку «Логи», выбираем из выпадающего сайта нужный (если их несколько) и активируем ползунок «Лог доступа (access_log)»
Примерно через час, когда накопится достаточное количество записей, переходим в директорию сайта и скачиваем файл.
Открываем в любом текстовом редакторе (на примере второй столбец, с адресом сайта закрашен).
Разберем для примера строку № 49
Даже при беглом взгляде видно, что с адреса 85.93.93.102 идет множество запросов. Обращение было как раз по чрезмерной нагрузке на сайт. Как только адрес бота Linguee Bot был запрещен, нагрузка практически сразу вернулась в норму.
И все за несколько минут, благодаря логам; без них на выяснение причины понадобилось бы гораздо больше времени. Также были замечены обращения по адресам, содержавшим вставки типа xd0\xbe\xd1\x82\xd0\xb7\ …
Тот, кто занимается «лечением» сайтов, знает, что подобные запросы могут создавать запредельные нагрузки на сервер.
Иногда самые простые методы – самые действенные, а защита на уровне сервера самая надежная.
Что такое лог (log) программы.
Решая различные компьютерные задачи, можно не раз столкнуться с таким понятием как лог (с англ. log). Лог какой-то программы. Давайте попробуем разобраться что это такое и для чего это нужно.
Log (с англ. журнал). У большинства программ, которые установлены на вашем компьютере, есть этот самый журнал.
Т.е. это такой же обычный файл, который мы с вами можем создать на компьютере. Таким же образом программа работая на компьютере, может создать этот файл и вносить туда программным образом какие-то текстовые пометки.
Зачем же программе вести какие-то записи, какой-то журнал?
Дело в том, что если мы с вами будем следить за человеком, который работает на компьютере, мы можем сказать, что этот человек делал в конкретный момент времени, какие программы он запускал, какие ошибки он совершал при работе на компьютере и.т.д.
Но, если мы говорим о компьютерной программе, здесь все не так ясно. Все действия, которые производит программа, они скрыты от взгляда обычного пользователя. Они обычно происходят с такой большой скоростью событий, что человеческий глаз просто не успеет за все этим уследить.
Для того, чтобы отслеживать состояние какой-то программы. Что делала программа в какой-то конкретный момент времени, какие при этом возникали ошибки, кто с этой программой взаимодействовал и др. вопросы. Все события, которые происходили с этой программой, эта программа может записывать в специальный журнал, так называемый лог-файл.
В каждой записи содержится информация о том, что происходило с программой и когда это происходило.
Давайте подведем итог, что такое лог и зачем он нужен. Это текстовый файл, в который программа записывает какие-то события, которые с ней происходят. Благодаря этим событиям мы можем получить какую-то дополнительную информацию, что происходило с этой программой в какой-то определенный момент времени, получить отладочную информацию, чтобы легче устранить какую-то ошибку.
Надеюсь, что стало понятнее что такое лог-файл и зачем он нужен и вы теперь будете использовать этот журнал в своей работе.
Логи. зачем, почему, как.
Условия:
— в машине не более двух человек (вы — рулите, пассажир — снимает лог. либо вариант — вы рулите а лог снимается сам ).
— двигатель полностью прогрет
— выключен кондиционер (не горит кнопка АС на ручном кондиционере; климат-контроль в положении 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-ое поле):
положительный (бедная смесь в режиме нагрузок) — чаще всего недостаточная производительность топливного насоса или низкое давление в топливной рампе (работа РДТ), дыры в турботракте, некорректная работа дмрв.
отрицательный (богатая смесь в режиме нагрузок) — негерметичность впускного тракта после тубины, дмрв, некорректная работа форсунок (текут), датчик температуры ОЖ.
Как правильно писать логи (?)
Тема может и банальная, но когда программа начинает работать как то не так, и вообще вести себя очень странно, часто приходится читать логи. И много логов, особенно если нет возможности отлаживать программу и не получается воспроизвести ошибку. Наверно каждый выработал для себя какие то правила, что, как и когда логировать. Ниже я хочу рассмотреть несколько правил записи сообщений в лог, а также будет небольшое сравнение библиотек логирования для языков php, ruby и go. Сборщики логов и системы доставки не будут рассматриваться сознательно (их обсуждали уже много раз).
Есть такая linux утилита, а также по совместительству сетевой протокол под названием syslog. И есть целый набор RFC посвящённый syslog, один из них описывает уровни логирования https://en.wikipedia.org/wiki/Syslog#Severity_level (https://tools.ietf.org/html/rfc5424). Согласно rfc 5424 для syslog определено 8 уровней логирования, для которых также дается краткое описание. Данные уровни логирования были переняты многими популярными логерами для разных языков программирования. Например, http://www.php-fig.org/psr/psr-3/ определяет те же самые 8 уровней логирования, а стандартный Ruby logger использует немного сокращённый набор из 5 уровней. Несмотря на формальное указание в каких случаях должен быть использован тот или иной уровень логов, зачастую используется комбинация вроде debug/info/fatal — первый для логирования во время разработки и тестирования, второй и третий в расчёте на продакшен. Потом в какой то момент на продакшене начинает происходить что то не понятное и вдруг оказывается, что info логов не хватает — бежим включать debug. И если они не сильно нагружают систему, то зачастую так и остаются включенными в продакшен окружении. По факту остаётся два сценария, когда нужно иметь логи:
В языке Go в котором всё упрощено до предела, стандартный логер тоже прилично покромсали и оставили следующие варианты:
Я часто при написании программы с нуля повсеместно использую debug уровень для логирования с расчётом, что на продакшене будет выставлен уровень логирования info и тем самым сократится зашумлённость сообщениями. Но в таком подходе часто возникают ситуация, что логов вдруг становится не хватать. Трудно угадать, какая информация понадобиться, что бы отловить редкий баг. Возможно рационально всегда использовать по умолчанию уровень info, а в обработчиках ошибок уровень error и выше. Но если у вас сотни и больше сообщений лога в секунду, то тогда наверно есть смысл тонкой настройки между info/debug. В таких ситуациях уже имеет смысл использовать специализированные решения что бы не просаживать производительность.
Есть ещё тонкий момент, когда вы пишите что то вроде logger.debug(entity.values) — то при выставленном уровне логирования выше debug содержимое entity.values не попадёт в лог, но оно каждый раз будет вычисляться отъедая ресурсы. В Ruby логеру можно передать вместо строки сообщения блок кода: Logger.debug < entity.values >. В таком случае вычисления будут происходить только при выставленном соответствующем уровне лога. В языке Go для реализации ленивого вычисления в логер можно передать объект поддерживающий интерфейс Stringer.
После того, как разобрались с использованием уровней логов, нужно ещё уметь связывать разрозненные сообщения, особенно это актуально для многопоточных приложений или связанных между собой отдельных сервисов, когда в логах все сообщения оказываются вперемешку.
Типичный формат строки сообщения в логе можно условно разделить на следующие составные части:
Но с единым контекстом в рамках запроса возникает проблема с различными ORM, http клиентами или другими сервисами\библиотеками, которые живут своей жизнью. И ещё хорошо, если они предоставляют возможность переопределить свой стандартный логер хотя бы глобально, а вот выставить контекст для логера в рамках запроса зачастую не реально. Данная проблема в основном актуальна для многопоточной обработки, когда один процесс обслуживает множество запросов. Но например в фрэймворке Rails имеется очень тесная интеграция между всеми компонентами и запросы ActiveRecord могут писаться в лог вместе с глобальным контекстом для текущего сетевого запроса. А в языке Go некоторые библиотеки логирования позволяют динамически создавать новый объект логера с нужным контекстом, выглядит это примерно так:
После этого такой экземпляр логера можно передать как зависимость в другие объекты. Но отсутствие стандартизированного интерфейса логирования (например как psr-3 в php) провоцирует создателей библиотек хардкодить малосовместимые реализации логеров. Поэтому если вы пишите свою библиотеку на Go и в ней есть компонент логирования, не забудьте предусмотреть интерфейс для замены логера на пользовательский.
Логирование как инструмент повышения стабильности веб-приложения
техлид в Dunice
Каждый проект так или иначе имеет жизненные циклы: планирование, разработка MVP, тестирование, доработка функциональности и поддержка. Скорость роста проектов может отличаться, но при этом желание не сбавлять обороты и двигаться только вперёд у всех одинаковые. Перед нами встаёт вопрос: как при работе над крупным проектом минимизировать время на выявление, отладку и устранение ошибок и при этом не потерять в качество?
Существует много различных инструментов для повышения стабильности проекта:
В данной статье я хочу поговорить об одном из таких инструментов — логировании.
Логи — это файлы, содержащие системную информацию о работе сервера или любой другой программы, в которые вносятся определённые действия пользователя или программы.
Логи полезны для отладки различных частей приложения, а также для сбора и анализа информации о работе системы с целью выявления ошибок. Всё это необходимо для контроля работы приложения, так как даже после релиза могут встретиться ошибки, а пользователи не всегда сообщают о багах в техподдержку. Чем больше процессов у вас автоматизировано, тем быстрее будет идти разработка.
Допустим, есть клиентское приложение, балансировщик в лице Nginx, серверное приложение и база данных.
В данном примере не важны язык/фреймворк бэкенда, фронтенда или тип базы данных, а вот про веб-сервер Nginx давайте поговорим. В данный момент Nginx популярнее остальных решений для высоконагруженных сайтов. Среди известных проектов, использующих Nginx: Рамблер, Яндекс, ВКонтакте, Facebook, Netflix, Instagram, Mail.ru и многие другие. Nginx записывает логи по умолчанию, без каких-либо дополнительных настроек.
Логи доступны 2 типов:
Клиент отправляет запрос на сервер, и в данной ситуации Nginx будет записывать все входящие запросы. Если возникнут ошибки при обработке запросов, сервером будет записана ошибка.
2020/04/10 13:20:49 [error] 4891#4891: *25197 connect() failed (111: Connection refused) while connecting to upstream, client: 5.139.64.242, server: app.dunice-testing.com, request: «GET /api/v1/users/levels HTTP/2.0», upstream: «http://127.0.0.1:5000/api/v1/users/levels», host: «app.dunice-testing.com»
Всё, что мы смогли бы узнать в случае возникновения ошибки, — это лишь факт наличия таковой, не более. Это полезная информация, но мы пойдём дальше. В данной ситуации помог Nginx и его настройки по умолчанию. Но что же нужно сделать, чтобы решить проблему раз и навсегда? Необходимо настроить логирование на сервере, так как он является общей точкой для всех клиентов и имеет доступ к базе данных.
Первым делом каждый запрос должен получать свой уникальный идентификатор, что поможет отличить его от других запросов. Для этого используем UUID/v4. На случай возникновения ошибки, каждый обработчик запроса на сервере должен иметь обёртку, которая отловит эти самые ошибки. В этой ситуации может помочь конструкция try/catch, реализация которой есть в большинстве языков.
В конце каждого запроса должен сохраняться лог об успешной обработке запроса или, если произошла ошибка, сервер должен обработать её и записать следующие данные: ID запроса, все заголовки, тело запроса, параметры запроса, отметку времени и информацию об ошибке (имя, сообщение, трассировка стека).
Собранная информация даст не только понимание, где произошла ошибка, но и возможную причину её возникновения. Обычно для решения ошибки информации из лога достаточно, но в некоторых случаях может быть полезен контекст запроса. Для этого необходимо при старте запроса не только генерировать ID запроса, но и сгенерировать контекст, в который мы будем записывать всю информацию по работе сервера, начиная от результата вызова функции и заканчивая результатом запроса к базе данных. Такая реализация даст не только входные данные, но и промежуточные результаты работы сервера, что позволит понять причину появления ошибки.
При микросервисном подходе система не ограничивается одним сервером, и при запросе от клиента происходит взаимодействие нескольких серверов внутри системы. Наша реализация логирования на сервере позволит выявить дефект в работе конкретного ресурса, но не позволит понять, почему запрос вернулся с ошибкой. В данной ситуации поможет трассировка запросов.
Трассировка — процесс пошагового выполнения программы. В режиме трассировки программист видит последовательность выполнения команд и значения переменных на каждом шаге выполнения программы.
В нашем случае требуется передавать метаинформацию о запросе при взаимодействии серверов и записывать логи в единое хранилище (такими могут быть ClickHouse, Apache Cassandra или MongoDB). Такой подход позволит привязать различные контексты серверов к уникальному идентификатору запроса, а отметки времени — понять последовательность и последнюю выполненную операцию. После этого команда разработки сможет приступить к устранению.
В некоторых случаях, которые встречаются крайне редко, к ошибке приводят неочевидные факторы: компилятор, ядро операционной системы, конфигурации сервера, юзабилити, сеть. В таких случаях при возникновении ошибки потребуется дополнительно сохранять переменные окружения, слепок оперативной памяти и дамп базы. Такие случаи настолько редки, что не стоит беспочвенно акцентировать на них внимание.
С сервером разобрались, что же делать, если у нас сбои даёт клиент и запросы просто не приходят? В такой ситуации нам помогут логи на стороне клиента. Все обработчики должны отправлять информацию на сервер с пометкой, что ошибка с клиента, а также общие сведения: версия и тип браузера, тип устройства и версия операционной системы. Данная информация позволит понять, какой участок кода дал сбой и в каком окружении пользователь взаимодействовал с информацией.
Также есть возможность отправлять уведомления на почту разработчикам, если произошли ошибки, что позволит оперативно узнавать о сбоях в системе. Такие подходы активно используются в системах мониторинга и аналитики логов.
Способы, которые мы рассмотрели в статье, помогут следить за качеством продукта и минимизируют затраты на исправление недочётов в системе.