[devel] I: 'Logoved' project

[Igor Vlasenko <vlasenko@imath.kiev.ua>]

Уважаемые господа!

Хочу представить вашему вниманию свою новую разработку -
систему "Логовед" для автоматизации починки пакетов,
разбора логов сборки и QA. Я буду докладывать
по этой разработке на конференции в Калуге.

Более ранний специализированный прототип системы "Логовед"
уже почти 5 лет используется совместно с системой автоматизации
сборки библиотек perl "cpanbuilder" и, частично, с инструментами
поддержки библиотек perl в Сизифе "watchscripts/perl".
На ее хрупких плечах поддержка более 26 тысяч пакетов perl-* 
в репозитории autoimports.

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


== Зачем Логовед нужен и как им пользоваться. ==


Укажу только часть наиболее важных применений.

Разбор FTBS логов и генерация отчета со статистикой.

Пример проблемы. В 2018 году в ALTLinux 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,
напишу позднее.


-- 

I V