---
title: "OpenTelemetry розширює сферу спостережуваності на CI/CD"
source: OpenTelemetry Documentation
source_url: https://github.com/open-telemetry/opentelemetry.io
licence: CC-BY-4.0
domain: engineering
subdomain: opentelemetry-docs
date_added: 2026-04-25
---

Ми роками говорили про необхідність спільної «мови» для отримання звітів та спостереження за системами CI/CD, і нарешті ми бачимо перші «слова» цієї мови, що входять до «словника» спостережуваності — [відкрита специфікація OpenTelemetry](/docs/specs/otel/). З нещодавнім випуском [Семантичних домовленостей OpenTelemetry](/docs/specs/semconv/), v1.27.0, ви можете знайти призначені для цього [атрибути для звітування про стан CI/CD](/docs/specs/semconv/registry/attributes/cicd/).

Це результат наполегливої роботи [Спеціальної групи з питань спостережуваності CI/CD в рамках OpenTelemetry](https://github.com/open-telemetry/community/blob/main/projects/completed-projects/ci-cd.md). Досягнувши цієї ключової віхи першого етапу, ми вирішили, що настав час поділитися нею зі світом.

## Інженерам потрібна прозорість конвеєрів CI/CD {#engineers-need-observability-into-their-cicd-pipelines}

[Спостережуваність CI/CD](https://medium.com/@horovits/fcc6c10c4987) має важливе значення для забезпечення ефективного та надійного запуску програмного забезпечення у промислову експлуатацію. Налагоджені конвеєри CI/CD безпосередньо впливають на бізнес-результати, скорочуючи [метрику Lead Time for Changes від DORA](https://horovits.medium.com/improving-devops-performance-with-dora-metrics-918b9604f8e2) і дозволяючи швидко ідентифікувати та розвʼязувати проблеми, повʼязані зі збоями або помилками в процесах. Інтегруючи спостережуваність у робочі процеси CI/CD, команди можуть відстежувати стан і продуктивність своїх конвеєрів у режимі реального часу, отримуючи уявлення про вузькі місця і сфери, які потребують вдосконалення.

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

## Потреба в стандартизації {#the-need-for-standardization}

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

Ситуація стає ще складнішою, коли вам потрібно відстежувати декілька інструментів, долучених у конвеєрі випуску, у єдиний спосіб. Саме тут [відкриті стандарти та специфікації стають критично важливими](https://horovits.medium.com/the-rise-of-open-standards-in-observability-highlights-from-kubecon-13694e732c97). Вони створюють спільну уніфіковану мову, яка є діагностичною для інструментів та постачальників, уможливлюючи узгоджену спостережуваність за різними інструментами та дозволяючи командам підтримувати чітке та всебічне уявлення про продуктивність їхнього конвеєру CI/CD.

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

## OpenTelemetry: природне середовище для специфікації спостережуваності CI/CD {#opentelemetry-the-natural-home-for-cicd-observability-specification}

Це усвідомлення підштовхнуло нас до пошуку правильного підходу до створення специфікації. OpenTelemetry постає як стандарт для генерації та збору телеметрії. Специфікація OpenTelemetry покликана розвʼязати цю задачу: створити загальну уніфіковану та діагностичну специфікацію для телеметрії. А підтримка з боку Cloud Native Computing Foundation (CNCF) гарантує, що вона залишається відкритою і нейтральною до постачальників. Бувши давніми прихильниками OpenTelemetry, ми вирішили розширити OpenTelemetry, щоб охопити цей важливий випадок використання DevOps.

Ми почали з [OpenTelemetry extension proposal (OTEP #223)](https://github.com/open-telemetry/oteps/pull/223) кілька років тому, запропонувавши нашу ідею розширити OpenTelemetry, щоб охопити область використання CI/CD. Паралельно ми створили канал у CNCF Slack, щоб зібрати колег-ентузіастів, які підтримують цю ідею, і почати мозковий штурм щодо того, як це має виглядати. Канал Slack розростався, і ми швидко виявили, що проблема є спільною для багатьох організацій.

Отримавши зворотний звʼязок від Комітету з технічного нагляду та інших членів CNCF, ми звернулися до них з проханням створити спеціальну робочу групу для цієї теми в рамках OpenTelemetry's Semantic Conventions SIG (SIG SemConv, скорочено — SIG SemConv). З їхнього благословення ми [створили офіційну Робочу групу зі спостережуваності CI/CD](https://github.com/open-telemetry/community/blob/main/projects/completed-projects/ci-cd.md), щоб формалізувати наші попередні обговорення та цілі в групі Slack.

## Спеціальна робоча група OpenTelemetry зі спостережуваності в CI/CD {#opentelemetrys-cicd-observability-sig}

Починаючи з листопада 2023 року, SIG активно працює над розробкою стандарту семантики щодо спостережуваності CI/CD у співпраці з експертами з різних компаній та проєктів з відкритим вихідним кодом. На початку роботи ми вирішили зосередитися на кількох ключових напрямках на 2024 рік:

- Початковий набір спільних атрибутів для систем CI/CD.
- Розробка прототипу(ів), що включатимуть як цілісні, так і специфічні для сигналів атрибути.
- Просування пропозиції щодо додавання змінних середовища як розповсюджувачів контексту до специфікації OpenTelemetry (OTEP #258).
- Стратегія зближення домовленостей OpenTelemetry з [CDEvents](https://cdevents.dev/docs/) та [Eiffel](https://eiffel-community.github.io/).

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

Після завершення та випуску першого етапу (див. нижче) нашій SIG було надано власне [спеціальне місце для зустрічей](https://github.com/open-telemetry/community/pull/2293) у [календарі OpenTelemetry](https://github.com/open-telemetry/community#calendar), щочетверга о 06:00 за тихоокеанським часом. Група збирається тут, щоб обговорити поточну і майбутню роботу перед тим, як перейти до більш масштабних зустрічей Семантичних домовленостей у понеділок. Ми дуже сподіваємося на подальшу підтримку та участь спільноти, оскільки ми продовжуємо рухатися вперед у цій важливій галузі стандартизації.

## CI/CD є частиною останніх семантичних домовленостей OpenTelemetry {#cicd-is-part-of-the-latest-opentelemetry-semantic-conventions}

Протягом місяців ітерацій та відгуків, [перший набір семантичних конвенцій було додано](https://github.com/open-telemetry/semantic-conventions/pull/1075) у версії v1.27.0. Ця зміна призвела до появи першого набору фундаментальної семантики для CI/CD у просторах імен `CICD`, `artifacts`, `VCS`, `test` та `deployment`. Це стало важливою віхою для SIG CI/CD Observability та галузі в цілому. Це створює фундамент, на якому всі інші цілі нашої групи можуть почати формуватися і досягати реалізації.

Але що це насправді означає? Яку цінність це дає? Розгляньмо приклади з реального світу для двох просторів назв.

### Відстеження ревізій випусків у системах керування версіями {#tracking-release-revisions-from-version-control-systems-vcs}

[Атрибути системи керування версіями (Version Control Systems, VCS)](/docs/specs/semconv/registry/attributes/vcs/) охоплюють декілька спільних для VCS областей, таких як референси та зміни (запити pull/merge). Атрибут `vcs.repository.ref.revision` є ключовим елементом метаданих. Оскільки системи контролю версій, такі як GitHub та GitLab, створюють події, вони тепер можуть мати цей семантично сумісний атрибут. Це означає, що при інтеграції коду, його випуску та розгортанні в середовищах, системи можуть включати цей атрибут і легше відстежувати зміни коду за межами системи. У разі невдалого розгортання ви можете швидко переглянути ревізію коду і знайти версію, в якій було допущено помилку. Цей атрибут також є ключовим елементом метаданих для [метрик DORA](https://dora.dev/guides/dora-metrics-four-keys/), оскільки ви розраховуєте час виконання змін та час відновлення після невдалого розгортання.

### Артефакти для безпеки ланцюга постачання, приведені у відповідність до специфікації SLSA {#artifacts-for-supply-chain-security-aligned-with-the-slsa-specification}

Простір назв атрибутів артефактів ([artifact attribute namespace](/docs/specs/semconv/registry/attributes/artifact/)) у своїй першій реалізації мав декілька атрибутів. Один з ключових наборів атрибутів у цьому просторі імен охоплює [attestations](https://slsa.dev/attestation-model), що тісно повʼязано з моделлю [SLSA](https://slsa.dev/spec/v1.0/about). Це дійсно перший випадок, коли встановлюється прямий звʼязок між спостережуваністю та безпекою ланцюга постачання програмного забезпечення. Розглянемо наступну [модель загроз ланцюга постачання](https://slsa.dev/spec/v1.0/threats), визначену SLSA: {{< figure class="figure" src="SLSA-supply-chain-model.png" attr="SLSA Community Specification License 1.0" attrlink=`https://github.com/slsa-framework/slsa?tab=License-1-ov-file` >}}

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

## Що далі для Робочої групи з питань спостережуваності CI/CD? {#whats-next-for-cicd-observability-working-group}

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

Другою важливою віхою є [OTEP #258](https://github.com/open-telemetry/oteps/pull/258) для розповсюдження контексту змінних середовища, який щойно було затверджено та інтегровано. Цей OTEP створює основу для написання специфікації.

Оскільки ми досягли прогресу у виконанні наших початкових етапів, ми оновили [CI/CD Observability SIG milestones for the rest of 2024](https://github.com/open-telemetry/community/blob/main/projects/completed-projects/ci-cd.md). Наша мета — завершити якомога більше визначених проміжних результатів до кінця року. Зокрема, ми зосереджені на:

- Додаванні [домовленостей для метрик для систем контролю версій](https://github.com/open-telemetry/semantic-conventions/pull/1383).
- Створення прототипів трасування в системах CICD (наприклад, ArgoCD, GitHub, GitLab, Jenkins).
- Підготовка [OTEP #258](https://github.com/open-telemetry/oteps/pull/258) до реалізації для доповнення специфікації.
- Додавання додаткових атрибутів до реєстру, що охоплюють більше доменів, як-от
  - [Інциденти збоїв у роботі програмного забезпечення](https://github.com/open-telemetry/semantic-conventions/issues/1185)
  - [Системні атрибути для CI/CD виконавців](https://github.com/open-telemetry/semantic-conventions/issues/1184)
- Початок роботи над специфікацією сигналів трасування та подій (журналів) для побудови мосту для інтероперабельності між іншими специфікаціями.
- Прийняття змін з [Entity and Resource OTEP](https://github.com/open-telemetry/oteps/pull/264).
- [Увімкнення специфічних для постачальника розширень](https://github.com/open-telemetry/semantic-conventions/issues/1193).
- Стратегія охоплення спільноти розробників відкритого вихідного коду для прийняття семантики.

Все, що було згадано до цього часу, це лише початок! Ми маємо багато роботи, визначеної нашою [Радою проєкту CICD](https://github.com/orgs/open-telemetry/projects/79), і ми продовжуємо працювати! Ми продовжимо працювати над вищезазначеними етапами, які ми намітили на решту 2024 року. Ось кілька речей, на які варто звернути увагу.

- Показники системи контролю версій — провідні індикатори для DORA
- Трейси з журналів GitHub Actions та Audit Logs
  - Особлива подяка наступним людям, які зробили цей компонент можливим:
    - Тайлер Гельмут - Honeycomb
    - Анджею Стенцелю - Elastic
    - Кертісу Роберту - Splunk
    - Джастіну Воссу
    - Крістоф Ковальські - Anz Bank
    - Майк Сараан - Nvidia
- Відповідна версія компонента GitHub Receiver, але реалізована в GitLab

І багато іншого!

## Щоб розширити OpenTelemetry, потрібна велика спільнота {#it-takes-a-village-to-extend-opentelemetry}

Ого, як багато треба зробити! Безумовно, ця SIG продовжить свою роботу після 2024 і до 2025 року. Стандарти важкі, але необхідні. І у нас є кілька чудових людей, які є частиною SIG і роблять свій внесок у ці стандарти! Ви можете запитати, хто це?

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

З боку Технічного комітету OpenTelemetry у нас є два основних спонсори: Карлос Альберто з Lightstep і Джош Суерет з Google. І Карлос, і Джош підтримують роботу CICD, дійсно направляючи нас через процес і деталі, необхідні для досягнення успіху.

З боку Комітету з управління OpenTelemetry нам дуже допомогли Траск Сталнекер (Trask Stalnaker) з Microsoft, а також Даніель Бланко (Daniel Blanco) зі Skyscanner, який зараз виконує обовʼязки нашого координатора. І Траск, і Деніел відіграли важливу роль у підтримці SIG та надали нам можливість провести власну зустріч у спільноті OpenTelemetry.

На додачу до цих людей, ми отримали значну підтримку та внесок від наступних ключових осіб:

- Юрій Шкуро - автор Jaeger, співзасновник OpenTelemetry
- Андреа Фріттолі (Andrea Frittoli) - Tekton CD Maintainer, співзасновник CDEvents, IBM
- Еміль Бекмарк - CDEvents та Eiffel Maintainer, Ericsson
- Магнус Бек - Eiffel, Axis Communications
- Людмила Молькова - Microsoft
- Крістофер Камфаус - Jemmic, Jenkins
- Джордано Річчі - Grafana Labs
- Джованні Ліва - Dynatrace, Keptn
- Іван Кальво - Elastic, Jenkins
- Армін Рюх - Dynatrace
- Майкл Сафʼян - Google
- Робб Кідд - Honeycomb
- Пабло Часін - Grafana Labs
- Александра Конрад - Elastic
- Александр Верт - Elastic
- Жоао Грассі - Dynatrace
- DJ Gregor - Discover

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

## Приєднуйтесь до дискусії Робочої групи та робіть свій внесок {#join-the-working-group-discourse-and-make-an-impact}

Хочете дізнатися більше? Хочете долучитися до формування спостережуваності CI/CD?

Запрошуємо розробників та практиків взяти участь в обговоренні, поділитися ідеями та допомогти сформувати майбутнє спостережуваності CI/CD та семантичних домовленостей OpenTelemetry. Обговорення відбувається в робочому просторі [CNCF Slack](https://slack.cncf.io/) на каналі `#otel-cicd`, і ви можете долучитися до обговорення будь-якої з проблем GitHub, згаданих у цій статті, а також приєднатися до щотижневих зустрічей [CICD SIG](https://github.com/open-telemetry/community/#sig-cicd) щочетверга о 06:00 PT.

_Версія цієї статті також [є в блозі CNCF][appears on the CNCF blog]._

[appears on the CNCF blog]: <{{% param canonical_url %}}>
