Логовед
Текст письма Игоря Власенко (viy@) в devel@ за 26.08.2018 г.
Логовед
Хочу представить вашему вниманию свою новую разработку - систему "Логовед" для автоматизации починки пакетов, разбора логов сборки и QA. Я буду докладывать по этой разработке на конференции в Калуге.
Более ранний специализированный прототип системы "Логовед"
уже почти 5 лет используется совместно с системой автоматизации
сборки библиотек perl "cpanbuilder" и частично с инструментами
поддержки библиотек perl в Сизифе "watchscripts/perl".
На ее хрупких плечах поддержка более 26 тысяч пакетов perl-*
в репозитории autoimports.
К сожалению, хотя прототип и зарекомендовал себя в своей области очень хорошо, ограничения дизайна не позволяли переориентировать его на другие задачи, да и дальнейшая разработка и расширение были невозможны. Поэтому разработку уже универсального решения пришлось вести заново.
Зачем Логовед нужен и как им пользоваться
Укажу только часть наиболее важных применений.
- Разбор FTBS логов и генерация отчета со статистикой.
- Пример проблемы. В 2018 году в ALT Linux beehive логи неудавшейся пересборки (FTBS: Fails To Build From Source) репозитория Sisyphus стабильно составляют порядка 500 пакетов. Только чтобы ознакомиться со всеми этими логами, понадобится как минимум 3-4 часа (500 на 20-30 сек на 1 файл).
- Логовед позволяет выявить известные базе Logoved DB причины несборки пакета, а Отчеты Логовед - оформить их.
- Отчет группирования логов создает каталог отчета с деревом подкаталогов, содержащих внутри линки на исходные лог файлы (которые, таким образом, остаются на месте нетронутыми) с ошибкой одного типа и вида и файл статистики.
Пример результата работы отчета группирования логов:
ОТЧЕТ/ apt/ E-not-found/ foo-1.2-alt1 ... (42 лог файла, E: Невозможно найти пакет; top: python2dist(setuptools) 8шт, pkgconfig(physfs) 4 шт, ...) E-conflict/ (7 лог файлов, conflicts between attempted installs; top: file /usr/bin/dbmmanage conflicts between attempted installs of apache-common-1.3.42rusPL30.24-alt9.1.i586 and apache2-base-1:2.4.33-alt1.S1.i586 [11 files in conflict] 5 шт, ...) brp-alt/ verify-elf-error/ bar-3.13-alt3,2 ... (23 лог файла, verify-elf: ERROR: ... ... ... Неопознанные/ baz-10.2013-alt2 ...
Отчет txt содержит в основном статистику, как в примере выше, отчет html может пригодиться, например, для webery.
Применительно к Логовед ответ на вопрос "В чем сила, брат?" будет следующий: сила в отчете группирования логов.
- Во-первых, не нужно тратить время на просмотр логов;
- Во-вторых, можно выбирать ошибки, к которым есть настроение, не нужно лишний раз напрягать и переключать мозг: можно сразу взять пакеты с однотипной ошибкой и получится конвейер - 10 однотипных ошибок чинятся быстрее, чем 3 разноплановых.
- В-третьих, в обработчиках ошибок.
Если ошибки слишком уж шаблонные и однотипные, для них можно (и нужно!) написать обработчик - скрипт починки.
В таких случаях отчет Логовед сгенерирует в отдельном дереве исправленные пакеты (в виде srpm для srpm-заливаемых пакетов и в виде gear репозиториев для git-заливаемых).
В зависимости от настроек он это сделает либо дополнительно к отчету, либо удалит из отчета ошибки, которые были исправлены автоматически, и оставит в отчете только пакеты, которые требуют ручной правки.
В случае с FTBS логами beehive для основного репозитория Sisyphus автоисправление сборки выглядит cool feature, но не killer feature, так как простые исправления в пакетах обычно вносятся достаточно быстро, а в FTBS накапливаются запущенные случаи.
Но в случае репозитория Sisyphus/autoimports
автоисправление сборки это действительно killer feature.
Автогенерированные и автоимпортированные пакеты имеют
тенденцию к появлению легко исправляемых систематических
ошибок из-за ограничений в коде генерации или импорта,
а логовед позволяет "вытянуть" их сборку.
Получается "замкнутый цикл", как в атомной энергетике -
исправленные Логоведом пакеты можно повторно отправлять
на сборку.
К примеру, во время обновления репозитория Sisyphus/cpanbuilder
от 25.08.2018 пакеты обновлений проходили с помощью специализированного
прототипа системы "Логовед" через автоматический цикл
"сборка - починка с помощью "Логовед" - сборка" 4 раза.
Каждый раз logoved допиливал до успешной сборки
все новые пакеты perl "паровым напильником",
цикл прекратился только тогда, когда больше новых пакетов
собрать не удалось.
К сожалению, этот прототип был встроен в скрипты сопровождения Sisyphus/cpanbuilder. Новый "Логовед" после наполнения базы будет способен работать самостоятельно, как с autoimports, так и с beehive Sisyphus FTBS.
Как устроен Логовед
Сердцем системы "Логовед" является "Logoved DB", база знаний
сообщений об ошибках и предупреждений и библиотека для работы с ней.
Сообщения об ошибках и предупреждения в простейшем случае
хранятся как регулярное выражение, но может быть и набор
регулярных выражений, и подпрограмма, и внешний скрипт-фильтр.
В базе хранятся не только различные сообщения об ошибках
но и во многих случаях действия, которые нужно предпринять
для исправления ошибки (к примеру, для редактирования srpm пакета --
ссылка на скрипт для библиотеки RPM::Source::Editor).
Поэтому "Logoved DB" и называется базой знаний.
"Logoved DB" может быть использован и напрямую, например, в системе тестирования приложений путем их установки и запуска в виртуальной машине, для распознавания их сообщений в консоли.
Однако наиболее важно применение этой системы для обработки логов сборки пакетов (и пересборки в beehive), как удачных (для поиска предупреждений и мелких ошибок) так и неудачных логов, для помощи в починке пакетов. Отсюда и название системы, Логовед.
Для обработки логов сборки/пересборки пакетов
для корректного применения к ним данных из "Logoved DB"
мало найти соответствующее сообщение, необходимо знать его контекст.
В процессе сборки в зависимости от этапа сборки одно и то же
сообщение может быть признаком build error, warning, или
же вообще должно быть проигнорировано как, к примеру, сообщение
"Package gtk+-2.0 was not found in the pkg-config search path"
на этапе выяснения BuildRequires пакета в hasher для подготовки chroot.
Для уточнения контекста сообщения "Logoved DB" нужен
посредник, парсер логов hasher. Для "Logoved DB" таким
парсером выступает подсистема "Logoved-Stream"
(доступна в виде отдельной независимой библиотеки).
"Logoved-Stream" позволяет разбить лог сборки
на отдельные секции, а также определять, успешно
ли завершилась конкретная секция.
Например, в логе пересборки в beehive для opengoo-1.5.2-alt2.3
подсистема "Logoved-Stream" выделила секции
hasher::chroot::users hasher::chroot::install beehive::chroot::srpm::repack hasher::chroot::srpm rpmbuild::prep rpmbuild::build rpmbuild::install rpmbuild::install::brp rpmbuild::files::processing::opengoo-1.5.2-alt2.3 rpmbuild::files::find_requires::opengoo-1.5.2-alt2.3 rpmbuild::files::requires::opengoo-1.5.2-alt2.3 rpmbuild::files::listed_twice::opengoo-1.5.2-alt2.3 rpmbuild::write hasher::time beehive::time
"Logoved-Stream" позволяет применять записи "Logoved DB" об ошибках и предупреждениях только к тем секциям лог файла, для которых это имеет смысл. (контекст сообщения об ошибке хранится в "Logoved DB", а в интерфейсе "Logoved-Stream" <=> "Logoved DB" указано, какому контексту какие наборы секций соответствуют). Также в зависимости от контекста одному и тому же сообщению могут быть назначены разные обработчики.
На этом пока закончу с описанием того, как устроен Логовед.
О других применениях Логовед, например, Логовед для repocop, напишу позднее.