OpenTelemetry Collector — прослойка между вашими сервисами и системами наблюдаемости. Сервисы шлют логи, метрики и трейсы в него, а он фильтрует, дописывает атрибуты и раскладывает по адресатам. Смысл в развязке: сменить систему хранения можно правкой конфига, не трогая код приложений. Fluent Bit и Vector делают похожее, но collector — эталонная реализация стандарта, и агенты под него пишут все.

4 августа вышла версия 0.158.0. Главное — новый компонент queuebatch вместо старого batchprocessor: он построен поверх общей обвязки экспортёров и настраивается теми же параметрами, что и очередь отправки, так что двух разных наборов настроек для соседних вещей больше нет.

Остальное:

🔘 в описаниях компонентов появились готовые типы duration, opaque_string, opaque_map и другие;
🔘 расширение memory_limiter доросло до беты;
🔘 исправлено ложное предупреждение, из-за которого молча отключалась старая метрика;
🔘 отладочный экспортёр перестал печатать числовые атрибуты в сыром виде.

Ломающее: убраны проверяющие функции из пакета xconfmap, брать теперь из confmap.

@prog_tools

Jujutsu, или jj, — система контроля версий, которая работает поверх обычного Git-репозитория: коллеги видят привычные ветки и коммиты, а у вас другая модель. Рабочая копия сама по себе коммит, staging area нет, любая операция отменяется через jj undo, конфликты хранятся в истории и не блокируют работу. 6 августа вышла версия 0.44.0, у проекта 31 тыс. звёзд на 17 августа.

🔘 стабилизирована работа с тегами: jj git fetch забирает их как <имя>@<remote>, теги можно отслеживать и не отслеживать как bookmarks, jj git push --all теперь пушит и теги;
🔘 новый revset merge_point() находит точку слияния веток, по аналогии с fork_point;
🔘 jj file search печатает совпавшие строки с именем файла, номер строки добавляет -n, старое поведение — через --name-only;
🔘 jj run идёт по ревизиям от старых к новым, получил --passthrough, --ignore-changes и --ignore-errors;
🔘 повторно переданный аргумент больше не ошибка, побеждает последний.

Альтернатива очевидна: сам Git. У него любой хостинг, submodules, IDE и десять лет чужих скриптов; у jj Git-совместимость объявлена стабильной, а команды и рабочий процесс до 1.0 могут меняться, о чём проект пишет в каждом релизе. Зато переписывание истории и работа с несколькими правками одновременно здесь заметно проще.

@prog_tools

blitcp копирует файлы по карте диска: сначала строит карту, потом читает данные в том порядке, в каком они физически лежат. Задача та же, что у cp и rsync, разница проявляется на множестве мелких файлов и на медленных носителях, то есть на HDD, флешках и NAS.

🔘 склеивает мелкие файлы в один поток чтения;
🔘 пропускает дубликаты по хешу xxHash-128;
🔘 умеет reflink и жёсткие ссылки, понимает разрежённые файлы;
🔘 после копирования сверяет результат с исходником.

Цифры авторы приводят в заметках к версии 4.0.2: 85 ГБ с NVMe на USB скопировались за 44 минуты 47 секунд вместо часа и четырёх минут, а построение карты диска в Windows для 6600 файлов ускорилось с 12 минут 48 секунд до 0,7 секунды, потому что теперь файл открывается только на чтение атрибутов и Windows Defender не сканирует его содержимое. На тесте в Linux с 12 347 мелкими файлами вышло 5,93 секунды против 14,14 у rsync и 14,99 у cp -ar.

Автор сам говорит, где его инструмент не нужен: на быстром SSD без дубликатов обычный cp лучше, потому что хеширование и анализ диска добавляют накладные расходы. Для инкрементальной синхронизации с удалённым сервером rsync тоже остаётся более подходящим, и автор это признаёт.

mkdir -p ~/.local/bin && curl -fsSL https://raw.githubusercontent.com/gekap/blitcp/v4.0.2/blitcp.py -o ~/.local/bin/blitcp && chmod +x ~/.local/bin/blitcp

Для работы по SSH дополнительно нужен paramiko.

@prog_tools

just — запускальщик команд проекта. Ту же роль обычно играет Makefile, но make всё-таки система сборки: он думает про файлы и зависимости, ругается на пробелы вместо табов и норовит не выполнить цель, если рядом лежит одноимённый файл. В justfile пишутся просто именованные команды с аргументами, и это всё, что нужно, когда цель — собрать в одном месте «прогнать тесты», «поднять окружение», «выложить».

3 августа вышла версия 1.58.0, небольшая:

🔘 у рецепта появился атрибут [timestamp], печатающий время выполнения, — удобно для долгих сборок, где раньше приходилось обкладывать команду вызовами date;
🔘 у него же есть аргумент формата;
🔘 --justfile-name теперь принимает несколько имён через запятую;
🔘 при форматировании вокруг выражений подстановки добавляются пробелы.

Ломающих изменений нет.

@prog_tools

k6 гоняет нагрузочные тесты, которые пишутся обычным JavaScript и запускаются одной командой из терминала. Сценарий лежит в репозитории рядом с кодом, порог вида «99-й перцентиль меньше трёх секунд» описывается прямо в файле, а результат печатается в консоль или уезжает в дашборд.

🔘 HTTP, WebSockets, gRPC и браузерные сценарии в одном инструменте;
🔘 в версии 2.2.0 от 10 августа появился chromium.connectOverCDP(), то есть тест можно подключить к уже запущенному Chromium и брать адрес сессии во время выполнения;
🔘 TextEncoder и TextDecoder стали глобальными, а в экспериментальных потоках появился WritableStream;
🔘 SharedArray перестал замораживать примитивы и оборачивать длинные строки в объекты: в присланной репродукции потребление памяти упало примерно с 1 ГБ до 100 МБ.

Очевидная альтернатива это JMeter, и по ряду пунктов он лучше: графический редактор тест-планов, запись сценариев и протоколы, которых у k6 нет вовсе, вроде JDBC, LDAP, FTP и JMS. k6 берёт другим: тест это код в git, запускается в CI одной командой и ревьюится как обычный пул-реквест.

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

brew install k6

@prog_tools

DuckDB — аналитическая база, которая живёт внутри вашего процесса, как SQLite. Отличие в том, что SQLite заточена под много мелких операций со строками, а DuckDB под запросы, которые читают миллионы строк и считают агрегаты. Практический смысл: SQL прямо по файлам Parquet и CSV, без поднятия сервера и без загрузки данных куда-либо.

Именно из-за этого сценария важен свежий выпуск 1.5.5 от 22 июля: файлы часто приходят извне, а база встроена в приложение, поэтому падает не отдельный сервер, а весь процесс.

🔘 перенесены исправления чтения за границами выделенной памяти;
🔘 разбор Parquet отклоняет страницы DATA_PAGE_V2 с несогласованным полем сжатого размера;
🔘 исправлена взаимная блокировка в управлении временной памятью;
🔘 в журнал HTTP-запросов добавлены длина тела и ошибки транспорта — полезно при чтении данных прямо из S3.

Выпуск целиком про исправления, ломающих изменений нет.

@prog_tools

Сервис на проде внезапно ест процессор. Перезапускать с профилировщиком нельзя: проблема как раз пропадёт.

py-spy подключается к уже работающему процессу Python по идентификатору и показывает, где тот проводит время. Код менять не нужно, перезапускать тоже, сам процесс при этом продолжает работать.

🔘 py-spy top --pid 1234 — живой список горячих функций, как top, только по функциям;
🔘 py-spy record -o profile.svg --pid 1234 — запись flame graph в файл;
🔘 py-spy dump --pid 1234 — стеки всех потоков прямо сейчас, полезно, когда процесс завис;
🔘 --locals добавляет к стекам значения локальных переменных;
🔘 --subprocesses включает дочерние процессы и обработчики очередей;
🔘 --native показывает и нативные расширения, а --gil отделяет время под глобальной блокировкой;
🔘 --nonblocking не приостанавливает процесс ради снимка — чуть менее точно, зато безопаснее на проде.

Встроенный cProfile требует запускать программу под собой, pyinstrument — правки кода. Если нужен разбор ещё и памяти с видеокартой, смотрите в сторону Scalene, но для «зайти и посмотреть, что происходит прямо сейчас» py-spy проще.

15,2 тысячи звёзд. Язык: Rust. Лицензия: MIT.

@prog_tools

Баг воспроизводится раз в сотню запусков, а под отладчиком не воспроизводится вообще.

rr записывает выполнение программы под Linux целиком, а потом проигрывает эту запись сколько угодно раз — с точностью до инструкции. Тот самый неудачный запуск можно пересматривать, ставить точки останова задним числом и двигаться по времени назад.

🔘 rr record ./program записывает выполнение вместе со всем, что программа получила извне;
🔘 rr replay открывает запись в GDB, где работают привычные команды;
🔘 reverse-cont продолжает выполнение назад — от места падения к причине;
🔘 watch -l ставит аппаратную точку наблюдения за адресом, после чего можно откатиться к предыдущей записи в него;
🔘 повторный run проигрывает тот же след заново, сохраняя расставленные точки останова;
🔘 rr pack делает след самодостаточным, чтобы передать его коллеге;
🔘 записываются деревья процессов и потоки, а режим хаоса помогает выловить редкие варианты планирования.

Ограничения честные: только Linux и только на процессорах с подходящими счётчиками производительности. Обычные GDB и LLDB переносимее, но обратной отладки не дают.

10,6 тысячи звёзд. Язык: C++. Лицензия: MIT.

@prog_tools

После выката надо свести три лога: веб-сервера, приложения и системный. Обычно это заканчивается связкой tail | grep | less в трёх окнах и ручным сопоставлением времени.

lnav открывает все файлы сразу, распознаёт формат каждого, распаковывает сжатые и показывает записи одной лентой по времени.

🔘 lnav app.log nginx/ syslog.gz — файлы, каталоги и архивы вперемешку, форматы определяются сами;
🔘 e и E прыгают к предыдущей и следующей ошибке, не заставляя искать глазами;
🔘 / ищет регулярным выражением, :highlight подсвечивает совпадения дальше по ленте;
🔘 ; открывает SQL по логам: записи разобраны на поля, и по ним можно считать группировки;
🔘 i рисует гистограмму сообщений по времени — сразу видно всплеск;
🔘 P разворачивает структурированный текст вроде JSON в читаемый вид;
🔘 F5 повторяет текущую операцию, включая последний SQL-запрос, когда логи доехали.

Для веб-аналитики с отчётами удобнее goaccess, для потоковой обработки в конвейере — angle-grinder. lnav сильнее именно как интерактивный просмотр разнородных логов на одной машине.

10,5 тысячи звёзд. Язык: C++. Лицензия: BSD-2-Clause.

@prog_tools

Подключились по SSH к незнакомой базе, и дальше начинается археология: как называется таблица, какие в ней колонки, не снесёт ли этот UPDATE пол-базы.

pgcli — терминальный клиент PostgreSQL, который подсказывает по ходу набора запроса.

🔘 после FROM предлагает таблицы, после WHERE — колонки именно этих таблиц, учитывает псевдонимы;
🔘 подсвечивает синтаксис и печатает результат ровной таблицей;
🔘 \d, \dt, \dn, \du, \dx показывают устройство схемы, пользователей и расширения;
🔘 --warn all предупреждает перед разрушительным запросом, прежде чем выполнить;
🔘 --row-limit не даёт случайно вывалить в терминал миллион строк;
🔘 --auto-vertical-output разворачивает широкие результаты по вертикали, когда они не влезают;
🔘 \watch, \timing и \copy закрывают повторный запуск запроса, замер времени и выгрузку.

Для скриптов и полного покрытия возможностей PostgreSQL остаётся psql: он есть везде и ничего лишнего не делает. pgcli удобнее там, где вы руками разбираетесь в чужой базе.

13,3 тысячи звёзд. Язык: Python. Лицензия: BSD-3-Clause.

@prog_tools

Network Doctor — консольная утилита, которая отвечает на вопрос «интернет вроде есть, а сервис не работает — где именно рвётся». Одна команда netdoc github.com прогоняет цепочку интерфейс, DNS, TCP, TLS, HTTP, прокси и path MTU и пишет вердикт обычным языком: DNS упал, всё зависимое пропущено, чинить надо запись. 14 августа вышла версия 1.11.4; у репозитория 253 звезды на 17 августа, проект молодой.

🔘 netdoc host:22 проверяет путь до SSH и баннер, netdoc без цели — локальный интерфейс, выход в интернет, прокси и Wi-Fi;
🔘 --watch ловит плавающие сбои, --json и коды выхода 0/1/2 годятся для скриптов и баг-репортов;
🔘 root не нужен даже для path MTU: только непривилегированные сокеты;
🔘 Linux, macOS, Windows; ставится через Homebrew, Scoop и winget.

Альтернатива — связка ping, dig, curl -v и mtr: она есть везде и показывает больше деталей, а mtr лучше видит потери по хопам. Network Doctor выигрывает, когда нужен не набор выводов, а ответ, чья это проблема: сети, пути или сервиса.

@prog_tools

bottom, в командной строке btm, — системный монитор для терминала: процессор, память, swap, сеть, диски, температуры, батарея и дерево процессов графиками на одном экране. 13 августа вышла версия 0.14.8, у проекта 13,9 тыс. звёзд на 17 августа.

🔘 релиз небольшой: починены закрытие меню сортировки по Enter, обработка значения swap в cgroups v1 и ссылки в JSON-схеме конфига;
🔘 графики масштабируются по времени, есть фильтры процессов, темы и собственные раскладки виджетов;
🔘 одна и та же сборка работает на Linux, macOS и Windows.

Альтернатива — htop: он есть в каждом дистрибутиве, проще и понятнее с первого взгляда, и для задачи «найти и убить процесс» его хватает. bottom берёт графиками во времени и тем, что показывает всё сразу, включая сеть и температуры; из той же ниши btop с более нарядным интерфейсом.

@prog_tools

tuicr — просмотрщик диффов для терминала, где можно оставлять построчные замечания, как в интерфейсе пул-реквеста, и одной командой отправить их ревью в GitHub, GitLab или Bitbucket. Управление вимовское, работает поверх git, jj и Mercurial.

🔘 Смотреть можно незакоммиченные правки, диапазон коммитов или чужой пул-реквест. Дифф идёт сплошным потоком по всем файлам, как на вебе.

🔘 Отметки «файл просмотрен» сохраняются между запусками, так что большое ревью можно бросить и вернуться. Клавиша H прячет уже отмеченное.

🔘 20 августа вышла версия 0.23.1, двумя днями раньше — 0.23.0 с командой :summary.

git diff универсальнее и не требует авторизации, но построчных замечаний и памяти о прогрессе у него нет. gh pr review выставляет официальный статус ревью, чего локальный просмотр не умеет, зато инлайн-комментарии через него не оставить. Для отправки tuicr нужны авторизованные gh, glab или bkt; у Bitbucket пока нет Request changes и черновиков. Звёзд на GitHub 2820 на 21 августа.

@prog_tools