Логовед

Текст письма Игоря Власенко (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, напишу позднее.

Ссылки

• logoved-report
• I: 'Logoved' project
• I: Logoved-Stream для обработки логов hasher