Почему я так упираюсь в связку “трейсы + логи”? Потому что это реально магия. Ты открываешь проблемный трейс, видишь trace_id, и дальше хочешь в один клик найти все логи по этому запросу. Чтобы это работало, логгер должен вытаскивать trace_id и span_id из контекста.

Идея простая: у каждого запроса есть trace_id, и по нему ты видишь весь путь запроса через сервисы, очереди, базы и внешние интеграции. Внутри trace есть span — атомарные операции. Хорошая новость в том, что большая часть спанов создаётся автоматически, если ты используешь нормальные инструменты (HTTP middleware, SQL драйверы с OTel-инструментацией, клиенты Kafka/Redis и т.д.). Плохая новость в том, что бизнес-логика “между ними” сама себя не оттрассирует, и иногда надо уметь добавить span руками.

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

Плюс есть технические метрики, которые не про сервис в целом, а про конкретную бизнес-механику: сколько сообщений улетело в DLQ, сколько промахов у кэша, как часто включается fallback. Такие числа позволяют развивать сервис на цифрах, а не на ощущениях.

Проблема: Традиционное нагрузочное тестирование включает в себя обширную ручную корреляцию данных с бэкэндом и часто заходит в тупик из-за «слепых зон» в коде приложения и распределенных системах.

Решение: Благодаря автоматической инструментации скриптов Locust с помощью OpenTelemetry, нагрузочные тесты теперь будут генерировать сигналы OpenTelemetry. Эта телеметрия нагрузочных тестов передается в платформу мониторинга на основе OTel в режиме реального времени, позволяя визуализировать каждый запрос нагрузочного тестирования и отслеживать всю его транзакцию. Теперь у вас есть полная сквозная видимость — ваши запросы нагрузочного тестирования коррелированы с вашим приложением, инструментированным OTel.

Наш API был медленным. Не сломанным — просто медленным.

Таким медленным, из-за которого пользователи обновляют страницу. Таким, из-за которого телефон кажется старым. У нас была задержка 200 мс на эндпоинтах, которые должны были отвечать за 40 мс. Каждая оптимизация, которую мы пробовали, делала всё только хуже. Затем я удалил большую часть нашей конфигурации Kubernetes. Задержка снизилась до 35 мс.

С официальным прекращением поддержки Ingress NGINX, запланированным на март 2026 года, пользователи Kubernetes сталкиваются с серьёзным архитектурным изменением. Это прекращение поддержки знаменует собой прекращение выпуска обновлений безопасности и исправлений ошибок, поэтому командам разработчиков крайне важно оценить планы миграции уже сейчас.

Один из самых простых и удобных в обслуживании путей — переход от традиционных ресурсов Ingress к Gateway API, современному стандарту сетевого взаимодействия в Kubernetes. Для упрощения этого процесса сообщество Kubernetes SIG Network предоставляет инструмент ingress2gateway с открытым исходным кодом, который автоматически преобразует объекты Ingress в ресурсы Gateway API.

Теперь Postgresus — это Databasus. И поддерживает другие базы: MySQL, MariaDB и MongoDB (при этом оставляя основной фокус на PostgreSQL).

3 часа ночи. Звонок от незнакомого номера. ”Пользователи не могут залогиниться, п****ц”.

Вы лихорадочно листаете Slack. Непонятно, где проблема и кого будить. Подняли тестеров — они тоже гадают. Бэкенд? Инфра?

Идёте во флудилку в телеге, ищете похожий ник тимлида. Не отвечает. Кто замещает - никто не знает. Начинается массовый обзвон. Через 40 минут находится человек. Смотрит код. “Не моё. Это к Сане — он, кажется, редирект криво поменял в гугл клауд консоли”. Ещё 20 минут — поиск Сани, доступы только у него.

Утром все разбитые. CTO вопрошает. И становится ясно: баг простой. Проблема не в коде. Проблема в бардаке.

Знакомо? Я тоже через это прошел. И после такой ночи решил: хватит. Нужна система.