Што е OpenTelemetry и како може да го подобри квалитетот на вашиот заднина?

Во минатото, кога зборувавме за backend, обично се осврнувавме на една голема апликација со единствена, голема база на податоци, а логирањето беше доволно за следење. Сега, благодарение на технологиите како , станаа стандард. Апликациите се побројни и дистрибуирани, а традиционалното евидентирање повеќе не е доволно за и дијагностицирање проблеми во нашите апликации. Kubernetes микросервисите дебагирање Одлично решение за организирање на мониторинг е OpenTelemetry — модерен пакет со алатки што може да се користи за дебагирање и анализа на перформансите на дистрибуирани системи. Оваа статија е наменета за ИТ професионалци кои сакаат да го прошират своето знаење за оптимизација на заднината. Подолу, ќе детализираме што е OpenTelemetry, неговите клучни концепти и проблемите што помага да се решат. Ако ве интересира како OpenTelemetry може да го промени вашиот пристап кон следење и дебагирање на задни системи, зголемувајќи ја нивната сигурност и ефикасност - прочитајте понатаму. Кратка историја на OpenTelemetry Големите технолошки компании за прв пат се соочија со предизвикот на дистрибуирана сеча и следење кон крајот на 2000-тите. Во 2010 година, Google објави труд, , кој ја постави основата за алатката за следење на Twitter, Zipkin, објавена во 2012 година. Дапер, инфраструктура за следење на дистрибуирани системи од големи размери Во 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 Trace Context Следење Следењето е процес на снимање и последователно визуелизирање на временската линија на патеката на барањето низ повеќе микросервиси. Во визуелизацијата, секоја лента се нарекува „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 поддржува „Tail Sampling“, каде што сите апликации секогаш детално ги извезуваат сите сигнали, но постои среден бафер. По собирањето на сите податоци, овој бафер одлучува дали да ги задржи целосните податоци или да задржи само делумен примерок. Овој метод овозможува порепрезентативен примерок од секоја категорија на барања (успешно/долго/грешка), но бара дополнително поставување на инфраструктурата. Багаж Механизмот за багаж дозволува произволни парови клуч-вредност да се пренесуваат заедно со / , автоматски поминувајќи помеѓу сите микросервиси за време на обработката на барањата. Ова е корисно за пренос на дополнителни информации потребни низ патеката на барањето - како што се кориснички информации или поставки на околината за време на траење. trace_id span_id Пример за заглавие за пренос на багаж според стандардот W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5 Еве неколку примери за користење багаж: Информациите како , или може да се пренесат низ сите микроуслуги. Апликациите можат автоматски да ги евидентираат овие информации, овозможувајќи пребарување на дневници по кориснички контекст за оригиналното барање. Предавање на деловниот контекст userId productId deviceId Поставки за SDK или инфраструктура. за специфични параметри за конфигурација Знамиња кои им помагаат на балансерите на оптоварување да донесуваат одлуки за рутирање. За време на тестирањето, некои барања можеби ќе треба да се насочат кон потсмевни позадини. Бидејќи багажот се пренесува автоматски преку сите услуги, нема потреба да се создаваат дополнителни протоколи - само поставете правило за балансерот на товарот. Знамиња за рутирање Имајте предвид дека иако влијанието на багажот на перформансите е минимално, прекумерната употреба може значително да го зголеми оптоварувањето на мрежата и услугите. Внимателно изберете кои податоци навистина треба да ги поминете низ Багаж за да избегнете проблеми со перформансите. Имплементација на инфраструктурата Спроведувањето на OpenTelemetry на ниво на инфраструктура вклучува интегрирање на OpenTelemetry backends во архитектурата на апликацијата и конфигурирање на инфраструктурата за агрегација на податоци. Процесот се состои од четири фази: Во првата фаза, OpenTelemetry SDK се директно интегрирани во апликациите за собирање метрики, дневници и траги, обезбедувајќи континуиран проток на податоци за перформансите на секоја компонента на системот. Интеграција на апликации Собраните податоци се пренасочуваат од апликациите преку извозниците до надворешни системи за понатамошна обработка, како што се евиденција, следење, следење или аналитички системи, во зависност од вашите потреби. Конфигурирање на извозници Оваа фаза може да вклучува нормализирање на податоците, нивно збогатување со дополнителни информации и спојување на податоци од различни извори за да се создаде унифициран приказ на состојбата на системот. Агрегација и складирање Конечно, обработените податоци се претставени како контролни табли во системи како Grafana (за метрика и траги) или Kibana (за дневници). Ова им овозможува на тимовите брзо да го проценат здравјето на системот, да идентификуваат проблеми и трендови и да поставуваат предупредувања врз основа на генерирани сигнали. Визуелизација на податоци Имплементација на апликацијата За да се интегрирате со апликација, треба да го поврзете соодветниот OpenTelemetry SDK за програмскиот јазик што се користи или да користите библиотеки и рамки што директно поддржуваат OpenTelemetry. OpenTelemetry често имплементира широко користени интерфејси од познати библиотеки, овозможувајќи пад-во замени. На пример, библиотеката Микрометар најчесто се користи за собирање метрика во екосистемот Јава. OpenTelemetry SDK ги обезбедува своите имплементации на Micrometer интерфејси, овозможувајќи метрички извоз без промена на главниот код на апликацијата. Покрај тоа, OpenTelemetry нуди имплементации на постари интерфејси OpenTracing и OpenCensus, олеснувајќи ја непречената миграција кон OpenTelemetry. Заклучок Во ИТ системите, OpenTelemetry може да стане клучот за иднината на доверливи и ефикасни задни системи. Оваа алатка го поедноставува дебагирањето и следењето, а исто така отвора можности за длабоко разбирање на перформансите на апликацијата и оптимизација на ново ниво. Придружете се на заедницата OpenTelemetry за да помогнете во обликувањето на иднината каде развојот на заднината е поедноставен и поефективен!