Што такое OpenTelemetry і як ён можа палепшыць якасць бэкэнда?

У мінулым, калі мы гаварылі пра бэкэнд, мы звычайна мелі на ўвазе адно вялікае прыкладанне з адзінай вялікай базай дадзеных, і для маніторынгу было дастаткова запісу ў журнал. Цяпер, дзякуючы такім тэхналогіям, як Kubernetes , мікрасэрвісы сталі стандартам. Прыкладанняў стала больш шматлікімі і распаўсюджанымі, і традыцыйнага вядзення часопісаў ужо недастаткова для адладкі і дыягностыкі праблем у нашых праграмах.

Выдатным рашэннем для арганізацыі маніторынгу з'яўляецца OpenTelemetry — сучасны інструментарый, які можна выкарыстоўваць для адладкі і аналізу прадукцыйнасці размеркаваных сістэм.

Гэты артыкул прызначаны для ІТ-спецыялістаў, якія імкнуцца пашырыць свае веды ў аптымізацыі бэкэнда. Ніжэй мы падрабязна раскажам, што такое OpenTelemetry, яго ключавыя паняцці і праблемы, якія ён дапамагае вырашыць. Калі вы зацікаўлены ў тым, як OpenTelemetry можа змяніць ваш падыход да маніторынгу і адладцы бэкэнд-сістэм, падвысіўшы іх надзейнасць і эфектыўнасць — чытайце далей.

Кароткая гісторыя OpenTelemetry

Буйныя тэхналагічныя кампаніі ўпершыню сутыкнуліся з праблемай размеркаванай рэгістрацыі і адсочвання ў канцы 2000-х гадоў. У 2010 годзе Google апублікаваў артыкул, Dapper, буйнамаштабная інфраструктура адсочвання размеркаваных сістэм , які заклаў аснову для інструмента адсочвання Twitter, Zipkin, выпушчанага ў 2012 годзе.

У 2014 годзе з'явіўся Kubernetes, які значна спрасціў распрацоўку мікрасэрвісаў і іншых размеркаваных у воблаку сістэм. Гэта прывяло да таго, што многія кампаніі сутыкнуліся з праблемамі размеркаванага вядзення часопісаў і трасіроўкі ў мікрасэрвісах. Для стандартызацыі размеркаванай трасіроўкі быў створаны стандарт OpenTracing, прыняты CNCF, і праект Google OpenCensus.

У 2019 годзе праекты OpenTracing і OpenCensus абвясцілі аб зліцці пад назвай OpenTelemetry. Гэтая платформа аб'ядноўвае лепшыя практыкі, назапашаныя за многія гады, дазваляючы бесперапынную інтэграцыю трасіроўкі, рэгістрацыі і паказчыкаў у любую сістэму, незалежна ад яе складанасці.

Сёння OpenTelemetry - гэта не проста праект; гэта галіновы стандарт для збору і перадачы тэлеметрычных даных. Ён распрацаваны і падтрымліваецца супольнасцю спецыялістаў і вядучымі кампаніямі, такімі як Google і Microsoft. Праект працягвае развівацца, набываючы новыя магчымасці для спрашчэння працэсу інтэграцыі і выкарыстання.

Што ўнутры?

OpenTelemetry - гэта поўны набор практык і інструментаў, якія вызначаюць, якія сігналы можа генераваць прыкладанне для ўзаемадзеяння са знешнім светам, і як гэтыя сігналы можна збіраць і візуалізаваць для маніторынгу стану прыкладанняў і сістэмы ў цэлым. Тры асноўныя тыпы сігналаў: трасіроўка, рэгістрацыя і збор паказчыкаў .

**Давайце больш падрабязна разгледзім кожны кампанент: \

Кантэксты

OpenTelemetry прадстаўляе канцэпцыю аперацыйных кантэкстаў. Кантэкст у асноўным уключае такія атрыбуты, як `trace_id` (ідэнтыфікатар для бягучай аперацыі) і `span_id` (ідэнтыфікатар для падзапыту, прычым кожная паўторная спроба падзапыту мае ўнікальны `span_id` ).

Акрамя таго, кантэкст можа ўтрымліваць статычную інфармацыю, такую як імя вузла, дзе разгорнута праграма, або імя асяроддзя (prod/qa). Гэтыя палі, вядомыя як рэсурсы ў тэрміналогіі OpenTelemetry, далучаюцца да кожнага журнала, метрыкі або трасіроўкі для палягчэння пошуку. Кантэксты могуць таксама ўключаць у сябе дынамічныя даныя, такія як ідэнтыфікатар бягучай канчатковай кропкі ( `http_path: "GET /user/:id/info"` ), якія можна выбарачна далучаць да груп журналаў, паказчыкаў або слядоў.

Кантэксты OpenTelemetry могуць перадавацца паміж рознымі праграмамі з дапамогай пратаколаў распаўсюджвання кантэксту. Гэтыя пратаколы складаюцца з набораў загалоўкаў, якія дадаюцца да кожнага запыту HTTP або gRPC або загалоўкаў паведамленняў для чэргаў. Гэта дазваляе ніжэйстаячым праграмам аднаўляць кантэкст аперацыі з гэтых загалоўкаў.

Вось некалькі прыкладаў распаўсюджвання кантэксту:

1. B3-Propagation Гэта набор загалоўкаў ( x-b3-* ), першапачаткова распрацаваны для сістэмы трасіроўкі Zipkin. Ён быў адаптаваны ў OpenTracing і выкарыстоўваецца многімі інструментамі і бібліятэкамі. B3-Propagation нясе trace_id / span_id і сцяг, які паказвае, ці патрэбна выбарка.

   
   

2. Кантэкст трасіроўкі W3C Распрацаваны рабочай групай W3C, гэты стандарт аб'ядноўвае розныя падыходы да распаўсюджвання кантэксту ў адзіны стандарт і з'яўляецца стандартным у OpenTelemetry. Добрым прыкладам прымянення гэтых стандартаў з'яўляецца адсочванне выканання запыту, які праходзіць праз мікрасэрвісы, рэалізаваныя з дапамогай розных тэхналогій, без шкоды для дакладнасці маніторынгу і адладкі.

Калькаванне

Трасіроўка - гэта працэс запісу і наступнай візуалізацыі часовай шкалы шляху запыту праз некалькі мікрасэрвісаў.

У візуалізацыі кожны бар называецца "span" і мае унікальны "span_id" . Каранёвы дыяпазон называецца "трасіроўка" і мае "trace_id" , які служыць ідэнтыфікатарам для ўсяго запыту.

Гэты тып візуалізацыі дазваляе:

• Прааналізуйце час выканання запытаў у розных сістэмах і базах дадзеных, каб выявіць вузкія месцы, якія патрабуюць аптымізацыі.
• Выяўляць цыклічныя залежнасці паміж службамі.
• Знайдзіце дублікаты запытаў. Выкарыстоўваючы дадзеныя адсочвання, вы таксама можаце будаваць дадатковую аналітыку, напрыклад, ствараць карту мікрасэрвісаў або размеркаваць час паміж рознымі сістэмамі падчас апрацоўкі аперацыі. Нават калі вы не выкарыстоўваеце даныя трасіроўкі для візуалізацыі шкал часу, OpenTelemetry па-ранейшаму генеруе trace_id і span_id для выкарыстання ў іншых сігналах.

Лагі

Нягледзячы на ўяўную прастату, вядзенне часопіса застаецца адным з самых магутных інструментаў для дыягностыкі праблем. OpenTelemetry паляпшае традыцыйнае вядзенне часопісаў, дадаючы кантэкстную інфармацыю. У прыватнасці, калі прысутнічае актыўная трасіроўка, атрыбуты trace_id і span_id аўтаматычна дадаюцца ў журналы, звязваючы іх з часовай шкалой трасіроўкі. Больш за тое, атрыбуты журнала могуць уключаць у сябе статычную інфармацыю з кантэксту OpenTelemetry, напрыклад, ідэнтыфікатар вузла, а таксама дынамічную інфармацыю, напрыклад, бягучы ідэнтыфікатар канчатковай кропкі HTTP (`http_path: "GET /user/:id"`).

Выкарыстоўваючы `trace_id`, вы можаце знайсці журналы ўсіх мікрасэрвісаў, звязаных з бягучым запытам, а `span_id` дазваляе адрозніваць падзапыты. Напрыклад, у выпадку паўторных спроб журналы розных спроб будуць мець розныя `span_id`. Выкарыстанне гэтых ідэнтыфікатараў дазваляе хутка аналізаваць паводзіны ўсёй сістэмы ў рэжыме рэальнага часу, паскараючы дыягностыку праблем і павышаючы стабільнасць і надзейнасць.

Метрыка

Калекцыя паказчыкаў дае колькасныя даныя аб прадукцыйнасці сістэмы, такія як затрымка, узровень памылак, выкарыстанне рэсурсаў і многае іншае. Маніторынг метрык у рэжыме рэальнага часу дазваляе аператыўна рэагаваць на змены прадукцыйнасці, прадухіляць збоі і знясіленне рэсурсаў, забяспечваць высокую даступнасць і надзейнасць прыкладання для карыстальнікаў.

Інтэграцыя з метрычнымі сістэмамі захоўвання і візуалізацыі, такімі як Prometheus і Grafana, палягчае візуалізацыю гэтых даных, значна спрашчаючы маніторынг.

Зборшчыкі метрык

Калектары паказчыкаў OpenTelemetry сумяшчальныя са стандартамі Prometheus і OpenMetrics, што дазваляе лёгка перайсці на рашэнні OpenTelemetry без значных змен. Пакет OpenTelemetry SDK дазваляе экспартаваць прыклады trace_id разам з метрыкамі, што дазваляе суадносіць метрыкі з прыкладамі журналаў і трасіроўкай.

Карэляцыя сігналаў

Разам журналы, паказчыкі і трасіроўка ствараюць поўнае ўяўленне пра стан сістэмы:

• Журналы забяспечваюць інфармацыю аб сістэмных падзеях, што дазваляе хутка ідэнтыфікаваць і ліквідаваць памылкі.
• Метрыкі адлюстроўваюць якасныя і колькасныя паказчыкі прадукцыйнасці сістэмы, такія як час водгуку або частата памылак.
• Трасіроўка дапаўняе гэты выгляд, паказваючы шлях выканання запыту праз розныя кампаненты сістэмы, дапамагаючы зразумець іх узаемасувязі. Выразная карэляцыя паміж журналамі, трасіроўкай і паказчыкамі з'яўляецца адметнай асаблівасцю OpenTelemetry. Напрыклад, Grafana дазваляе карыстальнікам бачыць адпаведныя паказчыкі трасіроўкі і запыту пры праглядзе часопіса, што значна павышае зручнасць і эфектыўнасць платформы.

У дадатак да трох асноўных кампанентаў OpenTelemetry уключае ў сябе канцэпцыі адбору пробаў, багажу і кіравання кантэкстам аперацый.

Адбор проб

У сістэмах з высокай нагрузкай аб'ём часопісаў і слядоў становіцца велізарным, што патрабуе значных рэсурсаў для інфраструктуры і захоўвання даных. Каб вырашыць гэтую праблему, стандарты OpenTelemetry ўключаюць выбарку сігналу — магчымасць экспартаваць толькі частку слядоў і журналаў. Напрыклад, вы можаце экспартаваць падрабязныя сігналы з адсотка запытаў, працяглых запытаў або запытаў памылак. Такі падыход дазваляе атрымаць дастатковую выбарку для збору статыстыкі, эканомячы значныя рэсурсы.

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

Каб вырашыць гэтую праблему, механізмы распаўсюджвання кантэксту OpenTelemetry перадаюць флаг выбаркі разам з `trace_id`/`span_id`. Гэта гарантуе, што калі першапачатковая служба, якая атрымала запыт карыстальніка, вырашыць, што запыт трэба дэталёва кантраляваць, усе астатнія сістэмы рушаць услед гэтаму прыкладу. У адваротным выпадку ўсе сістэмы павінны часткова або не экспартаваць сігналы для эканоміі рэсурсаў. Гэты падыход называецца «Выбарка загалоўка» — рашэнне, якое прымаецца ў пачатку апрацоўкі запыту, альбо выпадковым чынам, альбо на аснове некаторых уваходных атрыбутаў.

Акрамя таго, OpenTelemetry падтрымлівае "хваставую выбарку", калі ўсе прыкладанні заўсёды экспартуюць усе сігналы ў дэталях, але існуе прамежкавы буфер. Пасля збору ўсіх даных гэты буфер вырашае, захоўваць усе даныя ці толькі частковую выбарку. Гэты метад дазваляе атрымаць больш рэпрэзентатыўную выбарку кожнай катэгорыі запытаў (паспяховы/доўгі/памылка), але патрабуе дадатковай налады інфраструктуры.

Багаж

Механізм багажу дазваляе перадаваць адвольныя пары ключ-значэнне разам з trace_id / span_id , аўтаматычна перадаючыся паміж усімі мікрасэрвісамі падчас апрацоўкі запыту. Гэта карысна для перадачы дадатковай інфармацыі, неабходнай на ўсім шляху запыту, напрыклад, інфармацыі аб карыстальніку або налад асяроддзя выканання.

Прыклад загалоўка для перадачы багажу па стандарце W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Вось некалькі прыкладаў выкарыстання багажу:

• Перадача інфармацыі аб бізнес-кантэксце, такой як userId , productId або deviceId можа перадавацца праз усе мікрасэрвісы. Праграмы могуць аўтаматычна рэгістраваць гэту інфармацыю, дазваляючы шукаць у журнале кантэкст карыстальніка для першапачатковага запыту.

• Спецыфічныя параметры канфігурацыі Налады для SDK або інфраструктуры.

• Сцягі маршрутызацыі Сцяжкі, якія дапамагаюць балансіроўшчыкам нагрузкі прымаць рашэнні аб маршрутызацыі. Падчас тэсціравання некаторыя запыты, магчыма, спатрэбіцца накіраваць на фіктыўныя бэкэнды. Паколькі багаж перадаецца аўтаматычна праз усе сэрвісы, няма неабходнасці ствараць дадатковыя пратаколы — проста ўсталюйце правіла ў балансіры нагрузкі.

  
  

Укараненне інфраструктуры

Укараненне OpenTelemetry на ўзроўні інфраструктуры прадугледжвае інтэграцыю бэкэндаў OpenTelemetry у архітэктуру прыкладання і наладжванне інфраструктуры для агрэгацыі даных.

Працэс складаецца з чатырох этапаў:

1. Інтэграцыя прыкладанняў. На першым этапе пакеты SDK OpenTelemetry непасрэдна інтэгруюцца ў прыкладанні для збору паказчыкаў, часопісаў і трасіроўкі, забяспечваючы бесперапынны паток даных аб прадукцыйнасці кожнага кампанента сістэмы.

   
   

2. Наладжванне экспарцёраў. Сабраныя даныя накіроўваюцца з прыкладанняў праз экспарцёры ў знешнія сістэмы для далейшай апрацоўкі, такія як сістэмы вядзення журналаў, маніторынгу, адсочвання або аналітыкі, у залежнасці ад вашых патрэбаў.

   
   

3. Агрэгацыя і захоўванне Гэты этап можа ўключаць у сябе нармалізацыю даных, узбагачэнне іх дадатковай інфармацыяй і аб'яднанне даных з розных крыніц для стварэння адзінага ўяўлення пра стан сістэмы.

   
   

4. Візуалізацыя даных Нарэшце, апрацаваныя даныя прадстаўлены ў выглядзе прыборных панэляў у такіх сістэмах, як Grafana (для паказчыкаў і слядоў) або Kibana (для часопісаў). Гэта дазваляе камандам хутка ацэньваць стан сістэмы, выяўляць праблемы і тэндэнцыі і наладжваць абвесткі на аснове згенераваных сігналаў.

Рэалізацыя прыкладанняў

Для інтэграцыі з дадаткам вам трэба падключыць адпаведны OpenTelemetry SDK для выкарыстоўванай мовы праграмавання або выкарыстоўваць бібліятэкі і структуры, якія непасрэдна падтрымліваюць OpenTelemetry. OpenTelemetry часта рэалізуе шырока выкарыстоўваныя інтэрфейсы з вядомых бібліятэк, дазваляючы замену. Напрыклад, бібліятэка Micrometer звычайна выкарыстоўваецца для збору паказчыкаў у экасістэме Java. Пакет OpenTelemetry SDK забяспечвае рэалізацыю інтэрфейсаў Micrometer, што дазваляе экспартаваць паказчыкі без змены асноўнага кода прыкладання. Акрамя таго, OpenTelemetry прапануе рэалізацыю старых інтэрфейсаў OpenTracing і OpenCensus, што палягчае плыўны пераход на OpenTelemetry.

Заключэнне

У ІТ-сістэмах OpenTelemetry можа стаць ключом да будучыні надзейных і эфектыўных бэкэндаў. Гэты інструмент спрашчае адладку і маніторынг, а таксама адкрывае магчымасці для глыбокага разумення прадукцыйнасці прыкладанняў і аптымізацыі на новым узроўні. Далучайцеся да супольнасці OpenTelemetry, каб дапамагчы сфарміраваць будучыню, у якой бэкэнд-распрацоўка прасцей і больш эфектыўна!