Блог on OpenTelemetry

До вашої уваги: схеми та еталонні реалізації OTel

Sat, 16 May 2026 16:36:53 +0300

Користувачам, які впроваджують OpenTelemetry, нерідко доводиться на певному етапі задаватися питанням: «Чому все це так складно?». Повне впровадження зазвичай вимагає розуміння різних способів налаштування SDK, розгортання декількох Колекторів, конвеєрів даних, бібліотек інструментування, реєстрів семантичних домовленостей, API для ручного інструментування різними мовами програмування та багатьох інших складових.

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

Огляд OpenTelemetry.io 2025

Tue, 28 Apr 2026 03:49:32 +0300

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

Основні події 2025 року

Якщо 2024 рік став роком заснування багатомовної документації, то 2025 рік — роком, коли локалізація стала основним стовпом OpenTelemetry.io. Це означає більше учасників, більше перекладів, більше підтримуваних мов і більшу видимість локалізованого контенту.

Як Mastodon використовує колектори OpenTelemetry у своїй роботі

Wed, 08 Apr 2026 18:59:37 +0300

На початку 2025 року, OpenTelemetry Developer Experience SIG опублікувала результати свого першого опитування спільноти. Одне з найголовніших побажань було цілком очевидним: команди хочуть бачити більше реальних прикладів того, як SDK OpenTelemetry та OpenTelemetry Collector фактично використовуються у роботі.

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

Поза межами "Good First Issue" — Як зробити вашу участь постійною

Wed, 08 Apr 2026 18:58:44 +0300

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

Більшість посібників пояснюють, як знайти “good first issue”, зробити форк репозиторію або приєднатися до зустрічі SIG. Ці поради корисні, і багато ресурсів добре їх висвітлюють. Те, що часто отримує менше уваги, це ширший контекст участі: розуміння екосистеми, орієнтація в динаміці спільноти та побудова довгострокової участі у великому проекті з відкритим кодом.

Дослідження щодо використання OpenTelemetry Collector

Tue, 03 Feb 2026 19:54:17 +0200

У 2024 році End User SIG провела Collector Survey, щоб зібрати відгуки про те, як колектор OpenTelemetry використовується на практиці, та про досвід користувачів. Результати цього опитування вплинули на кілька рішень щодо розвитку та пріоритетності в рамках спільноти.

Як продовження, у 2025 році ми провели ще одне опитування, щоб зрозуміти, як з того часу змінилися практики розгортання, моделі використання та проблеми впровадження. У цій публікації в блозі представлено аналіз результатів, у якому висвітлено найважливіші зміни порівняно з попереднім роком.

Покращення спостережуваності асинхронного процесу в Dapr

Tue, 03 Feb 2026 19:52:13 +0200

Цей пост розповідає про те, як учасники спільноти хмарних технологій обʼєднали свої зусилля для вдосконалення інтеграції OpenTelemetry в Dapr, зокрема в частині асинхронних робочих процесів. У ньому також висвітлюються поточні зусилля з приведення Dapr у відповідність до семантичних домовленостей OpenTelemetry за допомогою OpenTelemetry Weaver та досліджується, як ця співпраця може стати корисним прикладом для інших проєктів CNCF. Жодна з цих робіт не починалася як офіційна ініціатива. Вона виникла в результаті обговорень, експериментів та спільної мети зробити телеметрію більш зрозумілою та послідовною в усій екосистемі.

Цілі OpenTelemetry eBPF Instrumentation на 2026

Tue, 03 Feb 2026 19:50:25 +0200

Як ми розпочинаємо 2026 рік, SIG OpenTelemetry eBPF Instrumentation прийшла до спільної домовленості про амбітні плани на рік. Наш фокус — досягнення готовності до промислової експлуатації з випуском 1.0, одночасно розширюючи підтримку протоколів та мов, щоб обслуговувати ширший спектр випадків використання. Ми також зміцнюємо інтеграцію з API та SDK OpenTelemetry, щоб підтримувати гібридні підходи до інструментування. Для тих, хто вперше стикається з OBI, перегляньте посилання на документацію вище, щоб дізнатися більше про інструментування без програмування за допомогою eBPF.

Зменшення обсягу журналів за допомогою процесора дедуплікації журналів OpenTelemetry

Wed, 21 Jan 2026 14:31:41 +0200

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

Проблема із повторюваними записами

Сучасні розподілені системи генерують величезні обсяги логів, але значна частина цих записів дає все менший ефект. Розглянемо типовий мікросервіс, який реєструє помилки підключення, коли підлеглий рівень залежності недоступний. Якщо сервіс повторює спробу кожні 100 мілісекунд протягом 30 секунд, це означає 300 майже ідентичних записів у лозі для одного інциденту. Кожен запис споживає памʼять, ресурси мережі та обчислювальну потужність вашого сервера.

Заява OpenTelemetry JS щодо запобігання DOS-атакам на Node.js

Fri, 16 Jan 2026 15:29:32 +0200

Можливо, ви бачили нещодавнє повідомлення про безпеку Node.js та повʼязані з цим матеріали, в яких обговорювалася потенційна проблема відмови в обслуговуванні, повʼязана з async_hooks. OpenTelemetry (та інші інструменти APM) були згадані, оскільки ми покладаємося на AsyncLocalStorage для поширення контексту.

Щоб було зрозуміло: це не є помилкою або вразливістю в OpenTelemetry. Проблема в кінцевому рахунку полягає в застосунках і фреймворках, які покладаються на невизначену поведінку вичерпання стеку для доступності. У версіях Node.js до 24.x AsyncLocalStorage реалізовано на основі async_hooks, що в поєднанні з цим небезпечним припущенням полегшувало відтворення такого крайнього випадку.

Що 10 000 повідомлень Slack розкривають про виклики впровадження OpenTelemetry

Fri, 16 Jan 2026 12:35:18 +0200

Протягом останніх кількох років спільнота OpenTelemetry значно зросла, і разом із цим зростанням зʼявилися цінні інсайти, приховані в наших дискусіях. Ми проаналізували майже 10 000 повідомлень з каналів #otel-collector та #opentelemetry в CNCF Slack за період з травня 2019 року по грудень 2025 року, щоб зрозуміти, з якими проблемами користувачі стикаються найчастіше, які компоненти викликають найбільше обговорень і де спільноті можуть знадобитися додаткові документи або вдосконалення інструментів.

Розвінчання міфів про OpenTelemetry: чому не варто боятися спостережуваності в традиційних середовищах

Fri, 16 Jan 2026 12:34:13 +0200

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

Виклики впровадження спостережуваності в традиційних середовищах:

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

Щоб це стало зрозумілішим, розглянемо вигадану виробничу компанію з напруженим виробничим процесом. Тут парк роботів, оснащених датчиками, передає оперативні дані через MQTT до центрального брокера. Застаріла програма реєструє виробничі події та помилки на диску, а набір серверів SQL і компʼютерів Windows підтримує виробництво, аналітику та інвентаризацію. Звучить знайомо? Це реальність для багатьох організацій, які намагаються поєднати старий і новий світи.

Припинення підтримки Zipkin Exporter

Sat, 03 Jan 2026 23:12:22 +0200

Проєкт OpenTelemetry припиняє підтримку специфікації експортера Zipkin на користь підтримки імпорту OTLP від Zipkin.

Дякуємо всім учасникам Zipkin за допомогу OpenTelemetry у досягненні цього важливого етапу!

Проаналізувавши моделі використання в різних мовних екосистемах, ми помітили, що спільнота значно тяжіє до OTLP, а експортери Zipkin використовуються обмежено — у декількох мовах навіть менше, ніж вже застарілий експортер Jaeger. З огляду на мінімальну зацікавленість користувачів у повʼязаних питаннях та наявність альтернатив, ми вважаємо, що зараз саме час припинити використання експортерів Zipkin в SDK OTel.

Чи іспит OTCA для вас? Інформація для новачків та досвідчених користувачів

Tue, 25 Nov 2025 14:38:50 +0200

В ІТ-галузі сертифікати часто викликають суперечки: одні вважають їх важливими етапами карʼєри, інші ставлять під сумнів їх практичну цінність. Хоча OpenTelemetry набуває все більшого поширення, не всі знають, що для OpenTelemetry існує спеціальний сертифікаційний іспит. Іспит OpenTelemetry Certified Associate (OTCA) від Linux Foundation — це сертифікат, призначений для підтвердження базових знань і найкращих практик у сфері спостережуваності з використанням OpenTelemetry, і його цінність поширюється як на новачків, так і на досвідчених фахівців. У цій статті описано структуру іспиту OTCA, його актуальність для осіб на різних етапах карʼєри та переваги отримання цієї сертифікації в більш широкому контексті спостережуваності.

Розвиток методів стабілізації та випуску OpenTelemetry

Sun, 09 Nov 2025 17:23:58 +0200

Короткий огляд

OpenTelemetry є, за будь-якими показниками, одним з найбільших і найцікавіших проєктів у сфері хмарних технологій. Протягом останніх п\яти років ця спільнота обʼєдналася, щоб створити один з найважливіших проєктів з моніторингу в історії. Однак ми не зупиняємося на досягнутому. Проєкт постійно шукає та прислухається до відгуків широкого кола зацікавлених сторін. З ваших відгуків ми розуміємо, що для переходу на наступний рівень нам потрібно скоригувати пріоритети та зосередитися на стабільності, надійності та організації випусків проєкту та артефактів, таких як документація та приклади.

Внесок у розробку процесора розгортання для OpenTelemetry Collector Contrib

Sun, 09 Nov 2025 17:20:26 +0200

Ідея розгортання обʼєднаних журналів всередині OpenTelemetry Collector не почалася з процесора.

Під «розгортанням» (“unrolling,) я маю на увазі взяття одного запису журналу, що містить кілька логічних подій, наприклад, масив JSON з десятьма записами журналу, і розширення його на десять окремих записів журналу, по одному для кожної події. Це дозволяє працювати з окремими записами журналу, а не з обʼєднаними даними.

Коли в Collector SIG вперше обговорювали проблему обробки журналів, що містять кілька логічних подій в одному тілі, наприклад масив JSON, першою інтуїтивною реакцією було вирішити її за допомогою функції OTTL (OpenTelemetry Transform Language) всередині процесора перетворення.

Оголошення про підтримку комплексних типів атрибутів в OTel

Sun, 09 Nov 2025 17:03:42 +0200

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

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

Але що відбувається, коли самі дані є комплексними? OpenTelemetry також прагне забезпечити спостережуваність для реальних систем, бібліотек та застосунків, спостережувані властивості яких іноді є комплексними.

OpenTelemetry eBPF Instrumentation відзначає перший випуск

Mon, 03 Nov 2025 23:30:52 +0200

Після значної співпраці між Grafana Labs, Splunk, Coralogix, Odigos та багатьма іншими членами спільноти, ми раді оголосити про випуск першої альфа-версії OpenTelemetry eBPF Instrumentation, або скорочено OBI.

Ця подія є значною віхою після того, як проєкт, спочатку відомий як Grafana Beyla, був переданий раніше цього року компанією Grafana Labs. Розробка eBPF-інструментів значно прискорилася після того, як проєкт став керуватися під егідою OpenTelemetry. Було додано багато нових протоколів, покращилася якість — особливо при розгортанні в масштабах, а тести виконуються в 10 разів швидше. Це справжнє свідчення цінності спільноти OpenTelemetry.

Оголошення результатів виборів до Керівного комітету 2025 року

Mon, 03 Nov 2025 23:29:33 +0200

Ми раді оголосити результати виборів до Керівного комітету OpenTelemetry 2025 року!

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

Цього року право голосу отримали 702 учасники, з яких 273 проголосували. Рівень участі склав 39%, що відповідає торішньому рівню, коли 299 бюлетенів було отримано від 701 учасника, що мали право голосу.

Подорож до декларативної конфігурації: чому знадобилося 5 років, щоб ігнорувати точки доступу перевірки стану в трасуванні

Mon, 20 Oct 2025 23:52:51 +0300

Однією з найпоширеніших і найпопулярніших функцій, яку користувачі Java OpenTelemetry просили додати протягом останніх кількох років, була можливість ефективно видаляти відрізки для точок доступу контролю працездатності — або будь-які інші точки доступу з низькою цінністю, що збільшують витрати. Ця проблема була вперше піднята в серпні 2020 року, проте комплексне рішення залишалося недосяжним протягом напрочуд довгого часу. Чому нам знадобилося пʼять років, щоб вирішити цю, здавалося б, просту проблему? Відповідь лежить у фундаментальних принципах системи конфігурації OpenTelemetry та у переході до більш надійного та гнучкого підходу: декларативної конфігурації.

Оновлення OpenTelemetry Sampling

Fri, 17 Oct 2025 15:51:14 +0300

Вступ

OpenTelemetry опублікував версію 1.0 своєї специфікації трасування більше чотирьох років тому, і в той же рік W3C TraceContext Level 1 був опублікований з статусом рекомендації W3C. Ми як спільнота і ми, як індустрія спостережуваності, отримали два нових стандарти для розподіленого трасування. Звичайно, ми ще не закінчили.

Ступінь дискретизації вибірки (Sampling) є важливою темою специфікації Tracing SDK, і оригінальна специфікація включала набір вбудованих вибірок, AlwaysOn, AlwaysOff, ParentBased та TraceIdRatioBased, а також інтерфейс, що дозволяє реалізовувати нові вибірки, в основному Jaeger Remote.