Почему exactly-once — это миф? Как защититься от дубликатов в распределённых системах?
Продолжаем работу с Kafka на практике и рассматриваем более интересные темы.

Простым языком и с примерами кода о непростых концепциях и паттернах.

Многие команды работают с кластерами Kubernetes побольше нашего. В них больше узлов, больше подов, больше ingress и так далее. По большинству размерностей нас кто-нибудь, да побеждает.

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

Проблема сильно усугубляется, когда daemonset должен выполнять listwatch пространств имён или сетевых политик (netpol), которые мы определяем для каждого пространства имён. Так как daemonset запускают под в каждом узле, каждый из этих подов выполняет listwatch одних и тех же ресурсов, из-за чего объём используемой памяти увеличивается при росте количества узлов.

Хуже того — эти вызовы listwatch серьёзно нагружали apiserver. Если одновременно перезапускалось множество подов daemonset, например, при развёртывании, то они могли перегрузить сервер запросами и вызвать реальный вылет.

Первый Docker-образ для моего Go-приложения весил 1.92 GB. Для микросервиса на 100 строк — абсурдно. Решил разобраться, куда именно уходит место и как добиться максимально лёгкого образа.

Всё больше выходит больших MoE моделей с малым числом активных параметров. У MoE совсем другой сценарий нагрузки и использования ресурсов нежели у Dense моделей, достаточно немного VRAM. Большие MoE модели устроит 1 GPU и много обычной RAM. О том, как устроены MoE и как ускорить работу одним параметром не меняя железо.

Казалось бы простая задача - переместить логи из пункта А в пункт Б, что тут сложного. Но даже для такой пустяковой задачи придумали множество ПО: как более популярных Rsyslog, Logstash, fluentd, fluentbit, так и менее известных как file.d, недавно принудительно-опенсорснутая Пилорама (спасибо, Яндекс!).

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

Всем привет! Я Алексей Босенко, DevOps-инженер в компании KTS. В этой статье я покажу, как комплексно настроить быструю и эффективную сборку проектов в Kubernetes с использованием BuildKit, которая учитывает не только производительность, но и стоимость ресурсов.

Под этой громкой фразой я подразумеваю целый комплекс решений: как создать и настроить экономичный кластер Kubernetes для сборок (ведь цена вопроса всегда важна), как настроить GitLab Runners и как сделать эффективное масштабирование сборок. Особый акцент будет на том, почему мы выбрали BuildKit, какие варианты использования он предлагает, и как непосредственно настроить один из них.

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

На просторах интернета можно найти множество интерфейсов для LLM. Все они довольно разношерстные и обладают разным функционалом: от простых чатов до почти энтерпрайз-приложений.

Я установил и опробовал 10 них (на самом деле больше, но нормальных только 10 :) В этой статье найдете их краткий обзор.

Мои курсы: Разработка LLM с нуля | Алгоритмы Машинного обучения с нуля

Помню тот момент, когда я в очередной раз пытался вытащить конкретную спецификацию из стопки PDF‑отчетов. «Вот бы ИИ мог сам в этом покопаться», — подумал я. Это чувство знакомо многим, кто работает с большими массивами текстовой информации.

Тогда я и решил, что хватит это терпеть. Последующий день превратился в марафон по установке и настройке RAG (генерация с дополнением извлеченной информацией). Это был путь проб и ошибок, который в итоге увенчался успехом. И теперь я хочу поделиться этим опытом с вами.

В этом материале мы:
• Пошагово установим rag_api в уже развёрнутый LibreChat;
• Воспользуемся Python 3.12, PostgreSQL 17;
• В командной строке соберём PostgreSQL‑аддон pg_vector через x64 Native Tools Command Prompt for VS 2022;
• Протестируем RAG‑систему 20 вопросами к вымышленной документации, сгенерированной в Gemini 2.5 Pro;
• Узнаем, во сколько раз медленнее запускать через CPU, чем через GPU.

Uptrace v2.0 использует новый JSON-тип ClickHouse для хранения observability-данных. Результат: запросы по трейсам ускорились в 10 раз.

Делюсь практическим опытом внедрения: установка за 5 минут через Docker, настройка data transformations для обработки данных на лету, гибкие retention policies для экономии на хранении.

В статье:

Пошаговая инструкция от установки до production

Примеры кода на Node.js с OpenTelemetry

Кейсы настройки: снижение cardinality URL, парсинг данных, удаление PII

Чеклист для продакшена

Подходит для микросервисных архитектур на 5+ сервисов, где нужна скорость поиска по атрибутам трейсов.

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

Де-факто стандартом мониторинга стал Prometheus. В статье мы разберёмся, всегда ли можно доверять информации, которую он предоставляет. Посмотрим, в каких случаях его данные не соответствуют реальности, и погрузимся в тонкости работы Lookback-delta, оконных функций и Federation API. В итоге вы глубже поймёте внутреннее устройство Prometheus и других систем мониторинга на базе TSDB и сможете корректно интерпретировать данные с учётом их особенностей.

База знаний помогает пользователям быстро понять, какие возможности есть у облачных сервисов — так же, как качественный README объясняет назначение open source‑проекта. 

В этом материале мы собрали несколько интересных бесплатных инструментов для подготовки README.

GitOps — широко известен и востребован, поэтому по теме регулярно появляются новые материалы для начинающих, а также специализированные инструменты. Мы в Beeline Cloud подобрали примечательные вводные статьи, гайды и open source-решения, которые интересно изучить и потестировать: от управления DNS-зонами и секретами до GitOps-инструментов от энтузиастов и крупных фирм-разработчиков.

Помните старую поговорку про семь раз отмерь? В мире AI-кодинга она обрела новый смысл.

Сегодня расскажу о практике AI-Driven разработки (AIDD), которую мы у себя в команде ежедневно применяем для разработки ИИ-решений. Она успешно зарекомендовала себя в различных проектах и задачах — будь то стартапы или легаси, приложения на Python, Java или даже 1C.

Разбирать методику будем в AI редакторе Cursor, но повторить ее вы сможете в любом кодовом ассистенте. Поехали...

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

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

Сегодня расскажу, откуда взялась Arch Kata, чем она отличается от привычного хакатона, как проходит и почему в ней стоит участвовать не только архитекторам, но и разработчикам, аналитикам и менеджерам. А в конце покажу пример, который мы давали участникам последней игры.

В каждой компании есть необходимость выстроить систему observability. В hh.ru мы перестраивали архитектуру под большее количество данных несколько раз — сейчас имеем на входе 24к RPS, 1 миллион спанов в секунду, 5к инстансов сервисов. Если вы — инженер, который находится в процессе построения или перестройки собственной системы трейсинга, этот доклад — для вас.

Привет, Хабр! Я — Александр Казанцев, уже более десяти лет в разработке. Когда-то был инженером на пивзаводе и могу рассказать, из чего делают пенное; но сегодня — о другом.

Даже если у вас большой опыт работы с Apache Kafka, время от времени наверняка случается зайти в тупик. Например, когда вы конфигурируете и изучаете клиенты или настраиваете и отслеживаете брокеры. Попробуй за всем уследить, когда в конвейере Kafka столько компонентов. В этой статье описано пять частых ошибок и советы по тому, как их избежать на всех этапах — от конфигурирования клиентов и брокеров до планирования  и мониторинга. Эти рекомендации сэкономят вам время и силы.

Привет Хабр! Я Дима, DevOps-инженер в IT-компании.

Эпик-фейлы бывают разные. Можно забыть закоммитить config.json. А можно так упаковать новый эндпоинт, что всё апи ляжет костьми в час-пик и будет тихо плакать под лавиной реквестов. Ручные нагрузочные тесты — это как проверять тормоза на уже летящем с горы автомобиле. Сегодня говорим о том, как автоматизировать эту магию — вшивать проверку производительности прямо в CI/CD, чтобы не краснеть перед продом и спокойно спать по ночам.

Запускайте свои пайплайны, щупальцы в руки — погнали!

Мы не раз разбирали в своём блоге теорию и практику по разным стратегиям развёртывания новой версии приложения в Kubernetes. Сегодня рассмотрим ещё одну реализацию канареечного деплоя: с пассивными healthcheck и использованием Argo Rollouts и Istio. Этот вариант подойдёт, если к вашему приложению обращаются не через Ingress, а ходят внутри кластера по адресу service. Или если вы хотите видеть, что происходит с пользовательским трафиком на каждом из этапов обновления.

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

Сегодня мы бы хотели поделиться десятком любопытных картографических сервисов, позволяющих открыть что‑то новое в окружающем мире. В нашей подборке: карты плотности населения и наложенные на существующие карты тысячелетней давности; поиск знаменитостей по географии и наложение статей Wiki на города; карты контроля территорий городскими бандами и даже способ написать свое имя природными объектами. Небольшая ремарка — большую часть карт лучше рассматривать на экране десктопа или ноутбука (и желательно с диагональю побольше), так как мобильные браузеры могут плохо справляться с визуализацией.

Теоретическую основу кэширования DNS в Linux мы разбирали в первой части, где говорили про работу процесса разрешения имен — от вызова getaddrinfo() до получения IP-адреса. Вторая часть была посвящена различным уровням кэшей самой системы, приложений и языков программирования, контейнеров, прокси - а также их мониторингу и сбросу. Теперь самое время перейти к практике.

Если вы когда-либо запускали подряд команды ping, curl, dig и получали разные IP-адреса, вы не одиноки. Поведение DNS в Linux — не просто вызов getaddrinfo(). Это взаимодействие множества слоёв: от glibc и NSS до NetworkManager, systemd-resolved, dnsmasq и облачных конфигураций. В этой части разберем практические аспекты DNS:

почему одинаковые запросы дают разные IP

как реально контролируется разрешение имен: что вызывает кого и зачем

как проводить диагностику: strace, resolvectl, tcpdump