Сбор метрик или отправка метрик - разница, которая может искривлять данные

Привет, киты 🐳!

Если вы думаете, что сбор метрик по pull-модели и отправка через push это примерно одно и то же, то я вас разочарую. Это не так. В push-модели есть особенности, которые заставят ваши данные выглядеть совсем не так, как вы ожидаете. А иногда разработчики пытаются писать метрики в VictoriaMetrics Remote-write эндпоинт в том же формате, что и для Prometheus PushGateway, а потом искренне удивляются, почему метрики не появляются. Многообразие форматов действительно может породить путаницу.

Зачем вообще отправлять метрики напрямую, вместо обычного вытягивания из эндпоинта /metrics?

Для короткоживущих приложений интервал сбора при pull-модели может оказаться больше времени работы самого приложения. Сборщик просто не придет. Частый пример: cron-задачи или PHP-приложения, которые живут только на время обработки запроса. Тут push метрик спасает. Хотя нет, вру, можно придумать свое костыльное хранилище на Redis и выставить их для сбора на /metrics. Но по факту это просто изобретение PushGateway, которое тащит лишнюю зависимость.

Кстати, для cron-задач, которые выполняются более 3-5 минут, я рекомендую выставлять отдельный /metrics эндпоинт и настраивать обычный pull-сбор. Это оправдано, когда вы хотите следить за прогрессом задачи в реальном времени, а не только получить данные о факте ее начала и окончания.

Но вернемся к граблям. Вот кусочек из кода модуля для отправки метрик в Prometheus PushGateway, с которым мы столкнулись:

return &Pusher{
    inner: push.New(endpoint, serviceName). // выставить в метрике job=serviceName
        Gatherer(gatherer).
        Grouping("k8s_cluster_name", cfg.clusterName).
        Grouping("k8s_namespace_name", cfg.namespace).
        Grouping("k8s_pod_name", cfg.podName).
        Grouping("k8s_cronjob_name", cfg.cronjobName).
        Grouping("k8s_job_name", cfg.jobName)
}

Вы можете по ошибке решить, что здесь добавляются лейблы в метрику. Но это не так (хотя Prometheus и увидит их как лейблы при сборе). Для самого PushGateway Grouping это как адрес книги в библиотеке (ряд, полка, раздел). Он отвечает за физическое хранение переданной в него группы метрик в памяти шлюза.

В PushGateway есть два поведения: перезаписывать (Push) и добавлять (Add). Для cron-задач подходит перезапись, так как нам важны данные о последнем запуске. Но в примере выше Grouping неверный. Если засунуть динамические значения (например имя пода) в Grouping, для каждого запуска cron или каждого пода создается новый адрес хранения. В итоге вы не видите полной картины по одной задаче. Хуже того, старые ячейки с метриками мертвых подов останутся в PushGateway навсегда. Он не удаляет метрики сам по TTL, поэтому они будут копиться как мусор, пока их не очистят через API. Это классическая утечка памяти.

Как это чинить?

Grouping key должен быть стабильным. Для cron-задач оставить в grouping только job (имя сервиса) и instance (имя самого крона). Всё остальное (namespace, pod_name и прочее) перенести в обычные лейблы метрик. Это решит проблему с мусором и некорректными графиками.

А вы используете PushGateway в своих проектах или стараетесь избегать его любой ценой, перестраивая архитектуру под pull? И сталкивались ли с проблемой вечных метрик в PushGateway после смерти подов?

#SRE #prometheus #PushGateway #observability #метрики #DevOps #ЛетитКит

Опрос про SRE в 2026 году.

Привет, киты 🐳!

Прошлый опрос дал вот такой отчет https://devcrowd.ru/sre-2025

А теперь ребята из DevCrowd запустили новое исследование для SRE, DevOps и платформенных инженеров.

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

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

Опрос анонимный, займет 10-12 минут. Отчет с динамикой к прошлому году обещают в начале декабря.

Пройти опрос: https://survey.devcrowd.ru/sre-2026

Что из вашего опыта точно еще не стоит отдавать Ai?

#SRE #DevOps #исследование #AI #надежность #DevCrowd

Прямо сейчас! Вылетаю на HardFest 2026 в Екатеринбурге.

2 попытка, Москва отпусти к ребятам, Екатеринбург принимай гостей!

Несу доклад https://2026.hardfest.ru/lecture/3814

#конференция #Екатеринбург #HardFest #sre #доклад

Кстати презентацию к докладу "Cбор логов на vector и clickhouse — то, что ИИ за тебя не сделал бы" выложил тут https://r3code.github.io/report-logs-collection-in-ai-era/

Впервой делал полностью через AI используя за конструктор перезнтаций sli.dev. Ассистентом был бесплатный z.ai в режиме Agent, скинул ему временный токен github и адрес репозитория, правила как оформлять. Он инициализировал структуру репозитория, попросил положить картинки в public/images и дальше содержимое для слайдов. Позже добавили github actions для публикации в PDF и PPTX как картинки.

Помню как я лютовал на одной из конференций, что мне не дали использовать PDF. Вот тут эта проблема решается публикацией PPTX с слайдами картинками.

Картинки только пришлось отдельно нарисовать. Раньше мог прямо на Google слайдах рисовать - это единственное неудобство.

Полезное: наш общий знакомый - Михаил Савин, написал отличное руководство по работе с sli.dev - https://jtprog.ru/posts/slidev/. Полезно показать эту статью агенту перед началом работы. В ней есть и мой небольшой вклад, т.к. я боролся со встроенным счетчиком страниц/кликов в PDF, который никак не хотел скрываться. В итоге победил это и Мише рассказал, а он добавил в свою статью.

А как вы делаете презентации? Докапываетесь к стилю или просто просите сделать "сделай в этом стиле"?

#перезентации #ИИ

Если хотите узнать как вы выглядите для своей LLM вставьте этот промт - результат вас заинтригует, насмешит, расстроит, мотивирует, встряхнет:

Based on everything you know about me, roast and don’t hold back. Say it in Russian slang Just like this, but add way more Russian swear words

Как вам результат? )

#ai #self #неожиданное

Скоро будет пост пост-хардфестный, и вы узнаете насколько далеко может завести случайно включенное радио... причем тут бетон и железо с Урала.

Внезапное, про радио из личного опыта.

Привет, киты 🐳!

Я работаю чаще всего под музыку, но что-то плейлист и как его начала подбирать Яндекс Музыка перестал радовать. Видимо я уже привык. И вот я однажды попросил включить Алису радио, и она внезапно включила Благодать FM... я подумал сейчас будет трансляция службы из церкви, или обсуждения библии. Но внезапно из динамика я услышал рок: Крылья - Дух рок-н-рола, потом Аврил Лавин, потом какую-то нашу попсу, снова что-то новое, что не слышал. Это было необычно.

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

https://blagofm.ru/ - офигенное радио Благодать FM с непредсказуемым треклистом, который вас заинтригует, после чего вы поймете, что радио еще может быть классным.

Благодать - это гора в черте города Кушва, где более 250 лет добывали железную руду.

Я вам рассказываю об этом, что это радио настолько меня поразило и порадовало, что я от них зафанател.

Да настолько, что появилась мечта съездить в это городок. И вот, когда был недавно на HardFest 2026 в Екатеринбурге - взял каршеринг и поехал 200км в Кушву, чтобы посмотреть сам городок и место откуда вещает это радио. Просто потому что очень захотелось.

И это было классно. Погода угодила, было тепло и солнечно. А город оказался основан в 1735 году! Я увидел тот самый карьер, город с высоты горы, который между прочим стоит на своем "море" - было красиво.

Мечта сбылась.

> А что вы делали такого неожиданного для себя, после чего чувствовали - "это то что было нужно"?

#жизнь #баланс #неработа