ещё вот такое с зеркалами всех этих библиотек есть https://open-slum.org/

там в комментах на hn ещё https://signoz.io рекомендуют

вроде гораздо более старый проект — им кто-нибудь пользовался?

вообще чувствую себя глуповато — я думал никто кроме DD нормально это не делает, а этот signoz выглядит прилично

Google postmortem

https://x.com/0xTib3rius/status/1933702904734429560

https://www.youtube.com/watch?v=ZZ3F3zWiEmc

вот видос классный про арт

P.S. и вообще это один из лучших каналов во вселенной

я кстати писал давным давно инструкцию по тому как правильно настраивать файрфокс чтобы все лишнее резалось, и при этом без перегибов вроде «надо без джаваскрипта сидеть и без кук»

https://www.brachkow.com/notes/firefox/

сейчас посмотрел, там все достаточно актуально

Нам нужно построить такую систему разработки чтобы с одной стороны минимизировать риски и усилия, а с другой стороны добиться максимальных результатов. Поэтому где только можно избавляемся от зависимостей, строим процессы и внедряем safety net. Идеально сразу писать без багов. Следующая идеальная ситуация: ловить баги во время локальных тестов. Затем CI. Затем ловить их в QA. Но если не получилось и баг все же попал в прод, то было бы неплохо иметь необходимые инструменты и практики чтобы быстро починить/откатить.

У нас как-то был multi-tenant saas, где у каждого тенанта была своя база. И когда релизи базу с новым кодом прям плохо все было. Решили разделить релизные циклы и выкатывать базу за пару дней до релиза приложений. И ввели много правил. Ситуация улучшилась: избавились многочасовых релизов с высокими рисками отката 😉 Потом внедрили feature toggles и вообще хорошо стало

У меня тут случился выход из отпуска по бразильской системе, в первый же день до 4 утра дебажил airbyte, который многие тут ругали. Вобщем страшилка про airbyte:

В двух регионах 2 разных airbyte синхронизирубют похожие данные, возникла проблема с одной из таблиц в одном регионе все ок в другом синхронизация падатет практически сразу с абсолютно ни о чем не говорящей ошибкой типа source connection unexpectedly closed.

Прикол этой таблицы в том что в ней есть 1 json столбец который может быть размером до 800kb. Но опять же в другом регионе все работает как надо. Проверил все что можно, конфиги, настройки, ресурсы в кубере, все +- одинаково.

В неработающем регионе данных побольше раз в 10 (15Gb vs 1.5Gb), решил попробовать синхронизировать пачками увеличивая размер по 1/10 и тут же словил ошибку на второй попытке, причем первые 20% валятся а следующие 80% нормально синкаются.

Возникло подозрение что с этим json может быть что-то не так в каких то строках, так как внутри airbyte гоняет все через постгресовый csv export / import (COPY TO STDOUT / COPY FROM STDIN). Но колонка то jsonb, не может там быть невалидного по идее. Вобщем экспортнул эти 20% ручками посмотреть что там получается, все нормально вроде.

Решил двоичным поиском найти на какой конкретно строке все валится, нашел - 13167-я строка (первый 13165 строк синкаются норм, добавляешь еще одну и все валится), но если синкануть не с начала таблицы а только небольшой кусок включающий эту строку - все работает.

Сразу стало понятно что дело не в конкретной строке а в том порядке в котором они синкаются, начал изучать как это устроено в airbyte, оказалось там есть “умный планировщие” (специфичный для конкретно db), который фетчит первые 10 строк, пытается померять время, размер и прикинуть оптимальный размер фетча для последующих батчей, в процессе он может корректировать размер батча.

После долго разглядывания логов, наконец увидел странность, что в случае когда синк фейлится, второй батч после примерочного какой-то неприлично огромный - 600к+ строк, что означает всю таблицу которая весит 15Gb.

В нормальных случаях размер батчей 1-3к строк. Посмотрел внимательно на таблицу оказалось что как раз в начале идет много строк где этот json супер маленький, можно сказать пустой, попробовал синкануть таблицу без пустых json - заработало.

Вобщем, как оказалось если размер строк плавает достаточно сильно и планировщие ошибся с размером второго батча (последующие оцениваются на большей выборке, а этот второй все лишь на первых 10 строках), то - хана, это никак не конфигурится как минимум в community edition.

Кто бы мог подумать что порядок строк может так ломать airbyte)

в следующий раз не ищи https://xkcd-excuse.com/

Всем огромное спасибо за обратную связь! Благодаря вам в итоге собрал демо на английском. Прошу прощения перед теми, кого смущает акцент и грамматические ошибки в английском. Но я споук фром май харт, так что простительно.
https://youtu.be/9Q1H_wQ0Gv0?si=dl1TyJO33GPyknhH

Буду очень рад, если посмотрите, лайкните или дизлайкнете(реально, дизлайк тоже хорошо) и напишете коммент.

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