OpenTelemetry гэж юу вэ, энэ нь таны арын хэсгийн чанарыг хэрхэн сайжруулах вэ?

Өмнө нь бид backend-ийн талаар ярихдаа ихэвчлэн нэг том мэдээллийн сантай нэг том програмыг хэлдэг байсан бөгөөд бүртгэл нь хяналт тавихад хангалттай байсан. Одоо Kubernetes гэх мэт технологийн ачаар микро үйлчилгээнүүд стандарт болсон. Аппликейшн нь илүү олон бөгөөд тархсан бөгөөд уламжлалт бүртгэл нь манай програмын алдааг засах , оношлоход хангалтгүй болсон.

Мониторинг зохион байгуулах маш сайн шийдэл бол OpenTelemetry бөгөөд тараагдсан системийн дибаг хийх, гүйцэтгэлд дүн шинжилгээ хийхэд ашиглаж болох орчин үеийн хэрэгсэл юм.

Энэхүү нийтлэл нь мэдээллийн технологийн мэргэжилтнүүдэд зориулагдсан бөгөөд арын оновчлолын талаархи мэдлэгээ өргөжүүлэхийг эрмэлздэг. Доор бид OpenTelemetry гэж юу болох, түүний үндсэн ойлголтууд, шийдвэрлэхэд тусалдаг асуудлуудын талаар дэлгэрэнгүй ярих болно. Хэрэв та OpenTelemetry нь арын системд хяналт тавих, дибаг хийх арга барилаа хэрхэн өөрчилж, тэдгээрийн найдвартай байдал, үр ашгийг дээшлүүлэх талаар сонирхож байгаа бол цааш уншина уу.

OpenTelemetry-ийн товч түүх

Томоохон технологийн компаниуд 2000-аад оны сүүлчээр тархсан мод бэлтгэх, мөрдөх сорилттой анх тулгарч байсан. 2010 онд Google нэгэн нийтлэл хэвлүүлсэн. Даппер, том хэмжээний тархсан системийг мөрдөх дэд бүтэц , 2012 онд гаргасан Твиттерийн мөрдөх хэрэгсэл болох Zipkin-ийн суурийг тавьсан.

2014 онд Кубернетес гарч ирсэн нь микро үйлчилгээ болон бусад үүлэн түгээлтийн системийг хөгжүүлэх ажлыг ихээхэн хялбаршуулсан. Энэ нь олон компанийг бичил үйлчилгээнд тархсан бүртгэл, мөшгихтэй холбоотой асуудалтай тулгарахад хүргэсэн. Тархсан мөрийг стандартчилахын тулд CNCF болон Google-ийн OpenCensus төслийг баталсан OpenTracing стандартыг бий болгосон.

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-Үргэлжлүүлэх Энэ нь Zipkin мөрийн системд зориулж анх боловсруулсан толгойн багц ( x-b3-* ) юм. Үүнийг OpenTracing-д тохируулсан бөгөөд олон хэрэгсэл, номын сангууд ашигладаг. B3-Үргэлжлүүлэх нь trace_id / span_id болон дээж авах шаардлагатай эсэхийг харуулсан тугийг агуулна.

   
   

2. W3C Trace Context W3C-ийн ажлын хэсгийн боловсруулсан энэхүү стандарт нь контекст түгээх янз бүрийн хандлагыг нэг стандартад нэгтгэдэг бөгөөд OpenTelemetry-д анхдагч стандарт юм. Эдгээр стандартыг хэрэглэх сайн жишээ бол хяналт, дибаг хийх нарийвчлалыг алдагдуулахгүйгээр өөр өөр технологиор хэрэгжсэн микро үйлчилгээгээр дамжуулан хүсэлтийн гүйцэтгэлийг хянах явдал юм.

Мөшгих

Мөшгих гэдэг нь олон микро үйлчилгээнүүдээр дамжуулан хүсэлтийн замыг бүртгэх, дараа нь дүрслэх үйл явц юм.

Дүрслэлд мөр бүрийг "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 нь "Сүүлт дээж авах"-ыг дэмждэг бөгөөд бүх програмууд бүх дохиог үргэлж нарийвчлан экспортлодог боловч завсрын буфер байдаг. Бүх өгөгдлийг цуглуулсны дараа энэ буфер нь бүрэн өгөгдлийг хадгалах уу эсвэл зөвхөн хэсэгчилсэн дээжийг хадгалах уу гэдгийг шийддэг. Энэ арга нь хүсэлтийн ангилал (амжилттай/урт/алдаа) бүрийг илүү төлөөлөх түүврийг гаргах боломжийг олгодог боловч нэмэлт дэд бүтцийн тохиргоог шаарддаг.

Ачаа тээш

Ачаа тээшний механизм нь хүсэлтийг боловсруулах явцад бүх микро үйлчилгээний хооронд автоматаар дамждаг trace_id / span_id -ийн хамт дурын түлхүүр-утга хосыг дамжуулах боломжийг олгодог. Энэ нь хэрэглэгчийн мэдээлэл эсвэл ажиллах цагийн орчны тохиргоо гэх мэт хүсэлтийн замд шаардлагатай нэмэлт мэдээллийг дамжуулахад хэрэгтэй.

W3C стандартын дагуу ачаа тээш дамжуулах толгойн жишээ: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Ачаа тээшний хэрэглээний зарим жишээ энд байна:

• userId , productId эсвэл deviceId гэх мэт бизнесийн контекст мэдээллийг дамжуулах нь бүх микро үйлчилгээнүүдээр дамжих боломжтой. Аппликейшн нь энэ мэдээллийг автоматаар бүртгэж, анхны хүсэлтийн хэрэглэгчийн контекстээр лог хайлт хийх боломжийг олгоно.

• SDK эсвэл дэд бүтцийн тусгай тохиргооны параметрүүдийн тохиргоо.

• Routing Flags Ачаалал тэнцвэржүүлэгчид чиглүүлэлтийн шийдвэр гаргахад тусалдаг тугнууд. Туршилтын явцад зарим хүсэлтийг хуурамч арын хэсэгт чиглүүлэх шаардлагатай байж магадгүй. Ачаа тээш нь бүх үйлчилгээгээр автоматаар дамждаг тул нэмэлт протокол үүсгэх шаардлагагүй - ачаа тээшийг тэнцвэржүүлэгч дээр дүрэм тохируулахад хангалттай.

  
  

Дэд бүтцийн хэрэгжилт

OpenTelemetry-ийг дэд бүтцийн түвшинд хэрэгжүүлэх нь OpenTelemetry backends-ийг програмын архитектурт нэгтгэх, өгөгдлийг нэгтгэх дэд бүтцийг тохируулах явдал юм.

Процесс нь дөрвөн үе шатаас бүрдэнэ.

1. Хэрэглээний интеграцчлал Эхний шатанд OpenTelemetry SDK-уудыг программуудад шууд нэгтгэж хэмжигдэхүүн, бүртгэл, мөрийг цуглуулж, системийн бүрэлдэхүүн хэсэг бүрийн гүйцэтгэлийн талаарх өгөгдлийн тасралтгүй урсгалыг хангадаг.

   
   

2. Экспортлогчдыг тохируулах Цуглуулсан өгөгдлийг таны хэрэгцээ шаардлагаас хамааран бүртгэл хөтлөх, хянах, хянах, аналитик систем гэх мэт цаашдын боловсруулалтанд зориулж экспортлогчоор дамжуулан программаас гадаад систем рүү чиглүүлдэг.

   
   

3. Нэгтгэх ба хадгалах Энэ үе шатанд өгөгдлийг хэвийн болгох, нэмэлт мэдээллээр баяжуулах, янз бүрийн эх сурвалжаас авсан өгөгдлийг нэгтгэн системийн төлөв байдлын нэгдсэн дүр төрхийг бий болгох зэрэг орно.

   
   

4. Өгөгдлийн дүрслэл Эцэст нь боловсруулсан өгөгдлийг Графана (хэмжүүр болон ул мөрийн хувьд) эсвэл Кибана (логийн хувьд) зэрэг системд хяналтын самбар хэлбэрээр үзүүлэв. Энэ нь багууд системийн эрүүл мэндийг хурдан үнэлэх, асуудал, чиг хандлагыг тодорхойлох, үүсгэсэн дохион дээр үндэслэн сэрэмжлүүлэг тохируулах боломжийг олгодог.

Хэрэглээний хэрэгжилт

Аппликейшнтэй нэгтгэхийн тулд та ашиглаж буй програмчлалын хэлэнд тохирох OpenTelemetry SDK-г холбох эсвэл OpenTelemetry-г шууд дэмждэг номын сан, фреймворк ашиглах хэрэгтэй. OpenTelemetry нь ихэвчлэн мэдэгдэж буй номын сангаас өргөн хэрэглэгддэг интерфейсүүдийг хэрэгжүүлдэг бөгөөд энэ нь оруулаад солих боломжийг олгодог. Жишээлбэл, микрометрийн санг Java экосистемд хэмжүүр цуглуулахад ихэвчлэн ашигладаг. OpenTelemetry SDK нь микрометрийн интерфэйсүүдийн хэрэгжилтийг хангаж, үндсэн програмын кодыг өөрчлөхгүйгээр хэмжигдэхүүнийг экспортлох боломжийг олгодог. Нэмж дурдахад OpenTelemetry нь OpenTracing болон OpenCensus-ийн хуучин интерфэйсүүдийн хэрэгжилтийг санал болгож, OpenTelemetry руу жигд шилжих боломжийг олгодог.

Дүгнэлт

Мэдээллийн технологийн системд OpenTelemetry нь найдвартай, үр ашигтай арын хэсгийн ирээдүйн түлхүүр болж чадна. Энэхүү хэрэгсэл нь дибаг хийх, хянах ажлыг хөнгөвчлөхийн зэрэгцээ програмын гүйцэтгэл, оновчлолыг шинэ түвшинд гүнзгий ойлгох боломжийг нээж өгдөг. Backend хөгжүүлэлт илүү хялбар, үр дүнтэй болох ирээдүйг бий болгоход туслахын тулд OpenTelemetry нийгэмлэгт нэгдээрэй!