AIDL (Android Interface Definition Language) и коммуникация между процессами (IPC)
Базовые понятия
Service – это компонентAndroid приложения без интерфейса пользователя, предназначенныйдля осуществления ресурсоемких и/или длительных операций.
Типы Android сервисов
Архитектура приложения
Разработанное нами приложение — галерея для Android которая позволяет просматривать фотографии из карты памяти и сетей обмена фотографиями.
Основными задачами сервиса в данном приложении являются: получение метаданных (информации о альбомах, фотографиях, друзьях), мониторинг их обновлений и всего остального, что с ними связано. Сервис постоянно хранит актуальную информацию и готов в любой момент отдать ее основной Activity для отображения.
Ниже будут приведены ключевые участки кода и описан процесс создания примитивного сервиса:
Для осуществления общения между сервисом и Activity используются следующие AIDL файлы:
IDataSourceService.aidl – интерфейс сервиса:
IDataSourceServiceListener.aidl – интерфейс слушателей сообщений от сервиса:
Данные передаются с помощью двух классов, которые реализуют интерфейс Parcelable — Album и Photo. Декларация aidl файлов для этих классов обязательна. При конвертации из примитивов ОС в java Объекты используется класс Creator.
Для записи данных используется метод writeToParcel интерфейса Parcelable:
Также существует вспомогательный метод describeContents, его задача описать специальные случаи/состояния объектакоторые когут использоватся при сериализации и десириализации:
Методы чтения данных оказались недостойными вынесения их в состав интерфейса Parcelable, но стандартная практика – использование Creator вместе с:
Activity запускает сервис (делая его таким образом StartedService) в методе onCreate
На этом же этапе жизненного цикла она соединяется с сервисом:
Процесс соединения с сервисом асинхронный, в нем учувствует реализация интерфейса ServiceConnection. Во время соединения с сервером Activity регистрируется в сервисе как слушатель сообщений, с помощью имплементации IDataSourceServiceListener.Stub:
Надеюсь выложенные исходные тексты помогут разработчикам ознакомится с AIDL. Архив с полным примером тут.
Основное приложение доступно для ознакомления в Android Market.
Cellular Modem Information » Qualcomm Linux Modems by Quectel & Co
IPC Logging¶
This is a non-standard/non-mainline high-speed in-memory logging sub-system that is present in the Qualcomm Linux kernel variants to perform logging of the IPC (inter processor communication) related drivers.
User Interface¶
The user interface to obtain the logs is implemented via debugfs below /sys/kernel/debug/ipc_logging
For each ipc log context (see below) there is one sub-directory. On the EC25 this looks like:
The format of the log lines is like this:
Official documentation¶
Below are excerpts from Documentation/arm/msm/msm_ipc_logging.txt :
Introduction¶
This module will be used to log the events by any module/driver which enables Inter Processor Communication (IPC). Some of the IPC drivers such as Message Routers, Multiplexers etc. which act as a passive pipe need some mechanism to log their events. Since all such IPC drivers handle a
large amount of traffic/events, using kernel logs renders kernel logs unusable by other drivers and also degrades the performance of IPC drivers. This new module will help in logging such high frequency IPC
driver events while keeping the standard kernel logging mechanism intact.
Hardware Description¶
This module does not drive any hardware resource and will only use the kernel memory-space to log the events.
Design Goals¶
IPC Log Context¶
This module will support logging by multiple drivers. To differentiate between the multiple drivers that are using this logging mechanism, each driver will be assigned a unique context by this module. Associated with each context is the logging space, dynamically allocated from the kernel memory-space, specific to that context so that the events logged using that context will not interfere with other contexts.
Event Logging¶
Every event will be logged as a combination. Type field identifies the type of the event that is logged. Size field represents the size of the log information. Value field represents the actual information being logged. This approach will support both id-based logging and stream-based logging. This approach will also support logging sub-events of an event. This module will provide helper routines to encode/decode the logs to/from this format.
Encode Context¶
Encode context is a temporary storage space that will be used by the client drivers to log the events in format. The client drivers will perform an encode start operation to initialize the encode context data structure. Then the client drivers will log their events into the encode context. Upon completion of event logging, the client drivers will perform an encode end operation to finalize the encode context data structure to be logged. Then this updated encode context data structure will be written into the client driver’s IPC Log Context. The maximum event log size will be defined as 256 bytes.
Log Space¶
Each context (Figure 1) has an associated log space, which is dynamically allocated from the kernel memory-space. The log space is organized as a list of 1 or more kernel memory pages. Each page (Figure 2) contains header information which is used to differentiate the log kernel page from the other kernel pages.
In addition to extracting logs at runtime through DebugFS, IPC Logging has been designed to allow extraction of logs from a memory dump. The magic numbers, timestamps, and context offset are all added to support the memory-dump extraction use case.
Design¶
Alternate solutions discussed include using kernel & SMEM logs which are limited in size and hence using them render them unusable by other drivers. Also kernel logging into serial console is slowing down the performance of the drivers by multiple times and sometimes lead to APPs watchdog bite.
SMP/multi-core¶
This module uses spinlocks & mutexes to handle multi-core safety.
Performance¶
Dependencies¶
This module will partially depend on CONFIG_DEBUGFS, in order to dump the logs through debugfs. If CONFIG_DEBUGFS is disabled, the above mentioned helper functions will perform no operation and return appropriate error code if the return value is non void. Under such circumstances the logs can
only be extracted through the memory dump.
Лог файлы Linux по порядку
Невозможно представить себе пользователя и администратора сервера, или даже рабочей станции на основе Linux, который никогда не читал лог файлы. Операционная система и работающие приложения постоянно создают различные типы сообщений, которые регистрируются в различных файлах журналов. Умение определить нужный файл журнала и что искать в нем поможет существенно сэкономить время и быстрее устранить ошибку.
Журналирование является основным источником информации о работе системы и ее ошибках. В этом кратком руководстве рассмотрим основные аспекты журналирования операционной системы, структуру каталогов, программы для чтения и обзора логов.
Основные лог файлы
Все файлы журналов, можно отнести к одной из следующих категорий:
Для каждого дистрибутива будет отдельный журнал менеджера пакетов.
И немного бинарных журналов учета пользовательских сессий.
И другие журналы
Так как операционная система, даже такая замечательная как Linux, сама по себе никакой ощутимой пользы не несет в себе, то скорее всего на сервере или рабочей станции будет крутится база данных, веб сервер, разнообразные приложения. Каждое приложения или служба может иметь свой собственный файл или каталог журналов событий и ошибок. Всех их естественно невозможно перечислить, лишь некоторые.
В домашнем каталоге пользователя могут находится журналы графических приложений, DE.
/.xsession-errors — Вывод stderr графических приложений X11.
/.xfce4-session.verbose-log — Сообщения рабочего стола XFCE4.
Чем просматривать — lnav
Недавно я обнаружил еще одну годную и многообещающую, но слегка еще сыроватую, утилиту — lnav, в расшифровке Log File Navigator.
Установка пакета как обычно одной командой.
Навигатор журналов lnav понимает ряд форматов файлов.
Что в данном случае означает понимание форматов файлов? Фокус в том, что lnav больше чем утилита для просмотра текстовых файлов. Программа умеет кое что еще. Можно открывать несколько файлов сразу и переключаться между ними.
Программа умеет напрямую открывать архивный файл.
Показывает гистограмму информативных сообщений, предупреждений и ошибок, если нажать клавишу . Это с моего syslog-а.
Кроме этого поддерживается подсветка синтаксиса, дополнение по табу и разные полезности в статусной строке. К недостаткам можно отнести нестабильность поведения и зависания. Надеюсь lnav будет активно развиваться, очень полезная программа на мой взгляд.
Учимся читать логи ваших бекапов
Скажите честно, в своей практике вам чаще приходилось сталкиваться с логами, напоминающими чей-то поток сознания, или всё же это были красивые структурированные файлы, на которые любо-дорого смотреть? Надеюсь, что второе. В наших продуктах, само собой, мы тоже стремимся идти по второму пути, однако необходимость зафиксировать большое количество процессов накладывает свой отпечаток. Так что сегодня мы научимся не “читать книгу и видеть фигу”, а бесстрашно открывать любой лог Veeam Backup & Replication и видеть его внутреннюю красоту.
Перед прочтением этой статьи настоятельно рекомендую предварительно ознакомиться со статьёй-глоссарием, дабы понимать используемую терминологию. Затем прочитать эту статью про источники данных для логов. А затем ещё и эту, дабы понимать, в какой лог ради чего следует залезать.
Когда читаешь логи, очень важно держать в голове и применять шесть простых правил.
Правило первое: В логах тьма ошибок с ворнингами и это нормально. Не надо бросаться на первую попавшуюся ошибку и пытаться с ней что-то сделать. Как мы помним из прочитанных ранее статей, в логах фиксируется вся информация, которая приходит от разнородных систем, включая внешние. Ошибка может обозначать переход между режимами или быть банальной проверкой. Вот пример:
Правило второе: Когда читаете лог, не надо смотреть только на последнюю в списке ошибку. Даже если она подсвечена в репорте, упавшем на почту. Причина её появления запросто может быть на пару экранов (и десяток других ошибок) выше. Например, в упавшем на почту HTML репорте видим ошибку «Microsoft SQL server hosting the configuration database is currently unavailable». Открываем лог джобы и видим, что последняя ошибка в логе прямо нам говорит “Не могу подключиться к SQL серверу, потому что ”.
Сразу хочется победно прокричать “Ага!” и побежать чинить связь до SQL сервера, перезагружать его, трясти за бампер и пинать по колесу. Однако если попробовать разобраться и отмотать лог ближе к началу, там обнаруживаются строки:
Из чего сразу становится понятно, что со связью до базы всё хорошо — а вот что плохо, так это то, что VBR не может выполнить какую-то кверю, и копать надо в эту сторону.
Правило третье: Редкая ошибка локализуется внутри одного конкретного лога. Изучение соседних логов на тот же момент времени позволяет собрать намного больше информации. Хрестоматийный пример — это лог джобы, где нам просто говорят, что возникала такая-то ошибка в такой-то таске. Какие-то выводы, конечно, мы сделать уже можем, но лучше открыть лог таски и получить более подробное описание случившегося бедствия. И если уж совсем ничего не понятно, то нам на помощь приходят логи агентов, в которых вся ситуация будет разобрана крайне подробно. Но тут действует правило “Чем дальше в лес, тем более узким и специфичным становится лог”. А ещё часть инфы может всплыть в сервисных логах, часть в виндовых ивентах и так далее.
Вот, например, берём типичный лог упавшей джобы:
Типичный никчёмный Failed to call RPC function, из которого максимум, что можно понять — что не удалось провзаимодействовать с транспортным агентом. Однако если вспомнить, что транспортный агент управляется транспортным сервисом (известен в документации как Datamover) и заглянуть в его лог (Svc.VeeamTransport.log) на хосте, где он запускался, то можно обнаружить:
То есть агент был принудительно выключен сервисом после неудачной попытки записать что-то на таргет, но к VBR эта информация по какой-то причине не пришла. Теперь мы хотя бы знаем, в какую сторону копать.
Правило четвёртое: Если в логах видим, что ошибка происходит где-то за границами компонентов VBR, значит, искать их причину надо тоже за границами компонентов VBR. Veeam хоть и старательно логирует все приходящие к нему события, однако ещё больше их(событий) остаётся на целевой системе. Типичным примером здесь будет создание VSS снапшота. По большому счёту, Windows отдаёт информацию на уровне “получилось или нет что-то сделать”, из чего крайне редко получается вычленить причину, почему же не получилось. Однако внутри виндовых ивентов можно найти множество событий, прямо указывающих на проблему. Главное — всегда тщательно сопоставлять время в логах от разных систем. Помним, что у VBR своё время, у vSphere всегда UTC+0, а виндовые ивенты показываются в локальном времени машины, на которой их смотрят. Типичные примеры экспорта внешних логов — для Windows и для Microsoft SQL.
Правило пятое: Следи за тредами (они обозначаются как ) и распутывай клубок последовательно! Многие вещи могут происходить параллельно, и если просто читать логи линия за линией, то можно прийти к неправильному выводу. Особенно это важно, если джоба кажется зависшей и надо понять, что именно в ней зависло.
Вот типичный лог для этой ситуации:
То есть этот тред посвящён совершенно другому агенту с id bf19! Открываем лог этого агента и видим:
Значит, проблема в битом VHDX и надо искать методы его лечения.
Правило шестое: Не получается, непонятно, кажется, что вот-вот, но идёт третий день без сна и всё никак — звони в сапорт! Veeam — огромный продукт, где есть тысячи нюансов, нюансы для нюансов и прочих сокровенных знаний, которые никогда не понадобятся 99,99% населения этой планеты. Однако именно этих знаний в большинстве случаев и не хватает, чтобы успешно найти причину неисправности самому. Сапорт Вима совсем не просто так получает свою зарплату и считается одним из лучших в IT-индустрии. А ещё он русскоязычный и доступен по телефону 😉
Смело открываем лог
И вот настал тот прекрасный момент, когда мы наконец-то готовы открыть свой первый лог. А любой уважающий себя файл начинается с некоего заголовка, где собрана вся основная информация. Чаще всего нас, конечно же, будут интересовать логи джоб и тасок, так что рассмотрим пример с ними.
Начало не вызывает никаких особых вопросов. Мы видим, как называется машина, на которой установлен VBR, и под каким пользователем запускается Veeam Backup Service.
Важный пункт — это версия запускающегося модуля.
Если ранее были установлены какие-то хотфиксы или приватные патчи, это сразу будет видно по номеру версии. В описании каждого патча, каждого релиза всегда обязательно указывается, на какую версию его следует устанавливать. Если вы словили какую-то багу, для которой вам выдали приватный фикс, то не надо затем сверху накатывать новый общий патч или свежий релиз. Никаких гарантий работоспособности в данном случае вы не получите.
Затем идёт перечисление всех сетевых интерфейсов и их IP-адреса. Также по названию карты зачастую можно понять, стоит ли Veeam на виртуальной машине или на физической. Хотя вы и сами наверняка это знаете, но может пригодиться.
И завершается всё информацией о времени и зоне, относительно которой указываются все цифры. Для географически разнесённых инфраструктур это критически важная часть. Автор сам несколько раз напарывался на ситуацию, когда старательно ищешь суть проблемы, а потом понимаешь, что искал на несколько часов позже или раньше.
Теперь, когда заголовок прочитан, давайте на примере бекапа и реплики посмотрим, что нас ожидает в логе любой джобы. Я не буду объяснять каждую строчку, иначе мы отсюда через месяц только разойдёмся. Просто легкая пробежка по общему принципу.
Первым делом джоба должна перечитать свои собственные настройки, дабы вообще знать, что ей требуется сделать.
Затем формируется список объектов, участвующих в бекапе.
Для всех объектов надо заблокировать необходимые ресурсы (файлы с бекапами, например) и убедиться, что никто другой не пытается с ними работать в этот момент времени.
Потом выясняем, где какая машина находится, что с ней можно сделать, какой транспортный режим использовать и на какую прокси назначить.
После чего можно запускать отдельные таски и ждать отчёта об их успешном (хочется верить, что да) выполнении.
И в конце, когда все таски отчитались, наступает тяжелая пора проверки ретеншенов. Удаляются старые точки, запускаются синтетические трансформы и прочий страшный сон для ваших СХД.
Когда всё закончилось успехом, надо везде рапортовать про это, записать в базу новую информацию и счастливо заснуть до следующего запуска. Конечно, строго говоря, на фоне будет происходить масса разнообразных и увлекательных сервисных вещей, но сегодня не об этом.
Теперь давайте обратим внимание на таски. Каждая таска запускается с чётко поставленной целью забекапить конкретную машину. Значит, после запуска её дело — это суметь подключиться к хосту, запустить агентов (в документации известны как data movers), проверить, что есть связь между компонентами, и совершить процесс передачи информации от хранилища вашего хоста до бекапного репозитория с необходимыми трансформациями по пути. Сжатие, разжатие, дедупликация, шифрование и так далее.
Соответственно, начинаем поиски проблемы широкими мазками, а именно — выясняем, на каком моменте всё сломалось. В этом нам помогает волшебное словосочетание has been completed. В общем случае таски рапортуют таким образом:
14 объектов — это так называемые OiB, Object in Backup. Эта информация дублируется в логе джобы после завершения каждой таски с пометкой о том, сколько тасок уже завершилось. А в самом конце джоба должна заканчиваться полным отчётом.
Другая полезная фраза — это Preparing point. Позволяет нам понять, какой тип бекапа сейчас будет создаваться.
В случае создания полного бекапа, в народе именуемого фульник (Full или Active full), создаётся следующая запись:
Инкрементальный проход выглядит вот так:
И реверс инкремент:
Для Synthetic full своей особой записи не существует! Она начинает с создания обычного инкремента, поэтому надо искать ниже в логе запись «Creating synthetic full backup». Или пройтись по «Preparing oib» в логе таски.
vSphere
Теперь переходим к специфике гипервизоров, ибо, как можно легко догадаться, VMware и Hyper-V под капотом устроены даже приблизительно не одинаково, так что и работать с ними надо по-разному.
И начнём мы именно с VMware. Для начала просто посмотрим версию хоста по слову Build- в логе джобы. Так мы сможем узнать версию и номер билда хоста с машиной. Если хост был добавлен как часть Vcenter, бонусом получаем поле source host type.
Эта же информация дублируется в момент проверки доступных режимов работы прокси.
В логе соответствующей таски это всё тоже имеется, только там это часть здоровенной XML, так что копипастить я её не буду. Зато там есть даже более интересная строка Host content info:
Там же, в логе таски, можно получить информацию о дисках и датасторах по строке Disk: label
Как мы видим, нас интересует ALLIN_PURE_GDI, поэтому переключаемся на лог джобы и видим:
Ещё бывает «Backup VM ‘VMname’ is DirectNFS compatible», но это не значит, что наша машина точно на NFS шаре.
Жизненный цикл vSpehere снапшотов
…и места, где они обитают.
Часто (а на самом деле практически всегда) понимать, в какой момент создавался снапшот, в какой был удалён и что с ним происходило, весьма важно для получения целостной картины мира реплик и бекапов. Поэтому открываем лог таски и ищем в нём API вызовы для создания и консолидации (удаления) снапшотов. Создание снапшота отлично ищется по Create snapshot
Удаление снапшота ищется по Removing snapshot.
Здесь что хочется отметить: по загадочной причине в логе VMware.log зачастую нет никакой информации об ошибках произошедших во время создания/удаления снапшота. Поэтому полную картину мира надо восстанавливать по всем логам vSphere, включая логи VPXD и HOSTD.
С точки зрения vSphere, в VMware.log обычно есть только события на создание снапшота:
Причём снапшоты, сделанные вручную, логируются несколько иначе, но это детали.
Зато как только мы заводим разговор о репликах, всё становится ещё веселее. VMware.log ведётся только когда виртуалка работает. А для реплицированных машин нормальное состояние — быть выключенными. Так что этот лог вам никак помочь не может. Поэтому здесь нам понадобятся логи vCenter или хоста. Самый простой способ их добыть — это ПКМ на vCenter > Export System Logs. В открывшемся визарде обязательно выбираем «Include vCenter server logs» и дожидаемся скачивания результата. Логи влёгкую могут весить несколько гигабайт, а скачиваться будут через браузер. Так что советую делать это на машине максимально близкой к VC. Самое интересное для нас внутри, это:
ESXi: В архиве проходим по /var/run/log/ и находим hotsd.log. Рядом будут лежать упакованные более ранние версии.
VC: ищем файлы vpxd-xxx.log по пути /var/log/vmware/vpxd.
Теперь давайте сравним, как будут выглядеть записи об одних и тех же операция в логе VBR, логе vpxd, и логе hostd. Здесь мы опустим моменты создания снапшота на исходной машине, так как нас интересует только реплика.
Итак, поскольку последний дельта-файл реплики доступен для записи и мы не можем гарантировать, что там никто ничего не натворил (горячий привет всем любящим включать реплицированные машины прямо с хоста), первым делом мы должны откатить все эти изменения:
После успешного отката (двусмысленные фразы, что вы делаете, аха-ха-ха, прекратите) нам надо зафиксировать успех, т.е. сделать текущую дельту доступной только для чтения. Для этого создаём ещё один снапшот сверху:
Теперь можно и данные передавать. Когда этот процесс закончится, наступает пора откатиться на “защитный” снапшот, дабы удалить всё, что могло попасть в его дельту (снова горячий привет любителям включать машины невовремя, ага) и удалить его. Благо больше он нам не нужен.
И обязательный десерт — применение ретеншн политики. В общем случае это слияние базового диска и самой старой дельты. Только учтите, что эта информация отображается уже в логе джобы, а не таски.
Ищем компоненты
Снапшоты — это, конечно, очень хорошо, однако неплохо бы было понимать, что же именно в нашей инфраструктуре принимало участие в создании реплики или бекапа. А поскольку процесс репликации имеет более сложную структуру, то и разбираться будем на его примере.
На самом деле с ходу найти все участвовавшие компоненты может быть сложно, так как в логе нет единого места с их перечислением. Банальный пример: прокси выбираются в момент прохода джобы, исходя из возможностей инфраструктуры. Однако если знать, как искать, то всё находится довольно легко.
И да, это будет опять vSphere. Получить общую информацию проще всего в логе таски по строке Processing object
Чуть ниже уже будет более подробная информация в строке VM information. Как видим, для машин, добавленных через VC, указывается, в том числе, и хост.
Далее следует масса информации про выбор прокси и доступных режимов работы. Всё это происходит под тегом [ProxyDetector]. Общий алгоритм таков: берём и проверяем возможность скачать диски поочередно в режимах SAN > HotAdd > NBD. Каким способом получилось, так и качаем. Начинается всё веселье в этом моменте:
И дальше полная вакханалия проверок, так как проверяются все возможные прокси на все возможные режимы. Да ещё и два раза — как таргет и как сорс. Единственное исключение возможно только в том случае, если в настройках джобы указан конкретный прокси и запрещены все режимы кроме одного.
Какой прокси, в каком режиме и куда был назначен — надо смотреть в логе каждой таски по фразе Preparing for processing of disk
Также полезное можно найти в логе /Utils/VMC.log. С ним только одна сложность: вся информация внутри представлена в виде ID. Никаких имён и человекочитаемых названий. Слава роботам!
Если мы говорим про Direct SAN режим, то самое важное — это корректность сопоставления LUN’ов с их номерами. В данном примере виден общий смысл происходящего: сначала получаем номера лунов, проверяем все подключённые к прокси луны на предмет нахождения идентичного и в случае успеха работаем с ним.
Эти же номера можно проверить самим. В vSphere клиенте — в разделе Host > Configure > Storage devices, а в Windows посмотреть в стандартный Disk Manager. Все номера должны совпадать.
Репозиторий
Если репозиторием выступает сетевая шара, то будет написан её путь:
Если углубиться в поисках, то по Setting repository можно найти не только ID и название, но и под какой учёткой мы туда ходим. Если вы используете не одну учётку для всего на свете, то запросто можно промахнуться в визарде и долго искать причину, почему не удаётся подключиться к серверу.
WAN акселераторы
В таск логе имена будут указаны уже в явном виде
Что за второе рождение упоминалось в начале? Это так называемый High Bandwidth режим. Если раньше смысл от акселераторов был только на действительно медленных линках (очень медленных линках), то в v10 был введён новый режим, обеспечивающий прирост в производительности на скоростях до 100 Мб/с. Включается он отдельной галочкой, а в логах таски это видно вот по этим строкам:
В первой строке указаны результаты проверки, включён ли необходимый режим на обоих WA — мы видим, что нет, и выбираем классическую версию.
Просто полезные слова для поиска
Но хватит уже упражняться в копипасте логов, давайте в конце перечислю некоторые места в логах, на которые может быть полезно обратить внимание.
Backup/Replication Job log
«> Error» или «> Warning» — здесь что-то произошло, на что точно надо обратить внимание. Не обязательно всё сломалось именно тут, но что-то здесь точно произошло. Возможно даже пошло не так, как планировалось.
Job Options: — здоровенная XML, где перечислены все настройки задания. После неё обычно идёт раздел VSS Settings, где перечислены настройки VSS.
[RetentionAlgorithm] — момент отрабатывания ретеншн алгоритма. Тут удаляются ставшие ненужными точки или синтезируются новые.
[JobSession] Load: — ботлнеки, про которые в нашем блоге есть отдельная статья.
Preparing point — узнаём, в каком режиме создаётся бекап (инкремент, реверс инкремент или фул).
Starting agent — узнаём, какой агент когда был запущен, и по его ID идём читать соответствующий ему лог.
VMware Job
[ProxyDetector] — весь процесс выбора рабочих прокси и режима транспорта. Технически, в Hyper-V будет всё то же самое, только с гораздо меньшим количеством деталей.
[SanSnapshots] — блок создания и работы с SAN-снапшотами.
VM task — детальная информация о каждой конкретной машине в задании.
Hyper-V Job
VM tasks — в отличие от VMware тут не будет исчерпывающей информации, однако как отправная точка для поиска истины — самое то.
VM guest info — много информации о гостевой машине и самом хосте. Однако имя машины надо предварительно посмотреть в секции Creating task, которая немного выше.
Task log
Starting Disk — можно узнать, когда началась обработка конкретного диска. Очень полезно, если у машины их много, включён parallel processing и всё несколько запутано.
Operation was canceled by user — где-то рядом ещё должно быть “Stop signal has been received”. Указывает на реальное время остановки бекапа и может означать всё что угодно. Если время подозрительно красивое, вроде 06:00:00, а юзер мамой клянётся, что ничего не трогал, то 99,99% — установлено Backup Window и ваше время истекло.
Starting agent — опять же, получаем ID нужного агента и далее смотрим прицельно.
Preparing oib — указывает, готовится ли бекап машины в инкрементальном виде или фул.
.source. shows — показывает, на каком сервере будет запущен передающий агент (Source Proxy).
.target. — показывает, на каком сервере будет запущен принимающий агент (Repository/Target proxy).
VMware Task
VM information: Практически вся информация, которую можно узнать про целевую машину.
[VimApi] Create или [VimApi] Remove — создание и удаление снапшотов. Через [VimApi] делается ещё несколько действий, так что не удивляйтесь.
Hyper-V Task
Files to process — краткий список того, что будет забекаплено.
[RTS] — весь процесс создания снапшотов и их удаления.
Agent log
Err | или WARN| — то же самое, что и > Error > Warning. В Err действительно есть пробел перед палочкой, это не опечатка.
Traffic size — размер всей переданной информации.
stat – размер файла бекапа.
Backup service log
== Name — показывает абсолютно все джобы и их текущее состояние (работает или остановлена). Между == и названием два пробела.
[Scheduler] Ready to start jobs: — список джоб, которые будут запущены в соответствии с расписанием.
by user — эта пометка делается, если юзер что-то сделал сам.
Backup copy job log
[OibFinder] — покажет вам, какие репозитории и точки восстановления были исключены из обработки. Иногда даже может сказать, почему.
[CryptoKeyRecryptor] — позволит понять, менялся ли на этом проходе юзер-пароль или энтерпрайз-ключ.
Surebackup
Backup point или Replica point — время, когда была создана проверяемая точка.
[ ] [PowerOnVm] [StableIp] — моменты включения и выключения машин в лаборатории.
И на этом пока предлагаю остановиться. Так как список этот можно продолжать долго и никогда не закончить. Инженер техподдержки учится премудростям логочтения и устройства Veeam примерно три месяца, так что охватить всю широту наших глубин в рамках серии статей задача утопическая. Да и новая версия не за горами и часть информации может стать более невалидной.
Поэтому, если есть вопросы, то добро пожаловать в комментарии. Если есть предложение по написанию подобной статьи на какую-то конкретную тему — адрес тот же, комментарии.
Засим позвольте откланяться и до новых встреч.
