Fast food против деликатесов. Создаем альтернативу Mozilla Socorro на Node.js за вечер | glide.name

Разработчики редко задумываются о том, удобно ли будет пользоваться их «творением». Нас больше волнует, какими модными технологиями этот продукт будет напичкан и как предусмотреть все на свете. В итоге рождаются продукты вроде Mozilla Socorro.Что это? Socorro — сервер для сбора и обработки краш-репортов, которые создаются популярной кросс-платформенной библиотекой Google Breakpad.

Однажды наткнувшись на него, я с облегчением вздохнул и обрадовался тому, что совсем скоро краш-репорты в моем проекте будут красиво показываться как у Mozilla. Отправной точкой стала официальная документация, в которой сразу же бросились в глаза зависимости:

Mac OS X or Linux (Ubuntu/RHEL)

PostgreSQL 9.3

RabbitMQ 3.1

Python 2.6

C++ compiler (GCC 4.6 or greater)

Subversion

Git

PostrgreSQL and Python dev libraries (for psycopg2)

Даже не вооруженным взглядом видно, что перед нами отличный деликатес для разработчиков. Python, PostgreSQL и даже RabbitMQ, который к слову сказать — разрабатывается также в недрах Mozilla. Но проходит пару минут, технологическая эйфория спадает и вы начинаете понимать:

Установка и настройка этого монстра займет много или даже ОЧЕНЬ много времени
Зависимости очень «тяжелые», один только RabbitMQ съест не мало оперативной памяти
Что особенно критично если у вас open-source проект, и в вашем распоряжении очень скромный сервер или VDS
Соль и перец к перечисленному выше добавьте по вкусу

Потом вы вспоминаете, что вы просто хотели бы какой-то инструмент, который автоматически обрабатывает приходящие краш-репорты и добавляет извлеченную из него информацию в дефекты на Github.

Первая мысль которая сразу же приходит на ум — найти альтернативы. Поверхностный поиск на github дал следующие результаты:

https://github.com/atom/mini-breakpad-server (Node.js)
https://github.com/GregoryHlavac/Caliper (Node.js)
https://github.com/efyx/LandingNet (Python)
https://github.com/reckhou/DoomAnalysis (Go)

Наиболее простым является mini-breakpad-server, он не требует никаких БД и достаточно прост в установке. НО как мне кажется существенным недостатком всех этих проектов является попытка сделать все тот же Mozilla Socorro, только самостоятельно, на любимом ЯП. Никто не задумался над тем, что вероятно у проекта которому нужен подобный «сервер» уже есть свой сайт и еще один со статистикой по краш-репортам им не нужен.

Именно поэтому я решил упростить задачу и разбить такой проект на две части:

Обработчик краш-дампов — будет извлекать полезную информацию и добавлять комментарием в уже открытый дефект на гитхабе
Web-приложение — принимает краш-дампы от клиента поставляемого вместе с приложением.

Это позволяет существенно сократить время необходимое на разработку. Чтобы написать свой велосипед быстро, я использовал Node.js для которого уже есть готовый модуль minidump

В качестве связующего звена, с помощью которого Web приложение будет обмениваться данными с этим обработчиком, я выбрал Redis. Потому что он прост, скромен и быстр 🙂 В итоге получилось следующее:

Обработчик краш-дампов: https://github.com/RedisDesktop/breakpadProcessor.js

Он следит за списком breakpad:unprocessed в Redis и обрабатывает поступающее минидампы. Сообщения поступающие в этот список должны иметь следующий формат:

{
  "minidump": %MINIDUMP_NAME%,
  "issue": %GITHUB_ISSUE_NUMBER%
}

{

"minidump": %MINIDUMP_NAME%,

"issue": %GITHUB_ISSUE_NUMBER%

}

В моем случае добавление происходит в приложении на php следующим образом:

    $redis = new Predis\Client($rdmData['db']);
    $task = array('minidump' => $dumpFileName, 'issue' => $issueInfo['number']);
    $redis->sadd("breakpad:unprocessed", json_encode($task));

$redis = new Predis\Client($rdmData['db']);

$task = array('minidump' => $dumpFileName, 'issue' => $issueInfo['number']);

$redis->sadd("breakpad:unprocessed", json_encode($task));

При желании можно добавить сбор и отображение статистики в веб-приложении.

Материалы по теме: