Бэкенд

Если вы эксплуатируете VictoriaLogs, повседневная работа сводится к трём вещам: отправке логов, выполнению запросов и настройке срока хранения, чтобы не переполнить диск. Всё остальное незаметно происходит на диске.

В этой статье мы проследим путь одной записи лога — от поступления в VictoriaLogs до окончательного размещения на диске. Это поможет представить, что происходит внутри системы, и понять наблюдаемое поведение: почему запросы выполняются быстро, почему на диске иногда появляется множество файлов и какие флаги и метрики важны при поиске неполадок. Статья рассчитана на широкую аудиторию: не требуется ни опыт программирования, ни знание Go. Тем, кто захочет разобраться глубже, первоисточником послужит исходный код VictoriaLogs.

Работа с coding-агентом часто начинается с простой схемы: разработчик формулирует задачу, передаёт репозиторий и просит подготовить изменение. Агент читает код, редактирует несколько файлов, запускает тесты и возвращает результат.

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

Генерация кода становится всё доступнее. Основная сложность смещается к организации среды, в которой агент систематически готовит корректные изменения.

Разбираемся с Kotlin Corouitines - какие идеи заложены и чем отличается CoroutineContext от CoroutineScope

Продолжение цикла статей "что такое RPG и как с ним работать.

Предыдущие статьи
Современный RPG — что может и зачем нужен
Способы работы с БД DB2 в языке RPG на платформе IBM i

Иногда бизнес-логика выглядит просто: «соберём все данные за период и посчитаем итоговый результат». На практике этот период может оказаться не часом и даже не днём, а несколькими сутками. В одном из моих проектов требовалось построить агрегаты на основе данных, которые могли поступать в течение пяти дней.

В литературе мы встретили концепцию временных окон (Time Windows). По описанию это выглядело именно тем инструментом, который должен решить задачу: определить период ожидания, дождаться всех необходимых данных и получить итоговый агрегат.

Однако при работе с реальными потоками оказалось, что основная сложность заключается вовсе не в выборе размера окна. Главный вопрос оказался другим: существует ли вообще момент, после которого агрегат можно считать завершённым и больше никогда не изменять?

Когда нужно проверить запись в таблице, выполнить запрос из логов или понять, почему база выбрала странный план, разработчик обычно вспоминает про DBeaver, pgAdmin или DataGrip. Все три варианта решают задачу, но по-разному.

1. DBeaver и pgAdmin остаются отдельными программами: со своими окнами, подключениями и настройками. 
2. DataGrip можно получить как в отдельной IDE, так и внутри IntelliJ IDEA Ultimate, WebStorm, GoLand и других IDE от JetBrains.

Но сегодня путь от скачивания до работающей IDE с лицензией далёк от простого и легального.

OpenIDE это третий вариант: полноценный DB-клиент уже входит в состав IDE. Через него легко подключиться к базе, посмотреть ее структуру, написать SQL с комплишенами и подсветкой синтаксиса, запустить EXPLAIN, править и выгружать данные.

Почему Spring-приложение запускается медленно, и на каком именно этапе оно тупит?

В новом переводе от команды Spring АйО разбираемся, как заглянуть внутрь процесса создания контекста и отследить инициализацию бинов.

Фискальный накопитель печатает чек — и связь обрывается до того, как пришёл ответ. Напечатался он или нет, узнать неоткуда: обе ситуации выглядят для сервиса одинаково. Повторить вслепую — риск юридически значимого дубля, не повторять — продажа без чека. Разбираю, как это решалось в облачной фискализации на сотни миллионов чеков в сутки: отдельное состояние «результат неизвестен», сверка с архивом накопителя по собственному идентификатору в реквизите чека, блокировка слота вместо продолжения наугад — и почему за корректность пришлось заплатить отказом от жёсткой временной гарантии. Первая часть из шести.

База данных — бизнес-критический компонент любой ИТ-инфраструктуры, поэтому вопрос обеспечения ее доступности и отказоустойчивости обычно находится в центре внимания. Однако, фокусируясь на отказоустойчивости, компании нередко недооценивают риск переполнения диска. При этом подобные ситуации могут оставаться незамеченными до полной остановки записи БД, например при заполнении отдельного раздела, где хранятся данные или WAL.

Привет, Хабр. Меня зовут Александр Шмелёв. Я Team Lead команды разработки Databases, VK Tech. В этой статье я расскажу о рисках и причинах переполнения дисков, а также рассмотрю несколько способов предотвращения подобных проблем.

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

Вслед за Эдвардом Сьоре, или как я писал свою реализацию on disk B+Tree-индекса на Rust. В этой статье попытаюсь осветить нюансы написание своего игрушечного индекса.

Допустим, у вашего товара в основной базе уже есть ID 550e8400-e29b-41d4-a716-446655440000. Он попадает в события, логи и ответы API. Но при загрузке того же товара в Manticore приложению приходится выдавать ему ещё один, числовой ID.

До Manticore Search 28.5.0 ID документа был беззнаковым 64-битным числом. UUID можно было сохранить в отдельном строковом атрибуте, однако идентификатором документа он от этого не становился. Для UPDATE, REPLACE и DELETE всё равно требовался числовой id.

В результате приходилось хранить соответствие между UUID из основной БД и числовым ID в таблице Manticore. Теперь без него можно обойтись: RT-таблица Manticore умеет использовать UUID как ID документа.

Двухфакторная аутентификация давно стала стандартом защиты корпоративных систем. Но для работы с персональными данными и другими критичными операциями проверки только при входе в систему может быть недостаточно. В этой статье разберем, чем Step-Up Authentication отличается от классической 2FA, в каких сценариях она применяется и как мы реализовали этот механизм в одном из наших проектов

За последний год я собрал 33 ИИ-агента. Шахматный тренер для ребёнка, помощник по учёбе, ассистент для жены, тьюторы образовательных программ, боты для металлургического холдинга и энергетической компании, внутренние агенты отдела продаж и CRM.

Все они работают на одном движке. Один и тот же Docker-образ, одна и та же кодовая база. Форков ядра — ноль.

Различаются они ровно одним: где у каждого проходит граница между тем, что считает код, и тем, что говорит модель. Это и есть содержание всей работы. Не промпт-инжиниринг, не выбор модели, не RAG. Граница.

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

TL;DR

У директив proxy_* и fastcgi_* совпадает 46 опций из 53 — буферизация, таймауты, кеш, next_upstream, с точностью до префикса и вплоть до значений по умолчанию. Два независимо написанных модуля так не сходятся.

Они и не независимы. Всё, чем proxy_pass отличается от fastcgi_pass, — девять указателей на функции в ngx_http_upstream_t. Соединение, таймауты, повторы, буферизация и отдача клиенту лежат в общих 7352 строках ngx_http_upstream.c, и восемь модулей — от proxy до свежего tunnel — дёргают один и тот же код.

Только контракт из этих девяти указателей врёт в обе стороны. Один из них, abort_request, ставят все восемь модулей — а машинерия не вызывает его ни разу: ноль вызовов во всём дереве и ни одного коммита с вызовом за всю публичную историю, с импорта 0.1.14 в январе 2005-го. Другой, pipe->input_filter, в контракте не объявлен вовсе — но обязателен, как только включена буферизация, и вызывается без проверки на NULL.

Разбираем по тегу release-1.31.3 со ссылками файл:строка: все места вызова каждого колбэка, включая тот, который разбирает заголовок не из сокета, а из файла кеша; матрица «кто какие указатели ставит» по всем восьми модулям; два сценария падения с разными стек-трейсами. Плюс свой рабочий upstream-модуль на 335 строк, собранный и проверенный curl'ом, и tunnel — самый маленький из восьми, приехавший в open source в апреле.

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

Chunk делит коллекцию на массивы — одна строка кода. Но есть размер чанка, после которого он замедляется в разы при тех же данных и той же памяти. А на массиве и на List<int> внутри разный код, и в самой строке этого не видно.

Некоторое время назад мне пришла задача спроектировать высокопроизводительный балансировщик нагрузки для протокола Diameter. Через 3 месяца задача исчезла, так как как оказалось слишком долго и дорого, но в итоге балансировщик был сделан и имеется его MVP которое готово к установке как на реальное железо так и в облаке. В итоге продукт получился неплохим, и он с лихвой выигрывал имееющееся решение в той компании, по производительности был выигрыш раз в 6 по ресурсам раз в 100. Но суть не в этом, а в том что балансировщик был кластерным и умел хранить сессии в Redis. Решение было сделано, оно показало работоспособность, все хорошо, но меня не устраивала производительность. В тот момент я столкнулся с очень интересной проблемой - по каким то причинам я не мог пробить барьер в 5-7К Diameter Transactions per second. В принципе 5-7К TPS было неплохо, но проблемным участком как показал анализ был Redis. Проведя немного времени я смог добиться приемлемого результать и производительность поднялась до 20К TPS но там были другие проблемы.

Embedded-разработка отличается множеством уникальных настроек, компиляторов и систем сборки. А при использовании стандартных методов анализа могут возникать сложности. Для решения этой проблемы PVS-Studio предоставляет специально разработанный механизм. Давайте узнаем о нём больше и посмотрим, как его можно применять на практике.

Для проверки сквозного трейсинга GenAI-приложения мы взяли OpenTelemetry Demo 3.0. В обновлённом стенде уже были сервисы chatbot, agentи mcp, а также ИИ-спаны. Оставалось направить телеметрию по OTLP в ProtoOBP и открыть готовую цепочку вызовов. Но все спаны приехали, а единой истории не получилось: один пользовательский запрос распался на два трейса на границе MCP.

Автоматическая HTTP-инструментация связь не восстановила. Мы проследили traceparent до MCP _meta, нашли место потери контекста и добавили небольшой слой над ClientSession. После исправления цепочка собралась в единый трейс из 27 спанов.

В статье покажем исходный разрыв, код исправления и проверку результата по клиентскому и серверному спанам и карте связей.