Какво е OpenTelemetry и как може да подобри качеството на вашия бекенд?

В миналото, когато говорехме за бекенда, обикновено имахме предвид едно голямо приложение с една голяма база данни и регистрирането беше достатъчно за наблюдение. Сега, благодарение на технологии като , се превърнаха в стандарт. Приложенията са по-многобройни и разпространени, а традиционното регистриране вече не е достатъчно за и диагностика на проблеми в нашите приложения. Kubernetes микроуслугите отстраняване на грешки Отлично решение за организиране на мониторинг е OpenTelemetry — модерен инструментариум, който може да се използва за отстраняване на грешки и анализ на производителността на разпределени системи. Тази статия е предназначена за ИТ професионалисти, които искат да разширят знанията си в оптимизацията на бекенда. По-долу ще опишем подробно какво е OpenTelemetry, неговите ключови концепции и проблемите, които помага за разрешаването. Ако се интересувате от това как OpenTelemetry може да промени вашия подход към наблюдението и отстраняването на грешки в бекенд системите, като подобри тяхната надеждност и ефективност - прочетете нататък. Кратка история на OpenTelemetry Големите технологични компании за първи път се изправиха пред предизвикателството на разпределеното регистриране и проследяване в края на 2000-те години. През 2010 г. Google публикува документ, , който постави основите на инструмента за проследяване на Twitter, Zipkin, пуснат през 2012 г. Dapper, широкомащабна инфраструктура за проследяване на разпределени системи През 2014 г. се появи Kubernetes, който значително опрости разработката на микроуслуги и други разпределени в облак системи. Това доведе до много компании, които се сблъскаха с проблеми с разпределеното регистриране и проследяване в микроуслугите. За стандартизиране на разпределеното проследяване беше създаден стандартът OpenTracing, приет от CNCF, и проектът OpenCensus на Google. През 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 заявка или заглавки на съобщения за опашки. Това позволява на приложенията надолу по веригата да реконструират контекста на операцията от тези заглавки. Ето няколко примера за разпространение на контекста: Това е набор от заглавки ( ), първоначално разработени за системата за проследяване Zipkin. Той беше адаптиран към OpenTracing и се използва от много инструменти и библиотеки. B3-Разпространението носи / и флаг, указващ дали е необходимо вземане на проби. B3-разпространение x-b3-* trace_id span_id Разработен от работната група на W3C, този стандарт обединява различни подходи за разпространение на контекста в един стандарт и е по подразбиране в OpenTelemetry. Добър пример за прилагане на тези стандарти е проследяването на изпълнението на заявка, преминаваща през микроуслуги, внедрени с различни технологии, без да се прави компромис с точността на наблюдение и отстраняване на грешки. Контекст на проследяване на W3C Проследяване Проследяването е процес на записване и последващо визуализиране на времевата линия на пътя на заявка през множество микроуслуги. Във визуализацията всяка лента се нарича "span" и има уникален . Основният участък се нарича и има , който служи като идентификатор за цялата заявка. "span_id" "trace" "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 поддържа "Tail Sampling", където всички приложения винаги експортират всички сигнали в детайли, но съществува междинен буфер. След като събере всички данни, този буфер решава дали да запази пълните данни или да запази само частична извадка. Този метод позволява по-представителна извадка от всяка категория заявка (успешна/дълга/грешка), но изисква допълнителна настройка на инфраструктурата. Багаж Механизмът за багаж позволява произволни двойки ключ-стойност да бъдат предавани заедно с / , автоматично преминавайки между всички микроуслуги по време на обработката на заявката. Това е полезно за предаване на допълнителна информация, необходима по пътя на заявката - като информация за потребителя или настройки на средата за изпълнение. trace_id span_id Пример за хедър за предаване на багаж според стандарта W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5 Ето няколко примера за използване на багаж: , като , или може да се предава през всички микроуслуги. Приложенията могат автоматично да регистрират тази информация, позволявайки търсене в регистрационни файлове по потребителски контекст за оригиналната заявка. Предаване на информация за бизнес контекст userId productId deviceId Настройки на за SDK или инфраструктура. специфични конфигурационни параметри Флагове, които помагат на балансиращите натоварването да вземат решения за маршрутизиране. По време на тестването може да се наложи някои заявки да бъдат насочени към фалшиви бекенди. Тъй като багажът се предава автоматично през всички услуги, няма нужда да създавате допълнителни протоколи – просто задайте правило за балансиращото натоварване. Флагове за маршрутизиране Имайте предвид, че въпреки че въздействието върху производителността на багажа е минимално, прекомерната употреба може значително да увеличи натоварването на мрежата и услугата. Внимателно изберете кои данни наистина трябва да преминете през Багаж, за да избегнете проблеми с производителността. Изпълнение на инфраструктурата Внедряването на OpenTelemetry на ниво инфраструктура включва интегриране на бекенда на OpenTelemetry в архитектурата на приложението и конфигуриране на инфраструктурата за агрегиране на данни. Процесът се състои от четири етапа: В първия етап OpenTelemetry SDKs са директно интегрирани в приложения за събиране на показатели, регистрационни файлове и проследявания, осигурявайки непрекъснат поток от данни за производителността на всеки системен компонент. Интегриране на приложения Събраните данни се насочват от приложения през експортери към външни системи за по-нататъшна обработка, като регистриране, наблюдение, проследяване или системи за анализ, в зависимост от вашите нужди. Конфигуриране на Exporters. Този етап може да включва нормализиране на данни, обогатяването им с допълнителна информация и обединяване на данни от различни източници, за да се създаде единен изглед на състоянието на системата. Агрегиране и съхранение И накрая, обработените данни се представят като табла за управление в системи като Grafana (за показатели и проследявания) или Kibana (за регистрационни файлове). Това позволява на екипите бързо да оценят изправността на системата, да идентифицират проблеми и тенденции и да настроят предупреждения въз основа на генерирани сигнали. Визуализация на данни Внедряване на приложението За да се интегрирате с приложение, трябва да свържете подходящия OpenTelemetry SDK за използвания език за програмиране или да използвате библиотеки и рамки, които директно поддържат OpenTelemetry. OpenTelemetry често имплементира широко използвани интерфейси от познати библиотеки, позволявайки замествания на дроп-ин. Например, библиотеката Micrometer обикновено се използва за събиране на показатели в екосистемата на Java. OpenTelemetry SDK предоставя своите реализации на Micrometer интерфейси, позволяващи експортиране на метрика, без да се променя основният код на приложението. Освен това OpenTelemetry предлага реализации на по-стари интерфейси OpenTracing и OpenCensus, улеснявайки плавната миграция към OpenTelemetry. Заключение В ИТ системите OpenTelemetry може да се превърне в ключ към бъдещето на надеждни и ефективни бекендове. Този инструмент опростява отстраняването на грешки и наблюдението и също така отваря възможности за задълбочено разбиране на производителността и оптимизацията на приложението на ново ниво. Присъединете се към общността на OpenTelemetry, за да помогнете за оформянето на бъдеще, където разработката на бекенда е по-проста и по-ефективна!