[Системное администрирование, Серверная оптимизация, Серверное администрирование, Резервное копирование] Учимся разбираться в названиях логов

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
17-Ноя-2020 12:31

Цитировать

Наверняка я вам не открою Америки рассказом о том, что логи назвали логами из-за судовых журналов, куда записывали всякое интересное (и не очень), что происходило на корабле во время плавания. (Возможно, некоторые из вас не знают, но по воде ходят именно корабли, а судно — это в больнице. Хотя тут показания расходятся)))Но не об этом мы сегодня. Сегодня мы поговорим о структуре логов в Veeam Backup & Replication, об их названиях и ожидаемом содержимом. Список будет большим, но не исчерпывающим, ибо всё описать — задача практически невозможная.

Как же подойти к процессу описания? Как вариант, можно рассказать, что некоторые логи лежат в папочках, а некоторые без папочек. Но это и так понятно, стало быть малоэффективно. Поэтому давайте начнём с незамысловатого факта, что мы в Veeam стараемся называть логи максимально прозрачно и придерживаться единой системы наименования. Так что начнём мы с не с грустных папочек, а с привязки логов к типам джоб. И первым делом рассмотрим довольно очевидныйBackup JobИтак, логи любой уважающей себя джобы лежат в отдельной папке, повторяющей её название из GUI Veeam. Кстати, если в гуе это название изменить, то папка с логами не переименуется, ибо человекочитаемые названия — тлен, а id в базе вечны.У любой джобы всегда и везде есть её самый главный лог, именуемый для простоты джобнОй лог (чистой воды жаргонизм, уж простите) Job.<job name>.Backup. В него уходит вся общая информация: когда запустилось, какие прокси назначены, что там с ретеншн, чем всё закончилось в конце, и всё такое прочее.Любая добавленная в джобу виртуалка обрабатывается в рамках отдельной таски. Поэтому вся информация, относящаяся к обработке отдельной машины, пишется в отдельный лог Task.<vm name>.<vm id> Это позволяет избежать нечитаемого фарша в одном файле и разбираться с каждой отдельной машиной в случае провала. Из интересного можно отметить, что vm id сильно отличается от того, как машина была добавлена в джобу. Возможно, не все знают, но в инфраструктуре VMware каждый считает своим святым долгом выдать свой уникальный id виртуалке. Поэтому одна и та же машина будет иметь уникальный номер на уровне ESXi, другой уникальный номер — на уровне vCenter, третий уникальный номер — на уровне vCloud, и так далее. Поэтому понимать, на каком уровне абстракций вы находитесь, крайне важно. В случае Hyper-V всё проще — там всегда будет огромный GUID.Далее идут агентские логи. Каждый агент выполняет свою некую маленькую задачу, позволяя в итоге случиться полноценному бекапу. Например, Agent.<job name>.Index - это логи агента, отвечающего за индексирование файлов, если в джобе была отмечена соответствующая опция. Если галочки нет, то лог файл создаваться не будет.Немного примеров других агентских логов:

Agent.VddkHelper В этом логе отмечаются API вызовы, запрещающие и разрешающие vCenter мигрировать машину во время бекапа.

Сейчас самое время запомнить простое правило: если в названии лога есть слово Source, значит, это лог агента, который что-то откуда-то читает. Если видим в названии лога слово Target, значит, это лог агента, который что-то куда-то записывает. В большинстве случаев работают они в паре и позволяют однозначно идентифицировать, где именно болит. Если сорсной агент не может прочитать данные, то не надо искать проблему на стороне репозитория.

Agent.<job name>.Source.<vm name> Логи агента, который занимается чтением файлов конфигурации машин участвующих в бекапе. VMX, VMXF, NVRAM - для VMware, или XML - для Hyper-V.
Agent.<job name>.Source.<vm name>.Hotadd.Attacher Как намекает название, это логи агента, который работает с дисками в Virtual Appliance режиме. Причём, если в процессе бекапа будет принято решение о смене режима на сетевой (если выбрана соответствующая опция), название файла не изменится. Также стоит отметить, что в данный момент диски с одной машины обрабатываются последовательно, поэтому лог тоже последовательный, и сочинять отдельный файл для каждого диска нет смысла.
Agent.<job name>.Source.<vm name>.<disk name> То же, что и выше, только про SAN/network режимы. Лог живёт непосредственно на машине с ролью прокси.
Agent.<job name>.Target Очень важный лог таргетного агента, в котором фиксируются события, связанные с открытием, чтением, записью файлов бекапов во время работы джобы. Если используется опция Per-vm, то у каждой машины в джобе будет свой отдельный лог в формате
Agent.<jobname>.Target.<vm name>.<vm id> Логи эти пишутся на репозитории и/или гейте.
Agent.<job name>.CtpTransfer.Client/Server Логи агента, отправляющего/получающего Changed Block Tracking данные, полученные от нашего драйвера.
Agent.<job name>.Target.Repair Если в процессе прохода джобы она потерпела неудачу (по любой причине), необходимо удалить с репозитория всё, что она успела туда записать. Эти операции логируются здесь.
Agent.<job name>.Client/Server или Agent.<job name>.Transform.<vm name>.Target/Source.<repo name> Логи от любимых всеми синтетических операций. Rollback, transform и прочие synthetic full фиксируются здесь.

Также есть небольшая порция специфических логов, которые появляются при работе с Hyper-V:

SnapshotCreator/SnapshotImporter Логи, связанные с VSS снапшотами. Есть смысл читать только вместе с Windows events.
HvWmiProxy-<HV host name> Логи отправляемых WMI запросов
Agent.<job name>.CtpTransfer.Client/Server Если используется наш драйвер для отслеживания изменённых блоков, то его работа фиксируется здесь.
Agent.<job name>.Source.<vm name>.CONFIGVMCX В Hyper-V 2016 произошёл уход от человекочитаемого XML формата при описании конфигурации машин в сторону бинарного VMCX. Однако со старым форматом тоже надо уметь работать. Агент делающих это отчитывается в этом файле.
Agent.<job name>.Source.<vm name>.CONFIGVMRS Тоже реверанс в сторону 2016 года, когда VRMS хранил в себе данные о рантайме вируталок.

Replication JobЭто были бекапы. А что с репликами? С ними всё то же самое. Только лог джобы будет называться Job.<job name>.Replica, а не .Backup. В остальном логика и названия будут ровно такие же, как и у бекапов. Хотя будет лукавством говорить, что у реплик нет ничего своего. Конечно, есть:

Например, появляется лог Agent.<job name>.Digests.Target, где содержится отчёт о создании метаданных реплики. Как вы, конечно же, помните, сама реплика хранится где-то на сторе вашего хоста. А вот метаданные от неё лежат уже в нашем репозитории.
Agent.<job name>.Repair.log Как известно, Veeam периодически проводит внутренние проверки блоков данных — забекапленного и реплицированного. Если будут обнаружены какие-то повреждения, то последует попытка спасти потерянные блоки. Штука на самом деле важная и полезная, а лог её работы лежит в этом файле.
Agent.<job name>.Target.<vm name>.<disk name> Лог таргетного агента, где хранится информация про запись данных на диски реплики.
И закончим на Agent.<job name>.Digests.Repository, посвящённом хранению метаданных.

Уверен, что вы уже поняли идею общей структуры логов. Всегда есть общий лог джобы. У него есть саб-логи тасок, где ведутся записи про каждую отдельную машину из джобы. Без тени сомнения могу сказать, что логи тасок несут в себе максимум полезной информации для решения большинства проблем. Но “большинства” не значит “всех”. Поэтому рядом с ними будут лежать логи агентов, которые делятся на сорсные и таргетные. Понимание этой незамысловатой структуры позволит вам детально разобраться с происходящим в любой вимовской джобе. Другой вопрос, что информация в логах может быть технически сложной, но про это будет в следующей статье. И не забываем, что некая часть логов оставляется агентами на бекапируемой/реплицируемой машине. И если проблема была на передающей стороне, искать её надо в логах сорсных агентов на соответствующей машине (читай прокси).Ну а мы продолжаем.Restore/FailoverЭти товарищи живут своей отдельной жизнью. Причём у них даже нет какого-то специального отдельного места для хранения своих логов. Просто создаётся папка с названием восстанавливаемой машины, и туда пишется вся информация. Правда, тут есть определённое неудобство, т.к. в одну папку могут попасть логи от разных ресторов, что (теоретически) приводит к путанице. Но с логикой наименования всё довольно просто:

IR.<vm name>.Mount/Dismount Нетрудно догадаться, IR означает Instant Recovery, а Mount/Dismount посвящены процессам монтирования машины из бекапа на продакшн сторадж и отпусканием бекапа в конце восстановления.
Vm.<vm name>.FileRestore Соответственно, логи восстановления файлов виртуалки.
Agent.<vm name>.FilesRestore.Client/Server Логи процесса копирования данных из бекапа в датастору. Опять же, разделены на два файла: один за источник, второй за приёмник.
Vm.<vm name>.Restore Появится, когда нам надо восстановить всю машину целиком.
А Vm.<vm name>.HddRestore - если восстановить нужно конкретный диск. И, по аналогии, рядом будет Agent.<vm name>.VmHardDisksRestore.Client/Server

Если речь идёт про фейловеры реплик, то самое интересное будет в следующих файлах со структурой Agent.<vm name>/<replicaname>.Failback.VddkAccessor. То есть главное — не перепутать, о чьём логе речь: реплики или оригинальной машины.Как видите, у каждой джобы есть какие-то свои особенности, которые накладывают свой отпечаток на содержание лог файлов. Но всегда и всюду наименование остаётся человекочитаемым и довольно прозрачно отражает суть содержимого. Поэтому с логами, лежащими в папочках, я хочу закончить и перейти к так называемымStandalone LogsКак нетрудно догадаться, здесь поговорим про логи, не лежащие в какой-то особенной папочке, а расположенные прямо в корне логохранилища Veeam. Сделано это в основном по причине того, что они несут в себе информацию про какие-то общие процессы, и делать под каждый такой лог свою папку — занятие странное. Хотя, положа руку на сердце, иногда всё же хочется подумать над группировкой, ибо если просто начать перечислять всё, что может лежать в папке C:\ProgramData\Veeam\Backup, то это будет больше двух страниц (проверено). Поэтому давайте самостоятельно немного сгруппируем логи по смыслу. Вот есть целая группа логов, начинающихся с Svc. Это логи наших сервисов.

Svc.VeeamBackup.log Лог того самого Veeam Backup Service, без которого ничего работать не будет. Поэтому в него приходит довольно много информации: расписание джоб, распределение ресурсов, отслеживание внутренней коммуникации между модулями, и так далее, и тому подобное. Тот редкий случай, когда в лог что-то постоянно пишется без перерывов на обед и сон.
Svc.VeeamBES.log То же самое, но это самый важный лог уже для Veeam Enterprise Manager

Дальше всё просто и понятно.

Svc.VeeamInstaller.log Фиксирует все действия Veeam Installer Service (aka Veeam Deployment service)
Svc.VeeamCatalog.log Содержит в себе записи о работе сервиса индексации гостей.
Svc.VeeamInstallerDll.log Поскольку Installer Service также проводит некоторые операции с файловой системой (проверка свободного места, поиск файлов, создание VBM и т.д.), было решено записывать эти события в отдельный лог. К слову, это единственный сервис, который приходится разворачивать через админскую шару и SCM. Все остальные устанавливаются уже с его помощью.
Svc.VeeamHvIntegration В этом логе фиксируется информация об операциях создания VSS снапшотов и взаимодействия с нашим проприетарным драйвером. Часть про VSS снапшоты одинакова с VeeamVssSupport.log файлом на гостевой машине. А поскольку у Hyper-V Integration сервисы работают в пассивном режиме, от них остаются только ответы на запросы.
Svc.VeeamWANSvc.log Логи WAN Accelerator сервиса. Лог пишется на обеих сторонах канала связи.
Svc.VeeamTransport.log Фиксирует работу Veeam Backup Proxy сервиса.
Svc.VeeamTape.log Здесь находится всё что связано с Remote Tape Server.
Svc.VeeamRestAPI.log Лог RESTfullAPI реквестов.
Svc.VeeamNFS.log. Та самая магия, которая позволяет ESXi хостам монтировать виртуалки прямо из бекапов. Используется для FLR, IR, SureBackups и прочих Other-OS File Recovery.

Есть сервис — должен быть отдельный лог. Или даже несколько, если так удобней.Так же имеется плеяда агентских логов.

Agent.<vm name>.DeleteVm Появляется если удалить из бекапа на репозитории машину. Backups>Disk>Выбрать джобу>Выбрать VM>Delete from Disk
Agent.DynGroupMount Агент отвечающий за монтирование динамических дисков.во время Windows FLR, например.
Agent.NfcCommander.Client/Server В этом логе фиксируются операции c VMFS вольюмами: чтение конфигурации, удаление/создание директорий и файлов. Используется при IR, Failover и Other OS FLR.
VeeamAgent.FileOperation.Client/Server.log В том или ином виде есть во многих подпапках. Хранит информацию о таких операциях как File Copy Job, экспорт логов и ещё нескольких.

А вот логи инструментов работающих с инфраструктурой убрали в отдельную папку \Utils\

Util.CatCleanup Лог, ведущийся тулой Catalog Synchronization. Проверяет соответствие информации в VBRCatalog и реальных бекапов.
Util.HvCtpScanner Тула, проверяющая актуальность содержимого .ctp файлов, в которых содержится информация об измененных блоках внутри VHD дисков. Один файл на один диск. Адепты VMware vSphere могли видеть то же самое в .ctk файлах.
Util.VeeamBackupConfiguration.Restore Логи восстановления базы данных самого VBR.
Util.VmBackupValidate Этот лог создаётся, если руками запустить Veeam.Backup.Validator.exe. Проверяет целостность блоков данных на уровне хранилища.
Util.DatabaseResynchronizer Это уже не отдельный лог, а полноценная папка с логами процесса синхронизации базы данных и фактического содержимого бекапных репозиториев.
Util.VolumesHostDiscover Другая полноценная папка, где хранятся логи так называемых Volumes Discovery тасков. Этот процесс проверяет диски, подключенные к прокси серверам, на предмет возможности их использования в качестве точки монтирования при ресторе элементов приложений.

И, конечно же, есть гора логов-одиночек.

Job.DatabaseMaintenance Раз в неделю Veeam проводит обслуживание своей базы: дефрагментирует индексы, удаляет ненужные данные, и так далее. Завершается это всё перезапуском основного сервиса.

VeeamBackupMksConsole Фиксирует информацию про открытие окна консоли машин, запущенных в рамках SureBackup.

RTS.ResourcesUsage.log Здесь хранятся записи планировщика ресурсов всех компонентов Veeam.
VeeamShell Всё, что происходит в GUI, оставляет свой отпечаток здесь
PowerShellInvokerWrapper<SCVMM FQDN> Лог связи между Veeam сервером и SCVMM
VeeamBackupManager Логи менеджера, запускающего джобы и таски. Практически вся информация записывается в соответствующие логи, так что здесь мало чего остаётся. Однако, где-то это надо фиксировать.

Логи по папочкамИ есть ещё логи, которые напрямую к бекапам не относятся, однако свою отдельную папочку заслужили по разным причинам.

%Something% Explorer Логи от одного из AIR (Application-Item restore) визардов. Active Directory, SQL, Oracle и так далее.
ResourceScan, Чтобы поддерживать в актуальном виде информацию о состоянии бекапной инфраструктуры, Veeam с определённой периодичностью сканирует всё, что к нему было подключено.
BackupConfigurationJob Логи джобы, бекапящей конфиг самого Veeam сервера (по сути, делающей дамп базы).
Console Информация о запусках консоли от разных пользователей. Информация внутри поделена на разные логины, однако учтите, что лог хранится на той машине откуда, запускалась консоль, а не на самом VBR сервере.
EvacuateBackupsJob Появляется при эвакуации бекапов с SOBR репозитория.
Exportlogs Логи визарда, собирающего логи для сапорта. Да, это логи на логи =)
Filefromtaperestore Удивительно, но тут живут логи восстановления файлов с лент.
FLRSessions Практически вся информация про FLR и Other OS ресторы.
Import_job Логи процесса импорта бекапов
NfsDatastore Всё, что связано с работой vPower NFS, фиксируется здесь
Satellites Своих спутников на орбите, к сожалению, у нас пока нет, однако есть несколько вспомогательных процессов, разгружающих GUI. Следы этих процессов будут в этой папке.

На этом пока всё. Повторюсь: это даже приблизительно не полный список логов и папок с ними. Как вы могли убедиться, логи пишутся буквально на каждый чих. Такова уж специфика софта, обеспечивающего защиту ваших данных. А поскольку функционал Veeam Backup&Replication невероятно огромен, то и логи генерируются в олимпийских количествах. И помимо таких очевидных вещей, как простой запуск бекапа/реплики, есть ещё фоновые задачи, такие как Health Check, например. И они тоже генерируют свои логи, дабы в случае аварии всегда можно было максимально подробно восстановить картину мира и понять, что мешает успешной работе.Поэтому основная цель, которую я перед собой ставил — это показать на примерах, как происходит именование файлов и как выглядят логи самых часто используемых функций. Надеюсь, всё получилось, и если нелёгкая заставит вас открыть %ProgramData%/Veeam/Backups, то вы сможете сориентироваться в этом море названий. А в следующей статье мы уже наконец-то перейдём к азам чтения самих логов. Поговорим про общие правила, которых надо придерживаться, и научимся вычленять базовую информацию.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_sistemnoe_administrirovanie (Системное администрирование), #_servernaja_optimizatsija (Серверная оптимизация), #_servernoe_administrirovanie (Серверное администрирование), #_rezervnoe_kopirovanie (Резервное копирование), #_veeam, #_blog_kompanii_veeam_software (
Блог компании Veeam Software
), #_sistemnoe_administrirovanie (
Системное администрирование
), #_servernaja_optimizatsija (
Серверная оптимизация
), #_servernoe_administrirovanie (
Серверное администрирование
), #_rezervnoe_kopirovanie (
Резервное копирование
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 23-Ноя 01:00
Часовой пояс: UTC + 5