В миналото, когато говорехме за бекенда, обикновено имахме предвид едно голямо приложение с една голяма база данни и регистрирането беше достатъчно за наблюдение. Сега, благодарение на технологии като Kubernetes , микроуслугите се превърнаха в стандарт. Приложенията са по-многобройни и разпространени, а традиционното регистриране вече не е достатъчно за отстраняване на грешки и диагностика на проблеми в нашите приложения.
Отлично решение за организиране на мониторинг е OpenTelemetry — модерен инструментариум, който може да се използва за отстраняване на грешки и анализ на производителността на разпределени системи.
Тази статия е предназначена за ИТ професионалисти, които искат да разширят знанията си в оптимизацията на бекенда. По-долу ще опишем подробно какво е OpenTelemetry, неговите ключови концепции и проблемите, които помага за разрешаването. Ако се интересувате от това как OpenTelemetry може да промени вашия подход към наблюдението и отстраняването на грешки в бекенд системите, като подобри тяхната надеждност и ефективност - прочетете нататък.
Големите технологични компании за първи път се изправиха пред предизвикателството на разпределеното регистриране и проследяване в края на 2000-те години. През 2010 г. Google публикува документ,
През 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 заявка или заглавки на съобщения за опашки. Това позволява на приложенията надолу по веригата да реконструират контекста на операцията от тези заглавки.
Ето няколко примера за разпространение на контекста:
B3-разпространение Това е набор от заглавки ( x-b3-*
), първоначално разработени за системата за проследяване Zipkin. Той беше адаптиран към OpenTracing и се използва от много инструменти и библиотеки. B3-Разпространението носи trace_id
/ span_id
и флаг, указващ дали е необходимо вземане на проби.
Контекст на проследяване на W3C Разработен от работната група на W3C, този стандарт обединява различни подходи за разпространение на контекста в един стандарт и е по подразбиране в OpenTelemetry. Добър пример за прилагане на тези стандарти е проследяването на изпълнението на заявка, преминаваща през микроуслуги, внедрени с различни технологии, без да се прави компромис с точността на наблюдение и отстраняване на грешки.
Проследяването е процес на записване и последващо визуализиране на времевата линия на пътя на заявка през множество микроуслуги.
Във визуализацията всяка лента се нарича "span" и има уникален "span_id" . Основният участък се нарича "trace" и има "trace_id" , който служи като идентификатор за цялата заявка.
Този тип визуализация ви позволява да:
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 включва концепциите за вземане на проби, багаж и управление на оперативния контекст.
В системи с голямо натоварване обемът на регистрационни файлове и следи става огромен, което изисква значителни ресурси за инфраструктура и съхранение на данни. За да се справят с този проблем, стандартите на 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, за да помогнете за оформянето на бъдеще, където разработката на бекенда е по-проста и по-ефективна!