Налаштування OpenTelemetry Collector для агрегації телеметрії в Kubernetes

OpenTelemetry Collector у Kubernetes: де рветься збір телеметрії

Під час налаштування OpenTelemetry Collector у Kubernetes перший робочий варіант майже завжди збирається на одному екземплярі: приймання сигналів, батчинг, надсилання до сховища.

Поки сервісів десятки, схема тримає потік, а на сотнях подів і кількох вузлах починає втрачати дані — причому непомітно, бо сам шар спостережуваності ніхто не спостерігає.

Перше місце відмови — черга надсилання. Якщо сховище відповідає повільніше, ніж іде потік, буфер заповнюється і колектор починає відкидати сигнали за заданою політикою.

Лічильник відкинутого є, але його ніхто не читає: пропуски в спостережуваності збігаються в часі з деградацією сервісу, тобто трапляються рівно тоді, коли дані потрібні найбільше.

Друге — дублювання. Сайдкар поруч із застосунком, агент на кожному вузлі та спільний агрегувальний шар можуть надсилати ті самі дані кілька разів.

Лічильники та гістограми сумуються двічі, панелі показують завищене навантаження, а оповіщення спрацьовують на цифрах, яких насправді немає.

Третє — сліпі зони в частині сервісів: десь залишився старий агент, десь не додано інструментацію, а збір трейсів іде лише за частиною шляхів запиту. Відмова в такому сервісі не видна в загальній картині, поки про неї не повідомлять користувачі.

Окрема стаття витрат — навантаження на застосунки. Синхронне надсилання з процесу, обробка та розрідження на боці сервісу забирають ресурси в робочої логіки, а за сплеску трафіку черга всередині застосунку зростає швидше, ніж устигає розвантажуватися.

Розбираємо, де ставити приймання та агрегацію, як винести обробку в окремий шар і налаштувати обмеження пам'яті так, щоб пріоритетні сигнали доходили навіть під навантаженням.

Що дає єдиний контур телеметрії: ефект у цифрах

Єдиний контур телеметрії — це коли метрики, логи та трейси йдуть через один шар зі спільними правилами фільтрації, збагачення та маршрутизації. Раніше кожен сервіс писав своїм агентом в окреме сховище, і питання «що сталося» перетворювалося на ручний обхід кількох систем.

Тепер OpenTelemetry Collector приймає сигнали, приводить їх до спільних атрибутів і розкладає за призначенням.

На прийманні фіксуємо вимірювані ефекти:

• Час пошуку причини збою: було — години на звірку панелей, стало — хвилини, бо за одним ідентифікатором запиту видно весь ланцюжок від вхідного вузла до бази.
• Втрати телеметрії: частка втрачених вимірювань падає з відсотків до десятих часток завдяки буферизації на агенті та повторному надсиланню за недоступності сховища.
• Обсяг збережених даних: скорочується в рази — службові метрики та зайві атрибути відсікаються на вході, а не після запису.
• Класи відмов: перестають бути невидимими обриви з'єднань, деградація затримок і помилки, які проковтувалися повторними спробами.
• Охоплення: нові сервіси підключаються шаблоном конфігурації, тому частка спостережуваних сервісів зростає без окремого проєкту.

Окремо перевіряємо, що контур не став єдиною точкою відмови: за недоступності приймача агенти пишуть у локальний буфер і після відновлення наздоганяють потік без ручних дій.

OpenTelemetry Collector: варіанти розгортання в кластері

Розгортання збирача в кластері — це насамперед вибір точки, у якій телеметрія збагачується та фільтрується.

Той самий OpenTelemetry Collector ставлять агентом на кожному вузлі, допоміжним контейнером поруч із застосунком або спільним шлюзом — або не ставлять узагалі, і сервіс надсилає дані напряму.

Робоча схема майже завжди гібридна: збір на рівні вузла дає дешевий потік логів і метрик, а централізований шлюз бере на себе важке — хвостове семплування, маскування чутливих полів, маршрутизацію потоків телеметрії за бекендами. Від вибору точки залежить, де втрачаються дані під час збою і хто відповідає за їх доставку.

Що вибрати під задачу

Варіанти комбінуються: агент і шлюз з'єднуються по OTLP, а допоміжний контейнер залишають там, де сервісу потрібні власні перетворення до надсилання.

Порядок впровадження: від інвентаризації джерел до передачі

Порядок робіт будуємо так, щоб до правок у конфігурації була видна вся картина трафіку, а після — зрозуміло, що саме змінилося. OpenTelemetry Collector розгортаємо не «як у документації»: набір приймачів, обробників і експортерів добираємо під конкретний парк сервісів.

1. Аудит джерел телеметрії. Інвентаризація: які сервіси й агенти віддають метрики, логи та трейси, у якому форматі й як часто. Окремо фіксуємо прогалини — ділянки, де дані не збираються взагалі або дублюються різними шляхами.
2. Схема потоків даних. Проєктуємо маршрути від приймачів через обробники до сховищ: де батчинг, де повторні надсилання, де буфер на диск. Схему узгоджуємо до налаштування — інакше конфігурація зростає стихійно.
3. Правила обробки та фільтрації. Відсікаємо шумні метрики й службові атрибути, задаємо розрідження трейсів, розводимо потоки за різними сховищами та командами. Правила живуть у репозиторії, а не правляться вручну на працюючому сервісі.
4. Перевірка збору під навантаженням. Прогоняємо реальний трафік, а не тестові дані: дивимося частку втрачених записів, затримку доставки, споживання пам'яті та поведінку за недоступності сховища.
5. Відмовостійкість і ліміти. Обмежуємо черги та пам'ять, налаштовуємо повторні надсилання так, щоб короткочасний збій приймача не перетворювався на втрату даних.
6. Передача та навчання. Віддаємо конфігурації, схему, регламент змін і розбір типових збоїв: чергова команда додає нове джерело за готовим шаблоном.

Конфігурації, схеми маршрутизації та регламенти на виході

Наприкінці робіт у команди замовника залишається не набір разових правок на стенді, а робочий контур телеметрії: конфігурація збирача, маршрутизація, правила обробки та регламент, за яким усе це живе далі.

Файли лежать у репозиторії під контролем версій — зміни проходять рев'ю, а не правляться вручну на кластері.

• Конфігурація збирача — приймання даних із застосунків і вузлів, обробка, вивантаження до сховищ; окремі гілки під метрики, логи та трейси, щоб навантаження одного потоку не затримувало інші.
• Схеми маршрутизації даних — що куди йде, за якими правилами розділяються потоки і як налаштовується доставка за недоступності приймача.
• Правила фільтрації та збагачення — відсікання шумних подій, розрідження, додавання атрибутів середовища й сервісу, щоб за записом знаходилося джерело.
• Політики доступу до даних — хто з команд бачить які потоки і як обмежується доступ до чутливих атрибутів.
• Регламент експлуатації — порядок оновлення конфігурації, контроль стану збирачів, реакція на переповнення буферів і деградацію доставки.
• Документація з телеметрії — опис потоків, домовленості про іменування, типові запити та точки розширення для нових сервісів.

Окремо фіксуємо карту потоків і передаємо її разом із конфігурацією: видно, який сервіс що надсилає і які правила до цього застосовані. Нові джерела підключаються за готовим шаблоном — без перегляду всієї схеми.

Кейс: як скоротили обсяг телеметрії та час пошуку збою

В одному з проєктів телеметрія йшла до сховища без розбору: зберігалися всі спани, включно з перевірками доступності кожні кілька секунд, метрики з ідентифікаторами запитів в атрибутах і дублі логів від реплік сервісу.

OpenTelemetry Collector стояв у режимі простої пересилки, тому корисних записів було близько чверті — решта не брала участі ні в алертах, ні в розборі збоїв, але зростала в обсязі та сповільнювала вибірку.

Що змінили в конвеєрі

Розділили приймання, обробку та вивантаження на окремі конвеєри. Спани перевірок доступності відкидаються на вході, з атрибутів прибрано ідентифікатори запитів і сесій — вони давали основну кардинальність.

Метрики інфраструктури розріджено до рівня сервісу, трейси зберігаються вибірково: усі запити з помилками, повторними спробами та аномальною тривалістю залишаються цілком. Зверху — буферизація батчами й обмежувач пам'яті, щоб за сплеску трафіку не втрачалися дані на приймачі.

Результат у цифрах

Обсяг телеметрії у сховищі скоротився в 4,5 раза: надлишковими виявилися 78% вхідного потоку. Час пошуку причини збою впав з 90 хвилин до 12–15 — інженер відкриває потрібний трейс, а не перебирає збіги за назвою сервісу.

Зникли втрати вимірювань на піках: раніше на переповненні черги втрачалося до 5% точок, тепер жоден спан з помилкою не пропадає. Правило «відкидаємо лише те, що ніхто не читає» спрацювало: метрики бізнес-рівня та все, що бере участь в алертах, зберігаються в повному складі.

Що робити, якщо частина сервісів уже надсилає телеметрію

Частково налаштований збір — нормальний стан: частина сервісів уже віддає метрики й трейси напряму, частина знімається опитуванням, решта не спостережувана взагалі.

Небезпечна не розрізненість, а спроба перемкнути все одразу — пауза в телеметрії дає сліпі алерти в момент, коли вони потрібні найбільше.

Починаємо з інвентаризації: які схеми збору працюють зараз, де дані дублюються і які дашборди на них зав'язані. Далі OpenTelemetry Collector ставиться поруч і стає другою адресою доставки — працюючі шляхи він не замінює.

Сервіси, які вже надсилають телеметрію відкритим протоколом, змінюють лише адресу приймача: код і бібліотеки не чіпаються. Ті, що віддавали метрики опитуванням, підключаються через виявлення сервісів за анотаціями подів — новий збір іде паралельно зі старим.

Підключення йде за namespace або за командою, а не одразу: обидві схеми співіснують, поки не підтверджено паритет. На кожному кроці звіряємо кардинальність метрик, атрибути ресурсу та відсутність дублів — так видно, що через колектор надходять ті самі дані.

Перерви в спостережуваності не виникає: на колекторі увімкнено буфер, і за недоступності бекенда дані наздоганяють чергу, а не губляться. Відкат теж дешевий — повертаємо попередню адресу доставки, про що домовляємося до початку міграції.

Часті технічні сумніви перед впровадженням

Перед впровадженням OpenTelemetry Collector команди ставлять майже ті самі запитання: скільки ресурсів забирає в застосунку збір даних, що відбувається за відмови шлюзу, як утримати обсяг під контролем і як розвести потоки між командами. Нижче — короткі відповіді на кожне.

Що буде, якщо шлюз недоступний?

Збирач працює репліками за балансувальником, тому втрата одного екземпляра потік не рве. Агенти тримають локальний буфер на диску й повторюють надсилання з наростаючою паузою: дані надходять із затримкою, але не губляться. За тривалої відмови вмикається обмеження обсягу, щоб не переповнити диск вузла.

Як обмежити обсяг зібраних даних?

Обсяг задається на боці збирача: правила фільтрації відсікають службові та шумні метрики, а розрідження знижує частоту опитування там, де важлива динаміка, а не точність. Дані зростають разом із кількістю сервісів лише там, де це усвідомлено закладено.

Чи можна розмежувати доступ між командами?

Так. Кожній команді видається свій набір ключів і правила, за якими збирач розкладає дані за різними сховищами: команда бачить лише свої сервіси. Спільні правила змінюються через рев'ю, тому випадкова правка не відкриє чужі дані.

Обговоримо задачу: що надіслати для попередньої оцінки

Щоб розмова про контур телеметрії була предметною, а не переказом документації, надсилайте вихідні дані — за ними ми повернемося з оцінкою та планом робіт, без листування на два тижні вперед. Нижче — що зазвичай знімає більшу частину невизначеності ще до старту.

• Кластери та відповідальність: скільки контурів, де розміщені, керовані чи власні, хто володіє вузлами та їх оновленнями.
• Джерела даних: які сервіси та мови, що вже інструментовано, які збирачі метрик, логів і трейсів працюють зараз.
• Конфігурація агрегатора: робочі файли OpenTelemetry Collector або чарти — які приймачі, обробники та вивантаження задіяні, що змінювалося останнім.
• Обсяги: кількість активних серій метрик, добовий потік логів, частка збережених трейсів — порядку достатньо, точність до відсотка не потрібна.
• Приймачі телеметрії: куди дані пишуться сьогодні, терміни зберігання, вимоги безпеки та ізоляції контурів.
• Доступи: ролі та сервісні облікові записи, мережеві політики, обмеження на вихідні з'єднання.
• Вимоги до надійності: допустима затримка доставки, поведінка за перевантаження, хто отримує оповіщення і як реагує.

Опишіть задачу своїми словами та додайте те, що є: повний набір не обов'язковий. Наші інженери розберуть контур, покажуть вузькі місця й повернуться з оцінкою та планом робіт — до будь-яких змін у продакшені.