снятие логов что это такое
Инструменты для снятия логов с Android / iOS-устройств. Чтение и разбор
Привет! Сегодня стартует наш четвертый митап для тестировщиков, QAчественное общение. До 18:00 МСК на него все еще можно зарегистрироваться. А пока мы начинаем выкладывать доклады с предыдущего митапа, и начинаем с Ольги, старшего QA-инженера в компании red_mad_robot. Поговорим про мобильные устройства и про снятие логов с этих мобильных устройств, почитаем их и разберем, как вообще с ними работать.
Что вообще такое логи мобильного устройства? Логи – это записи либо сообщения в виде текста. У нас в этом тексте записываются все действия пользователя или как отвечает система на действия пользователя, соответственно, вся та информация, что вы делаете, куда нажимаете на самом устройстве, в приложении – всё это пишется в логи.
Какие логи в принципе бывают? Разделим их на две группы. Первая – это Crash logs, они подразумевают под собой отдельный файл, куда сыпется только информация об экстренном завершении программы. И второй вариант – это просто логи, файл, который является журналом событий, в нём хранятся все системные записи и ответы устройства на действия пользователя.
Уровни логирования
Хочу заметить, что эти уровни логирования больше под Android-логи, потому что именно разделение на Error, Warn, Info, Debug и Verbose в основном вы можете увидеть именно на логах с Android. Плюс, такая же информация чаще всего будет в ваших серверных логах, в принципе, будет довольно полезно изучить их. Что примечательно, каждый уровень включает в себя предыдущий. Если мы возьмем Verbose, фильтрацию по нему, например, то мы будем получать логи со всех предыдущих уровней, то есть абсолютно все логи. Разберем каждый подробно.
Первый – это Error. Ошибки уровня Error – ошибки, которые говорят о работе системы, на них надо очень быстро реагировать и всегда сообщать о них разработчикам.
Например, SpannableStringBuilder – это ошибка приложения, которая говорит нам о том, что текстовое поле, то есть Span, наш элемент, он не может быть нулевым либо пустым. Второй вариант – это системная ошибка ZeroHung. Данная ошибка говорит о том, что у нас происходит утечка памяти, она может быть как от какого-то действия с приложением, так и от самого приложения.
Следующий вариант – Warning. Это тоже ошибки, которые говорят о каком-то неожиданном поведении, которые требуют внимания, но они не такие важные, как error. Например, ошибка из приложения: мы пытаемся декодировать видео в нужное нам качество, в нужный формат, и у нас на этом происходит ошибка. Второй вариант, например, BroadcastQueue. Это ошибка системная, ошибка работы какого-то виджета на вашем устройстве. У меня это был Android Huawei, мне от системы сыпятся такие ошибки.
Следующий уровень – Info. Это уровень логов, на котором нам приходят записи чисто информационного характера о работе системы. Например, в этот уровень будут приходить ваши запросы, которые отправляют приложения на сервер. То есть он будет выглядеть так: http start, здесь вы увидите, какие header’ы отправляются, какое тело отправляется, если оно есть, и так же будете получать ответ от сервера в таком формате: json, key, value, ключ, значение и так далее. Заканчиваться он будет как http end. Далее, системный вариант ошибки или системный вариант лога о том, что сейчас мы намереваемся выключить экран. То есть, эта запись появляется, когда мы просто блокируем экран телефона, и он гаснет. Это у нас падает в информацию.
Далее, уровень Debug. Это тот уровень сообщений, в котором передается информация о процессах отладки или шаги каких-то крупных процессов, то, на что разработчики хотели обратить пристальное внимание. Например, мы просто нажали на качель громкости. Здесь будет, конечно, более подробно внутри этого лога – если вы его поймаете, то увидите конкретно что произошло: мы увеличили звук, уменьшили звук и на какое количество. И второй вариант, например, у вас приложение работает по WebSocket, и вам надо понять, подключились вы вообще или нет. Соответственно, вот это сообщение о том, что коннект произошел (на экране «b$b: WebSocket connected»).
Следующий уровень Verbose. Это уровень самого низкого приоритета, там сыпятся вообще все логи, там будет какая-то дополнительная информация, которая не вошла в Info, например. К примеру, у нас всплывает окно, мы его закрываем, у нас WindowManager, и мы здесь видим, что-либо добавилось, либо все удалилось. Далее, вся информация о геолокации. Например, у нас есть LocationProvider. В более расширенном варианте там будет полностью писаться ваша геолокация вплоть до долготы и широты. И третий пример, тоже связанный со звуком, то есть какой у нас звук и насколько он громкий. То есть, например, volume 10 это у нас максимальный звук, и мы его увеличили до такого варианта (на экране «AudioManager: getStreamVolume streamType: 3 volume: 10»). Очень похож на Info, но, я бы сказала, что более подробная информация на него передается.
Чем снимать логи?
Android
Первый инструмент – это Android Studio, в частности, его утилита Logcat. Что надо для того, чтобы начать снимать логи через Android Studio? Первое, конечно же, необходимо перевести устройство в режим разработчика. В настройках вы ищете номер вашего билда или операционной системы, в зависимости от того, на каком устройстве вы собираетесь смотреть, оно меняется от производителей. Нажимаете около 10 раз на эту информацию, и у вас появляется сообщение «Не желаете ли вы перевести ваше устройство в режим разработчика?». Нажимаете «Ок», и ваш телефон уже не такой обычный. Далее, вам надо подключить это устройство по USB к вашему компьютеру, конечно же, установить на сам компьютер Android Studio, он устанавливается как на Windows, так и на MacOS, тут проблем никаких нет.
Открывая Android Studio, выбираем вкладку Logcat. Под цифрой 1 то, где найти это сокровенное слово. Нажимая на него, переходим в сообщения в реальном времени. Под цифрой 2 окно, где мы выбираем телефон, с которого будем снимать логи. Соответственно, если ничего не подключено либо ваш телефон не виден, здесь вы ничего не сможете выбрать. Под цифрой 3 интересный момент: если вы хотите полностью снимать все логи (системные и со всех приложений, которые у вас сыпятся), не выбирайте здесь ничего. Если вы выберете какое-то конкретное приложение, которое debug’ное, у вас будут показываться логи исключительно по нему. Рядом с цифрой 3 вы видите слово Verbose – это уровень того лога, который вы хотите видеть. То есть, если вы выберете Error, будут только Error’ы. И под цифрой 4 у вас поле поиска. Это то поле, где вы сможете фильтровать выдачу по приложению, по уровню, по какой-то утилите, которая вам нужна, соответственно, это у нас regular выражение, и там все довольно просто ищется по совпадению. Вариант второго скриншота – это я уже выбрала конкретную сборку, и мы видим, что у нас по этой сборке сыпятся логи.
Дальше у вас в терминале, примерно так же, как и в Android Studio, будут в режиме реального времени сыпаться логи. Разберем, как их читать. Под цифрой 1 будет дата и время, когда пришла запись. Под цифрой 2 – маленький столбец, где вы видите буквы V, D, E, I и так далее. Это как раз те самые уровни нашего логирования Debug, Verbose, Warning или Info. В графе 3 – названия – инструменты, утилиты или части ОС, откуда идет сообщение, и, соответственно, его расшифровка – что конкретно у нас происходит. Конечно, выглядит это так, что в Android’е это все намного удобнее и приятнее, легко можно фильтровать. В Terminal’е фильтровать будет уже посложнее, надо будет менять саму команду, добавлять ключи, которые бы фильтровали выдачу по уровню либо по отдельному приложению.
Открываем его, как мы видим, информация похожа на ту, что в Terminal, единственное, как вы прекратили команду, этот файл больше не обновляется до тех пор, пока вы снова не повторите эту команду. Опять же, в таблице 1 мы видим дату и время прихода сообщения, таблица 2 – уровень наших логов, в таблице 3 мы видим, от какой части системы у нас сыпятся данные, лог и его расшифровка.
Конечно же, первое, о чем я хотела бы рассказать, это xCode и встроенный для него симулятор. К сожалению, xCode – программа только для MacOS. Чтобы снять с симулятора логи, нужно установить xCode, зайти в меню, открыть Developer Tools и симулятор. Симулятор – дополнительная программа, которая позволяет воспроизводить работу системы, если у вас нет физического девайса.
В этот симулятор мы устанавливаем нужное нам приложение, выбираем, какой конкретно IPhone, его размеры, разрешение и операционную систему. И уже в симуляторе выбираем пункт «Debug» и «Open System Log». Это выглядит так: я выбираю в самом симуляторе папку Debug и подвкладку Open System Log. Он точно так же идет в режиме реального времени, но они (логи) выведены по-другому, не так, как на Android.
Мы видим, что тут уже нет уровня логирования, есть дата и время. Цифра 2 – сообщение, что мы вообще видим. Мы видим, с какого устройства была снята информация.
В моем случае это имя моего Mac. Видим дополнительную запись, с какого элемента системы это сообщение пришло и его расшифровка. Например, в логах IOS придётся поковыряться чуть поподробнее, чем в Android.
Второй инструмент тоже связан с xCode, но он идет по другой «дорожке». Это Devices and Simulator. Устанавливаем xCode, подключаем устройство по USB, тут уже важно, чтобы было реальное устройство. В самом xCode открываем вкладку Window, там выбираем подвкладку Devices and Simulator. Нажимаем у устройства «Open Console». На панели видим название нашего устройства, какая у него операционная система, модель, и правее этой кнопки нам интересно «Open Console».
Под цифрой 1 мы видим все приложения, которые дополнительно установлены на наши устройства, в колонке под цифрой 2 – версия этого устройства, которую разработчик указывает. Третье пишется URL нашего устройства. То есть, например, у вашего разработчика, у вашей компании, у вашего приложения есть свой URL, по которому он ходит. Соответственно, здесь он отражен.
Как это все выглядит: здесь довольно удобно отслеживать, как сыпятся логи. Они тоже сыпятся в реальном времени, и, если их никак не фильтровать, они будут постоянно падать, но здесь все удобно смотреть. У нас есть время этого сообщения, процесс – это с какой части системы, приложения пришло сообщение. В колонке «Сообщение» мы видим подробное описание того, что происходит, что не так, вся сервисная системная информация. Что интересно, именно в Devices and Simulator есть поиск, который позволяет фильтровать выдачу. То есть, справа сверху мы можем написать название нашего приложения, и у нас все отфильтруется по процессу. Также мы можем приостановить выдачу по кнопке, и тогда логи перестануть хаотично и беспорядочно сыпаться (чтобы удобнее искать то, что вы хотите найти на устройстве).
Как снимать логи с IOS на Windows
Есть приложение iMazing, которое ставится на Windows и MacOS. Подключаете устройство по USB и в меню выбираете «показать консоль устройства». В целом, это приложение платное, однако, снять логи с устройства можно на триальной версии, она никак не ограничивается. У нас открывается следующее окно: мы видим, какое устройство у нас подключено, мы видим аккаунт, и в меню мы видим как раз «показать консоль устройства».
Если мы на нее нажмем, увидим следующее. Первый квадрат – это дата и время, когда мы получили это сообщение, второй пункт – от кого, с какого устройства, так как это уже реальный девайс, он называется у нас «IP-040». Далее, пишется, с какой части системы прилетело сообщение и его описание. Под цифрой 3 мы видим поле поиска. Мы можем фильтровать эту выдачу, можем остановить поток входящих логов по кнопке «пауза» и отфильтровать ее в поле поиска. Это поможет вам сконцентрироваться на конкретном запущенном приложении. Также у iMazing можно эти логи сохранять по соответствующей кнопке.
Вертим логи как хотим ― анализ журналов в системах Windows
Пора поговорить про удобную работу с логами, тем более что в Windows есть масса неочевидных инструментов для этого. Например, Log Parser, который порой просто незаменим.
В статье не будет про серьезные вещи вроде Splunk и ELK (Elasticsearch + Logstash + Kibana). Сфокусируемся на простом и бесплатном.
Журналы и командная строка
До появления PowerShell можно было использовать такие утилиты cmd как find и findstr. Они вполне подходят для простой автоматизации. Например, когда мне понадобилось отлавливать ошибки в обмене 1С 7.7 я использовал в скриптах обмена простую команду:
Она позволяла получить в файле fail.txt все ошибки обмена. Но если было нужно что-то большее, вроде получения информации о предшествующей ошибке, то приходилось создавать монструозные скрипты с циклами for или использовать сторонние утилиты. По счастью, с появлением PowerShell эти проблемы ушли в прошлое.
Основным инструментом для работы с текстовыми журналами является командлет Get-Content, предназначенный для отображения содержимого текстового файла. Например, для вывода журнала сервиса WSUS в консоль можно использовать команду:
Для вывода последних строк журнала существует параметр Tail, который в паре с параметром Wait позволит смотреть за журналом в режиме онлайн. Посмотрим, как идет обновление системы командой:
Смотрим за ходом обновления Windows.
Если же нам нужно отловить в журналах определенные события, то поможет командлет Select-String, который позволяет отобразить только строки, подходящие под маску поиска. Посмотрим на последние блокировки Windows Firewall:
Смотрим, кто пытается пролезть на наш дедик.
При необходимости посмотреть в журнале строки перед и после нужной, можно использовать параметр Context. Например, для вывода трех строк после и трех строк перед ошибкой можно использовать команду:
Оба полезных командлета можно объединить. Например, для вывода строк с 45 по 75 из netlogon.log поможет команда:
Для получения списка доступных системных журналов можно выполнить следующую команду:
Вывод доступных журналов и информации о них.
Для просмотра какого-то конкретного журнала нужно лишь добавить его имя. Для примера получим последние 20 записей из журнала System командой:
Последние записи в журнале System.
Для получения определенных событий удобнее всего использовать хэш-таблицы. Подробнее о работе с хэш-таблицами в PowerShell можно прочитать в материале Technet about_Hash_Tables.
Для примера получим все события из журнала System с кодом события 1 и 6013.
В случае если надо получить события определенного типа ― предупреждения или ошибки, ― нужно использовать фильтр по важности (Level). Возможны следующие значения:
Собрать хэш-таблицу с несколькими значениями важности одной командой так просто не получится. Если мы хотим получить ошибки и предупреждения из системного журнала, можно воспользоваться дополнительной фильтрацией при помощи Where-Object:
Ошибки и предупреждения журнала System.
Аналогичным образом можно собирать таблицу, фильтруя непосредственно по тексту события и по времени.
Подробнее почитать про работу обоих командлетов для работы с системными журналами можно в документации PowerShell:
PowerShell ― механизм удобный и гибкий, но требует знания синтаксиса и для сложных условий и обработки большого количества файлов потребует написания полноценных скриптов. Но есть вариант обойтись всего-лишь SQL-запросами при помощи замечательного Log Parser.
Работаем с журналами посредством запросов SQL
Утилита Log Parser появилась на свет в начале «нулевых» и с тех пор успела обзавестись официальной графической оболочкой. Тем не менее актуальности своей она не потеряла и до сих пор остается для меня одним из самых любимых инструментов для анализа логов. Загрузить утилиту можно в Центре Загрузок Microsoft, графический интерфейс к ней ― в галерее Technet. О графическом интерфейсе чуть позже, начнем с самой утилиты.
О возможностях Log Parser уже рассказывалось в материале «LogParser — привычный взгляд на непривычные вещи», поэтому я начну с конкретных примеров.
Для начала разберемся с текстовыми файлами ― например, получим список подключений по RDP, заблокированных нашим фаерволом. Для получения такой информации вполне подойдет следующий SQL-запрос:
Посмотрим на результат:
Смотрим журнал Windows Firewall.
Разумеется, с полученной таблицей можно делать все что угодно ― сортировать, группировать. Насколько хватит фантазии и знания SQL.
Log Parser также прекрасно работает с множеством других источников. Например, посмотрим откуда пользователи подключались к нашему серверу по RDP.
Работать будем с журналом TerminalServices-LocalSessionManager\Operational.
Не со всеми журналами Log Parser работает просто так ― к некоторым он не может получить доступ. В нашем случае просто скопируем журнал из %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx в %temp%\test.evtx.
Данные будем получать таким запросом:
Смотрим, кто и когда подключался к нашему серверу терминалов.
Особенно удобно использовать Log Parser для работы с большим количеством файлов журналов ― например, в IIS или Exchange. Благодаря возможностям SQL можно получать самую разную аналитическую информацию, вплоть до статистики версий IOS и Android, которые подключаются к вашему серверу.
В качестве примера посмотрим статистику количества писем по дням таким запросом:
Если в системе установлены Office Web Components, загрузить которые можно в Центре загрузки Microsoft, то на выходе можно получить красивую диаграмму.
Выполняем запрос и открываем получившуюся картинку…
Любуемся результатом.
Следует отметить, что после установки Log Parser в системе регистрируется COM-компонент MSUtil.LogQuery. Он позволяет делать запросы к движку утилиты не только через вызов LogParser.exe, но и при помощи любого другого привычного языка. В качестве примера приведу простой скрипт PowerShell, который выведет 20 наиболее объемных файлов на диске С.
Ознакомиться с документацией о работе компонента можно в материале Log Parser COM API Overview на портале SystemManager.ru.
Благодаря этой возможности для облегчения работы существует несколько утилит, представляющих из себя графическую оболочку для Log Parser. Платные рассматривать не буду, а вот бесплатную Log Parser Studio покажу.
Интерфейс Log Parser Studio.
Основной особенностью здесь является библиотека, которая позволяет держать все запросы в одном месте, без россыпи по папкам. Также сходу представлено множество готовых примеров, которые помогут разобраться с запросами.
Вторая особенность ― возможность экспорта запроса в скрипт PowerShell.
В качестве примера посмотрим, как будет работать выборка ящиков, отправляющих больше всего писем:
Выборка наиболее активных ящиков.
При этом можно выбрать куда больше типов журналов. Например, в «чистом» Log Parser существуют ограничения по типам входных данных, и отдельного типа для Exchange нет ― нужно самостоятельно вводить описания полей и пропуск заголовков. В Log Parser Studio нужные форматы уже готовы к использованию.
Помимо Log Parser, с логами можно работать и при помощи возможностей MS Excel, которые упоминались в материале «Excel вместо PowerShell». Но максимального удобства можно достичь, подготавливая первичный материал при помощи Log Parser с последующей обработкой его через Power Query в Excel.
Приходилось ли вам использовать какие-либо инструменты для перелопачивания логов? Поделитесь в комментариях.
Где посмотреть и как читать логи с ошибками сервера
Блоги, форумы, посадочные страницы и другие интернет-ресурсы представляют собой совокупность графического, текстового, аудио- и видео-контента, размещенного на веб-страницах в виде кода. Чтобы обеспечить к ним доступ пользователей через интернет, файлы размещают на серверах. Это аппаратное обеспечение (персональный компьютер или рабочая станция), на жестком диске которого и хранится код. Ключевые функции выполняются без участия человека, что актуально для всех типов оборудования, включая виртуальный выделенный сервер. Но это не означает, что контроль не осуществляется. Большинство событий, которые происходят при участии оборудования, пользователей и софта, включая ошибки, логи сервера фиксируют и сохраняют. Из этой статьи вы узнаете, что они собой представляют, зачем нужны, и как их читать.
Что такое логи
Это текстовые файлы, которые хранятся на жестком диске сервера. Создаются и заполняются в автоматическом режиме, в хронологическом порядке. В них записываются:
Посмотреть логи сервера может каждый, у кого есть к ним доступ, но непосвященному обывателю этот набор символов может показаться бессмысленным. Интерпретировать записи и получить пользу после прочтения проще профессионалу.
Классификация логов
Для каждой разновидности софта предусмотрены соответствующие файлы. Все логи сервера могут храниться на одном диске или даже на отдельном сервере. Существует довольно много разновидностей логов, вот наиболее распространенные:
Записи в системные журналы выполняет установленный софт.
Зачем нужны логи
Анализ логов сервера — неотъемлемая часть работы системного администратора или веб-разработчика. Обрабатывая их, специалисты получают массу полезных сведений. Используются в следующих целях:
После изучения информации можно получить точную статистику в виде сводных цифр, информацию о юзерах, выявить поведенческие закономерности пользовательских групп.