Откъде идват логовете? Veeam Log Diving

Продължаваме нашето потапяне в увлекателния свят на гадаенето… проблемното решаване чрез логове. В предишната статия сме се споразумели относно значението на основните термини и с един поглед разгледахме общата структура на Veeam като единно приложение. Задачата за днес е да разберем как се формират лог файловете, каква информация се съдържа в тях и защо изглеждат така, както изглеждат.

Какво мислите, какво всъщност са тези "логове"? Според мнозинството, на логовете на всяко приложение трябва да се отрежда роля на всевъзможната същност, която голяма част от времето прозябава някъде на задния план, но в нужния момент се появява от нищото в сияющи доспехи и спасява всичките ния. Тоест, в тях трябва да има всичко, започвайки от най-малките грешки в всеки компонент, до отделни транзакции на базата. И ако има грешка, веднага трябва да бъде записано как да се коригира. И всичко това трябва да се побере в няколко мегабайта, не повече. Все пак, това е просто текст! Не могат текстовите файлове да заемат десетки гигабайти, чух някъде това!

И така, логове

В реалния свят логовете са просто архив на диагностична информация. И какво да се съхранява там, откъде да се вземе информация за съхранение и колко подробна трябва да бъде, решават самите разработчици. Някой избира минимализма, съхранявайки записи на ниво ВКЛ/ИЗКЛ, а някой събира всичко, което успее да набере. Има и междинен вариант с възможност за избор на така нареченото Ниво на Логване, при което сам посочваш колко подробна информация искаш да съхраняваш и колко излишно място имаш на дисковете =) При VBR има цели шест нива, между другото. И повярвайте, не искате да видите какво се случва при максимално подробно логиране, когато имате свободно пространство на вашия диск.

Добре. По принцип разбираме какво искаме да запазим, но възниква законният въпрос: откъде да вземем тази информация? Част от събитията за логване, разбира се, формираме сами чрез нашите вътрешни процеси. Но какво да правим, когато става въпрос за взаимодействие с външната среда? За да не изпаднем в ада на импровизациите и бъркотията, Veeam има тенденция да не изобретява колелото наново. Винаги, когато съществува готово API, вградена функция в системата, библиотека и т.н., ние даваме предимство на готовите варианти, преди да започнем да изграждаме свои сложни решения. Въпреки че и тях не липсва. Затова при анализа на логовете е важно да разберем, че голямата част от грешките идват от съобщения от трети API, системни повици и други библиотеки. В този случай ролята на VBR се свежда до предаване на тези грешки в лог файловете без промяна. Основната задача на потребителя е да научи как да разбира коя линия е от кого и за какво отговаря този “някой”. Затова, ако кодът на грешка от логовете на VBR ви насочва към страницата на MSDN, това е нормално и правилно.

Както се договорихме по-рано: Veeam е така нареченото приложение, базирано на SQL. А това означава, че всички настройки, всяка информация и всичко, което е необходимо за нормалното функциониране - всичко се съхранява в неговата база. Оттук следва простата истина: това, което не е в логовете, вероятно е в базата. Но и това не е сребърна куршумица: някои неща ги няма нито в локалните логове на компонентите на Veeam, нито в неговата база. Затова трябва да се научите да изследвате логовете на хоста, логовете на локалната машина и логовете на всичко, което участва в процеса на бекъп и възстановяване. А понякога се случва така, че необходимата информация я няма абсолютно никъде. Такъв е пътят. 

Няколко примера за такива API

Този списък не цели да бъде изключително пълен, така че не търсете истината в последна инстанция в него. Неговата задача е само да покаже най-често срещаните трети API и технологии, използвани в нашите продукти.

Да започнем с VMware. 

Първият в списъка ще бъде vSphere API. Използва се за аутентификация, четене на йерархия, създаване и изтриване на снимки, заявка за информация за машините и много (много) друго. Функционалността на решението е много широка, така че на всеки желаещ мога да препоръчам VMware vSphere API Reference за версия 5.5 и 6.0. За по-актуални версии всичко може да се намери с едно просто търсене в Google.

VIX API. Черна магия на хипервизора, за която има отделен списък с грешки. VMware API за работа с файлове на хоста без свързване към тях по мрежата. Вариант на последна надежда, когато трябва да поставите файл на машина, до която няма по-добър канал за свързване. Представлява мъка и страдание, ако файлът е голям, а хостът е натоварен. Но тук важи правилото, че дори 56,6 Кб/с е по-добре от 0 Кб/с. В Hyper-V подобна функция се нарича PowerShell Direct. Но това беше само до появата на

vSpehere Web Services API Започвайки от vSphere 6.0 (приблизително, тъй като този API беше представен за първи път в версия 5.5), той се използва за работа с гостуващи машини и вече практически навсякъде е заменил VIX. По същество, това е още един API за управление на vSphere. За заинтересованите мога да препоръчам да проучат отличен наръчник. 

VDDK (Virtual Disk Development Kit). Библиотека, за която частично беше споменато в този статии. Използва се за четене на виртуални дискове. Веднъж беше част от VIX, но с времето беше отделена в самостоятелен продукт. Въпреки това, като наследник, използва същите кодове за грешки, както и VIX. Но по някаква причина в самия SDK няма описание на тези грешки. Затова опитно беше установено, че грешките на VDDK с други кодове — всъщност са транслация от бинарен в десетичен код. Състои се от две части – първата половина представлява недокументирана информация за контекста, а втората част — традиционни VIX/VDDK грешки. Например, ако видим:

Грешка VDDK: 21036749815809. Непозната грешка

То смело конвертираме това в hex и получаваме 132200000001. Неефективният старт 132200 просто отхвърляме, а остатъкът ще бъде нашият код за грешка (VDDK 1: Непозната грешка). За най-честите VDDK грешки наскоро имаше отделен статия.

Сега да се погледнем на Windows.

Тук всичко необходимо и важно за нас можем да намерим в стандартния Event Viewer. Но има едно обстоятелство: по стара традиция Windows логва не пълния текст на грешката, а само нейния номер. Например, грешка 5 — това е “Достъп отказан”, а 1722 — това е “RPC сървърът е недостъпен”, а 10060 — това е “Времето за свързване е изтекло”. Разбира се, прекрасно е, ако помните най-известните, но какво да кажем за досега невиждани? 

И за да не изглежда животът съвсем меден, грешките се съхраняват и в шестнадесетичен вид, с префикс 0x8007. Например, 0x8007000e наистина е 14, Изчерпване на паметта. Защо и за кого е направено така — остава загадка. Въпреки това, пълният списък с грешки можете да изтеглите безплатно и без СМС от девцентъра.

Между другото, понякога се срещат и други префикси, а не само 0x8007. В такава тъжна ситуация, за да разберете HRESULT (“result handle”), трябва да задълбочите още повече в документацията за разработчиците. В обикновения живот не ви го препоръчвам, но ако случайно сте притиснати или просто ви е интересно, сега знаете какво да правите.

Но колегите от Microsoft малко ни съжалиха и представиха на света утилитата ERR. Това е малък парченце конзолно щастие, което може да превежда кодовете на грешки на човешки език без нужда от Google. Работи по следния начин.

C:UsersrootDesktop>err.exe 0x54f
# за hex 0x54f / десимал 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# Възникна вътрешна грешка.
# като HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# за hex 0x54f / десимал 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# Възникна вътрешна грешка.
# 2 срещания намерени за "0x54f"

Задава се законен въпрос: защо не пишем веднага разшифровка в логовете, а оставяме тези мистериозни кодове? Отговорът е в страничните приложения. Когато сами извиквате някакъв WinAPI, разшифроването на неговия отговор не е трудно, защото дори има свой специален WinAPI извикване. Но както вече бъде споменато, в нашите лога попада всичко, което само идва в нашите отговори. И за разшифроването ще трябва постоянно да наблюдавате този поток на съзнанието, да изваждате от него парчета с Windows грешки, да ги разшифровате и да ги вмъкнете обратно. Да кажем честно, не е най-възбудителната задача.

Windows File Management API всячески се използва при работа с файлове. Създаване на файлове, изтриване, отваряне за запис, работа с атрибути и т.н.

По-горе споменатият PowerShell Direct като аналог на VIX API в света на Hyper-V. За съжаление, не е толкова гъвкав: мнозина ограничения по функционалността, не работи с всяка версия на хоста и далеко не с всички гости.

RPC (Remote Procedure Call) Мисля, че няма човек, който е работил с Windows, който да не е виждал грешки, свързани с RPC. Независимо от разпространеното схващане, това не е един протокол, а всеки клиент-сървърен протокол, отговарящ на редица параметри. Въпреки това, ако в нашите логове има грешка RPC, в 90% от случаите това ще бъде грешка от Microsoft RPC, който е част от DCOM (Distributed Component Object Model). В мрежата можете да намерите огромно количество документация по темата, но значителна част от нея е доста остаряла. Ако обаче имате спешно желание да проучите темата, мога да препоръчам статии. Какво е RPC?, Как RPC работи и дълъг списък грешки RPC.

Основните причини за възникване на RPC грешки в нашите логове са неуспешни опити за взаимодействие между компонентите VBR (сървър > прокси, например) и най-често поради проблеми с връзката.

Топ грешка сред всички грешки е The RPC server is unavailable (1722). Казано по-просто, клиентът не успя да установи връзка със сървъра. Как и защо — няма един отговор, но обикновено това е проблем с автентикацията или със сетевия достъп до порт 135. Последното е характерно за инфраструктури с динамично назначаване на портове. По тази тема има дори отделен КВ. А при Microsoft — обширно ръководство за откриване на причините за неизправност.

Втората по популярност грешка: There are no more endpoints available from the endpoint mapper (1753). RPC клиентът или сървърът не успяха да назначат порт. Обикновено възниква, когато сървърът (в нашия случай гостуващата машина) е бил настроен на динамично разпределение на портове от ограничен диапазон, който е свършил. А ако погледнем от страна на клиента (в нашия случай VBR-сървъра), това означава, че нашият VeeamVssAgent не е стартирал или не е бил регистриран като RPC интерфейс. По тази тема също има отделен КВ.

А за да завършим Топ-3 на RPC грешките, да припомним RPC function call failed (1726). Появява се, ако връзката е била установена, но RPC заявките не се изпълняват. Например, запитваме информация за статуса на VSS (вдруг в момента се прави шадоу копие, а ние се опитваме да проверим), а в отговор получаваме мълчание и игнор.

Windows Tape Backup API необходим за работа с лентовыми библиотеки или устройства. Как я уже упоминал в начале: писать свои драйвера и сталкиваться с поддержкой каждого устройства нам нет никакого удовольствия. Поэтому у Вима нет собственных драйверов. Всё осуществляется через стандартный API, поддержку которого реализуют сами производители оборудования. Так ведь намного логичней, правда?

SMB/CIFS Все по привычке пишут их рядом, хотя не все помнят, что CIFS (Общая Интернет-файловая система) — просто частная версия SMB (Server Message Block). Так что обобщение этих понятий вполне уместно. Samba — это уже реализация для Linux/Unix, и там есть свои особенности, но я отвлёкся. Важно: когда Veeam просит записать что-то по UNC пути (serverdirectory), сервер использует иерархию драйверов файловой системы, включая mup и mrxsmb, для записи на шару. Соответственно, ошибки тоже будут генерироваться этими драйверами.

Никак нельзя обойтись без Winsock API. Если что-то нужно сделать по сети, VBR работает через Windows Socket API, известный как Winsock. Так что если мы видим в логе связку IP:Port, это оно. В официальной документации есть неплохой список возможных на грешки.

По-горе споменатият WMI (Windows Management Instrumentation) — это всеобъемлющий API для управления всем и всяким в мире Windows. Например, при работе с Hyper-V практически все запросы к хосту происходят именно через него. Словом, это совершенно незаменимая и очень мощная вещь. В попытках определить, где и что сломалось, очень помогает встроенная утилита WBEMtest.exe.

И последний в списке, но совершенно не последний по значимости — VSS (Volume Shadow Storage). Эта тема настолько неисчерпаемая и загадочная, сколько написано по ней документации. Shadow Copy проще всего понимать как особый тип снапшота, которым он по сути и является. Благодаря ему в VMware можно делать application-consistent бекапы, а в Hyper-V вообще чуть ли не всё. У меня есть в планах сделать отдельную статью с неким выжимкой по VSS, но пока можете попробовать почитать это описание. Только осторожно, потому что попытка понять VSS с наскока может привести к травмам головного мозга.

На этом, пожалуй, можно и остановиться. Задачу объяснить самые базовые вещи считаю выполненной, так что в следующей главе будем смотреть на логи. Но если остались вопросы, не стесняйтесь озвучивать их в комментариях.

Източник: habr.com