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