Кастомный экспортер Prometheus: где ломается сбор метрик
Типовая картина: сервисы отвечают, дашборд зелёный, а об инциденте узнаём из жалобы пользователя. Формально сбор метрик настроен, но покрывает только те компоненты, которые сами отдают показатели. Всё остальное для наблюдаемости не существует — хотя деградация чаще всего начинается именно там.
Пробелы в мониторинге складываются из трёх источников. Часть данных живёт в закрытых системах — проприетарных или чужих, куда штатный агент не поставишь и открытого эндпоинта у них нет. Часть выдаётся в неудобном виде: числа есть, но лежат в логах, таблицах или ответах внутреннего API, откуда их никто не забирает. Ещё часть появляется только при ручной сверке — инженер сводит отчёты и глазами ищет расхождения, которые в реальном времени не видит никто.
Стандартный экспортер тут не помогает: ему нужен источник, который уже говорит на языке метрик. Если сервис отдаёт только строки в журнале, агрегаты в базе или счётчики в очереди, между ним и системой мониторинга нужен слой-переводчик — со своей логикой опроса, разбором ответов и приведением значений к единому виду.
Кастомный экспортер Prometheus превращает такие источники в обычные метрики закрытых систем: их видно на общих графиках, по ним срабатывают оповещения и правила агрегации. Дальше разбираем, как это закрывается — от выбора источников и схемы опроса до проверки, что цифры на графике не расходятся с реальностью.
Что даёт свой сборщик метрик: эффект в измеримых величинах
Время диагностики инцидента
Метрики приложения попадают в ту же шкалу времени, что и показатели хостов, очередей и баз, поэтому сопоставлять логи из разных систем вручную больше не нужно. Причина деградации читается по графику: видно, на каком шаге выросла задержка или просела доля успешных операций. Дежурный идёт к конкретному сервису, а не перебирает всю цепочку.
Раннее обнаружение отказов
Сборщик отдаёт сигналы по внутренним очередям, пулам соединений и повторам запросов — то, что раньше проявлялось только жалобой пользователя. Правила срабатывают на отклонение от обычного профиля нагрузки задолго до того, как сервис перестаёт отвечать.
Полнота картины мониторинга
Стандартные агенты видят процесс, но не смысл: сколько заказов обработано, сколько операций отклонено. Кастомные метрики закрывают этот разрыв, и панель отражает путь запроса целиком — от входного шлюза до записи в хранилище.
Доля отказов до обращения пользователей
Когда сигналы идут по бизнес-событиям, а не только по доступности, большую часть сбоев фиксирует дежурный, а не служба поддержки. Обращение «всё сломалось» перестаёт быть основным каналом обнаружения.
Общая точка правды
Один набор метрик используют дежурные, разработчики и владелец продукта, без сведения данных из нескольких панелей. Спор «на нашей стороне всё работало» закрывается объективными числами.
Варианты реализации экспортера: сравнение подходов
Выбор схемы определяется тремя вещами: есть ли доступ к коду сервиса, сколько живёт процесс и что произойдёт с метриками при недоступности сборщика. Ниже — четыре варианта, между которыми реально выбирают, и их ограничения.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Сбор внутри приложения | Код под нашим контролем, процесс живёт постоянно, нужны метрики бизнес-логики | Требует правки кода и релиза; библиотека тянет зависимости; при падении процесса данные теряются |
| Отдельный сервис-сборщик рядом | Есть внешние системы без доступа к коду: СУБД, очереди, файлы, чужие сервисы | Точек отказа две; нужны свои таймауты и промежуточное хранение; метрики отстают на шаг опроса |
| Выгрузка по расписанию | Пакетные задания и отчёты, показатели которых считаются раз в сутки | Между запусками данных нет; нужна защита от дублей и «залипших» серий |
| Шлюз для короткоживущих заданий | Задачи, живущие секунды: миграции, разовые обработки, проверки | Легко получить устаревшие серии; нужна явная очистка после завершения задания |
На практике схему почти всегда совмещают: постоянные сервисы отдают метрики сами, внешние системы опрашивает отдельный сборщик, а короткие задания проходят через шлюз. Мы разводим эти контуры по разным правилам сбора, чтобы сбой одного не портил серии остальных, и оставляем переход между вариантами обратимым — экспортер можно перенести из приложения в отдельный сервис без переписывания запросов и дашбордов.
Как мы внедряем сбор метрик: этапы работ
Этапы внедрения мониторинга идут от инвентаризации до передачи в эксплуатацию, и каждый опирается на результат предыдущего. Порядок снимает главную причину провалов: кастомный экспортер Prometheus пишут раньше, чем выясняется, что часть показателей отдаётся штатно, а часть требует доработки на стороне источника.
- Аудит источников метрик. Инвентаризация систем: приложения, базы, очереди, балансировщики, внешние сервисы. По каждому фиксируем, что отдаётся штатно, а что придётся считать самим, и с какой частотой.
- Схема потоков и модель данных. Типы показателей (счётчик, измеритель, гистограмма), набор меток и предельная кардинальность, чтобы хранилище не разрасталось. Решаем, где нужен кэш, а где — прямой опрос.
- Реализация сбора. Разбор ответов источника, устойчивость к задержкам и частичным сбоям, служебный адрес состояния и метрика самоконтроля. Опрос ведём только на чтение.
- Настройка сбора данных. Цели, интервалы опроса, правила пересчёта, пороги оповещений и панели наблюдения. Метрика без оповещения и графика бесполезна.
- Проверка под нагрузкой. Сверяем значения с первичными данными, смотрим расхождение, поведение при недоступности источника и рост кардинальности. Нагрузка на источник остаётся в согласованных пределах.
- Передача эксплуатации. Конфигурации, схемы потоков, регламент дежурства и инструкция, как добавить новую метрику своими силами, не переписывая сборщик.
Что остаётся в инфраструктуре после внедрения
Внедрение заканчивается не в момент, когда метрики пошли, а когда дежурная смена читает их без автора и может починить сбор своими силами. Поэтому передача — это фиксированный перечень артефактов, а не устный рассказ на созвоне. Ниже то, что остаётся у вас на руках после сдачи кастомного экспортера Prometheus.
- Конфигурации сбора: манифесты экспортера, цели и интервалы опроса, набор меток — с пояснением, что меняется при добавлении нового узла.
- Схема потоков метрик: путь от источника до хранилища и правил оповещений, с отмеченными точками отказа и способами их обхода.
- Документация по метрикам: тип, единицы, источник, нормальный диапазон и что означает отклонение — по этому описанию метрику трактуют без автора.
- Правила доступа к метрикам: кто читает, кто меняет пороги оповещений, как выдаётся и отзывается доступ, где хранятся ключи.
- Регламент сбора: периодичность опроса, сроки хранения серий, политика очистки устаревших данных.
- Регламент реагирования: какие срабатывания критичны, кому адресованы, что считается ложным и как корректируется порог.
- Инструкция по расширению: как добавить новую метрику, проверить её локально и выкатить, не ломая уже собираемые.
- Протокол передачи в эксплуатацию: показ дежурной смене, перечень приёмки, окно сопровождения и момент, после которого изменения идут обычным порядком.
Кейс: метрики биллинга без ручной сверки
До внедрения начисления считались в биллинговом сервисе, события уходили в очередь, агрегаты за ночь ложились в хранилище — три источника, которые никто не сопоставлял построчно. Расхождения всплывали только из жалоб: клиент замечал лишнее списание, поддержка заводила разбор, поиск занимал до трёх недель. К этому моменту счёт был выставлен и оплачен.
Что сделали
Написали кастомный экспортёр, который подписывается на поток событий начислений и читает справочник тарифов, не вмешиваясь в логику биллинга — только чтение. Каждое событие превращается в счётчик с метками по клиенту, тарифу и типу операции, а расхождение между суммой по событиям и суммой в счёте уходит отдельной метрикой. Данные забирает Prometheus, пороговое правило оповещения срабатывает на отклонение по конкретному клиенту.
- Этапы: начисление → счёт → списание, с разрывом по каждому переходу.
- Целостность: число событий в очереди против числа обработанных.
- Сверка с прошлым периодом — для медленно накапливающихся расхождений.
- Оповещения с разделением на критичные и требующие разбора.
Результат
Расхождение видно в момент возникновения: сигнал приходит через несколько минут после отклонения вместо трёх недель до этого. Сверкой покрыт весь поток начислений — раньше проверяли выборочные счета по жалобам, теперь ни одна операция не выпадает.
Нагрузка на биллинг не выросла: экспортёр только читает поток и не участвует в проведении платежей. Сборщик переживает перезапуск — позиция в потоке сохраняется, повторной обработки и двойного счёта метрик не возникает.
Чем отличается свой экспортер от готовых сборщиков
Готовый экспортер закрывает задачу целиком, пока источник метрик стандартный. Состояние узла, базы данных, очереди или доступность сервиса по сети описаны в официальном наборе — остаётся поставить сборщик и задать адреса с интервалом опроса. Кода не пишем: нечего сопровождать, поведение предсказуемо для любого инженера в команде.
Ограничения начинаются там, где данные лежат внутри вашей логики. Prometheus только опрашивает точку выдачи метрик по сети — он не знает, как достать остатки из учётной системы, состояние лицензий у вендора или очередь необработанных заявок. Обходной путь — скрипт по расписанию с текстовым файлом — живёт до первого сбоя: метрика стареет, дублируется при перезапуске, а при отсутствии данных отдаёт ноль вместо пропуска.
Второе ограничение — форма данных. Готовые сборщики отдают сырые счётчики, а решения принимают по производным: доле ошибок, времени ожидания, числу объектов в нештатном состоянии. Свой сборщик считает это на месте сбора, держит последнее известное значение, помечает устаревшие серии и повторяет запрос с нарастающей паузой.
Четыре вопроса решают выбор: есть ли у источника документированная точка выдачи метрик; выражается ли модель данных настройками; укладывается ли полный обход объектов в интервал опроса; нужны ли разграничение доступа и фильтрация по клиентам. Отрицательный ответ хотя бы на один — и готовое решение придётся обвешивать костылями. Выгоднее гибрид: типовое собираем готовыми сборщиками, свой пишем под пробел — компактным сервисом с тестами, отдельным контуром отказа и собственными метриками работоспособности.
Технические сомнения по сбору метрик и ответы
Кастомный экспортер встаёт между системой мониторинга и продакшн-контуром, поэтому возражения про нагрузку, доступы и дальнейшую поддержку справедливы. Ниже отвечаем на те, что чаще всего звучат на этапе оценки. Все четыре снимаются на уровне архитектуры сбора, а не обещаниями.
Не добавит ли экспортер нагрузку на продовую базу?
Опрашиваем через отдельное подключение только на чтение, агрегируем на стороне источника и кэшируем между опросами, тяжёлые выборки разнося по расписанию. Интервал опроса привязан к критичности метрики: то, что нужно раз в минуту, не тянется ежесекундно.
Как вы получите доступ к закрытой системе?
Экспортер ставим внутри вашего контура: он открывает только исходящее соединение к серверу сбора, входящие порты не пробрасываются. Учётная запись — с правами только на чтение нужных представлений, для изолированных контуров передача идёт по уже согласованному у вас защищённому каналу.
Можно ли добавить метрику, не останавливая сервис?
Набор метрик описан декларативно: новая добавляется правкой конфигурации и перезапуском только экспортера, целевой сервис не останавливается. Схему имён и меток фиксируем заранее, чтобы дополнение не ломало дашборды и правила оповещений.
Что входит в поддержку сбора метрик?
Передаём конфигурации, схему метрик и инструкцию по типовым изменениям — ваша команда добавляет метрики без нас. Отдельно описываем поведение при недоступности источника, чтобы сбой сбора было видно отдельно от сбоя самого сервиса.
Обсудим вашу задачу по сбору метрик
Чтобы оценка работ по сбору метрик была предметной, а не «по ощущениям», на первом разговоре нам нужна картина вашей инфраструктуры: какие источники уже отдают данные, что снимается вручную, где расхождения с реальностью. Разбираемся, где действительно нужен кастомный экспортер Prometheus, а где достаточно штатных средств и настройки.
Что уточняем, прежде чем вернуться с планом внедрения сбора:
- Какие источники метрик есть сейчас и в каком виде отдают данные — встроенный экспорт, файлы журналов, внутренние программные интерфейсы, обращения к базе.
- Что именно должно стать измеримым: задержки обработки запросов, глубина очередей, доля ошибок, состояние подключений, свежесть данных.
- По какой частоте опроса и глубине хранения строить расчёты, чтобы данные не терялись и при этом не разрастался реестр.
- Какие правила разметки нужны, чтобы метрики разных сервисов сопоставлялись между собой и не превращались в тысячи лишних наборов.
- Как данные попадают в ваши панели и оповещения и какие сигналы должны поднимать дежурного ночью, а какие — только писать в отчёт.
- Требования к доступам, сетевой доступности и порядку остановки сбора, если экспортёр придётся снять или переключить на резервный источник.
Опишите задачу мониторинга — вернёмся с оценкой работ по сбору метрик и планом внедрения: этапы, состав конфигураций, сроки и способ проверки, что метрики соответствуют реальному состоянию системы.
