Ano ang OpenTelemetry at Paano Ito Mapapabuti ang Kalidad ng Iyong Backend?

Noong nakaraan, kapag pinag-uusapan natin ang tungkol sa backend, karaniwang tinutukoy namin ang isang malaking application na may isang solong, malaking database, at ang pag-log ay sapat para sa pagsubaybay. Ngayon, salamat sa mga teknolohiya tulad ng Kubernetes , naging pamantayan ang mga microservice . Ang mga application ay mas marami at ipinamamahagi, at ang tradisyonal na pag-log ay hindi na sapat para sa pag-debug at pag-diagnose ng mga problema sa aming mga application.

Ang isang mahusay na solusyon para sa pag-aayos ng pagsubaybay ay ang OpenTelemetry — isang modernong toolkit na maaaring magamit para sa pag-debug at pagtatasa ng pagganap ng mga distributed system.

Ang artikulong ito ay inilaan para sa mga propesyonal sa IT na naglalayong palawakin ang kanilang kaalaman sa backend optimization. Sa ibaba, idedetalye namin kung ano ang OpenTelemetry, ang mga pangunahing konsepto nito, at ang mga problemang tinutulungan nitong lutasin. Kung interesado ka sa kung paano mababago ng OpenTelemetry ang iyong diskarte sa pagsubaybay at pag-debug ng mga backend system, pagpapahusay sa kanilang pagiging maaasahan at kahusayan — basahin pa.

Isang Maikling Kasaysayan ng OpenTelemetry

Ang malalaking tech na kumpanya ay unang humarap sa hamon ng distributed logging at tracing noong huling bahagi ng 2000s. Noong 2010, naglathala ang Google ng isang papel, Dapper, isang Malaking-Scale Distributed Systems Tracing Infrastructure , na naglatag ng batayan para sa tool sa pagsubaybay ng Twitter, ang Zipkin, na inilabas noong 2012.

Noong 2014, lumitaw ang Kubernetes, na makabuluhang pinasimple ang pagbuo ng mga microservice at iba pang mga cloud-distributed system. Ito ay humantong sa maraming kumpanya na nakakaranas ng mga isyu sa distributed logging at pagsubaybay sa mga microservice. Upang i-standardize ang distributed tracing, nilikha ang OpenTracing standard, na pinagtibay ng CNCF, at OpenCensus project ng Google.

Noong 2019, ang mga proyekto ng OpenTracing at OpenCensus ay nag-anunsyo ng isang pagsasanib sa ilalim ng pangalang OpenTelemetry. Pinagsasama ng platform na ito ang pinakamahuhusay na kagawiang naipon sa loob ng maraming taon, na nagbibigay-daan sa tuluy-tuloy na pagsasama ng pagsubaybay, pag-log, at mga sukatan sa anumang system, anuman ang pagiging kumplikado ng mga ito.

Ngayon, ang OpenTelemetry ay hindi lamang isang proyekto; ito ay isang pamantayan sa industriya para sa pagkolekta at pagpapadala ng data ng telemetry. Ito ay binuo at sinusuportahan ng isang komunidad ng mga espesyalista at mga kumpanyang nangunguna sa merkado tulad ng Google at Microsoft. Ang proyekto ay patuloy na nagbabago, nakakakuha ng mga bagong kakayahan upang pasimplehin ang proseso ng pagsasama at paggamit.

Ano ang nasa loob?

Ang OpenTelemetry ay isang komprehensibong hanay ng mga kasanayan at tool na tumutukoy kung anong mga senyales ang maaaring mabuo ng isang application upang makipag-ugnayan sa labas ng mundo, at kung paano makokolekta at mailarawan ang mga signal na ito upang masubaybayan ang estado ng mga application at ang system sa kabuuan. Ang tatlong pangunahing uri ng mga signal ay ang pagsubaybay, pag-log , at pagkolekta ng mga sukatan .

** Tingnan natin ang bawat bahagi: \

Mga konteksto

Ipinakilala ng OpenTelemetry ang konsepto ng mga konteksto ng operasyon. Pangunahing kasama sa konteksto ang mga attribute gaya ng `trace_id` (identifier para sa kasalukuyang operasyon) at `span_id` (identifier para sa isang sub-request, na may natatanging `span_id` ang bawat muling pagsubok ng sub-request).

Bukod pa rito, maaaring maglaman ang isang konteksto ng static na impormasyon, gaya ng pangalan ng node kung saan naka-deploy ang application o ang pangalan ng kapaligiran (prod/qa). Ang mga field na ito, na kilala bilang mga mapagkukunan sa terminolohiya ng OpenTelemetry, ay naka-attach sa bawat log, sukatan, o bakas para sa mas madaling paghahanap. Ang mga konteksto ay maaari ding magsama ng dynamic na data, tulad ng identifier ng kasalukuyang endpoint ( `http_path: "GET /user/:id/info"` ), na maaaring piliing i-attach sa mga pangkat ng mga log, sukatan, o bakas.

Maaaring maipasa ang mga konteksto ng OpenTelemetry sa pagitan ng iba't ibang mga application gamit ang mga protocol ng pagpapalaganap ng konteksto. Ang mga protocol na ito ay binubuo ng mga header set na idinaragdag sa bawat HTTP o gRPC na kahilingan o ang mga header ng mga mensahe para sa mga pila. Nagbibigay-daan ito sa mga downstream na application na buuin muli ang konteksto ng operasyon mula sa mga header na ito.

Narito ang ilang halimbawa ng pagpapalaganap ng konteksto:

1. B3-Propagation Ito ay isang set ng mga header ( x-b3-* ) na orihinal na binuo para sa Zipkin tracing system. Ito ay inangkop sa OpenTracing at ginamit ng maraming mga tool at library. Ang B3-Propagation ay nagdadala trace_id / span_id at isang flag na nagsasaad kung kailangan ang sampling.

   
   

2. W3C Trace Context Binuo ng W3C working group, pinag-iisa ng pamantayang ito ang iba't ibang approach ng pagpapalaganap ng konteksto sa iisang pamantayan at ang default sa OpenTelemetry. Ang isang magandang halimbawa ng paglalapat ng mga pamantayang ito ay ang pagsubaybay sa pagpapatupad ng isang kahilingang dumadaan sa mga microservice na ipinatupad gamit ang iba't ibang teknolohiya nang hindi nakompromiso ang katumpakan ng pagsubaybay at pag-debug.

Pagsubaybay

Ang pagsubaybay ay ang proseso ng pagtatala at kasunod na pagpapakita ng timeline ng landas ng kahilingan sa pamamagitan ng maraming microservice.

Sa visualization, ang bawat bar ay tinatawag na "span" at may natatanging "span_id" . Ang root span ay tinutukoy bilang isang "trace" at mayroong "trace_id" , na nagsisilbing identifier para sa buong kahilingan.

Nagbibigay-daan sa iyo ang ganitong uri ng visualization na:

• Suriin ang oras ng pagpapatupad ng mga kahilingan sa iba't ibang system at database para matukoy ang mga bottleneck na nangangailangan ng pag-optimize.
• I-detect ang mga cyclic na dependency sa pagitan ng mga serbisyo.
• Maghanap ng mga duplicate na kahilingan. Gamit ang data ng pagsubaybay, maaari ka ring bumuo ng karagdagang analytics, gaya ng paggawa ng mapa ng microservices o pamamahagi ng oras sa iba't ibang system sa panahon ng pagpoproseso ng operasyon. Kahit na hindi ka gumagamit ng trace data upang mailarawan ang mga timeline, ang OpenTelemetry ay bumubuo pa rin trace_id at span_id para magamit sa iba pang mga signal.

Mga log

Sa kabila ng maliwanag na pagiging simple nito, ang pag-log ay nananatiling isa sa pinakamakapangyarihang tool para sa pag-diagnose ng mga problema. Pinahuhusay ng OpenTelemetry ang tradisyonal na pag-log sa pamamagitan ng pagdaragdag ng impormasyon sa konteksto. Sa partikular, kung mayroong aktibong trace, awtomatikong idaragdag ang mga katangian ng `trace_id` at `span_id` sa mga log, na nagli-link sa kanila sa timeline ng trace. Bukod dito, maaaring magsama ang mga attribute ng log ng static na impormasyon mula sa konteksto ng OpenTelemetry, gaya ng node identifier, pati na rin ang dynamic na impormasyon, tulad ng kasalukuyang HTTP endpoint identifier (`http_path: "GET /user/:id"`).

Gamit ang `trace_id`, mahahanap mo ang mga log mula sa lahat ng microservice na nauugnay sa kasalukuyang kahilingan, habang binibigyang-daan ka ng `span_id` na mag-iba sa pagitan ng mga sub-request. Halimbawa, sa kaso ng muling pagsubok, ang mga log mula sa iba't ibang pagsubok ay magkakaroon ng iba't ibang `span_id`s. Ang paggamit ng mga identifier na ito ay nagbibigay-daan sa mabilis na pagsusuri ng buong pag-uugali ng system sa real-time, pagpapabilis ng pag-diagnose ng problema at pagpapahusay ng katatagan at pagiging maaasahan.

Mga sukatan

Ang koleksyon ng mga sukatan ay nagbibigay ng dami ng data sa pagganap ng system, tulad ng latency, mga rate ng error, paggamit ng mapagkukunan, at higit pa. Ang real-time na pagsubaybay sa mga sukatan ay nagbibigay-daan sa iyo na agad na tumugon sa mga pagbabago sa pagganap, maiwasan ang mga pagkabigo at pagkaubos ng mapagkukunan, at tiyakin ang mataas na kakayahang magamit at pagiging maaasahan ng application para sa mga user.

Ang pagsasama sa panukat na storage at visualization system tulad ng Prometheus at Grafana ay ginagawang mas madaling makita ang data na ito, na makabuluhang pinapasimple ang pagsubaybay.

Mga Kolektor ng Sukatan

Ang mga kolektor ng sukatan ng OpenTelemetry ay katugma sa mga pamantayan ng Prometheus at OpenMetrics, na nagbibigay-daan sa isang madaling paglipat sa mga solusyon sa OpenTelemetry nang walang makabuluhang pagbabago. Ang OpenTelemetry SDK ay nagbibigay-daan sa mga halimbawa ng trace_id na ma-export kasama ng mga sukatan, na ginagawang posible na iugnay ang mga sukatan sa mga halimbawa ng log at mga bakas.

Kaugnayan ng Signal

Magkasama, ang mga log, sukatan, at pagsubaybay ay lumikha ng isang komprehensibong pagtingin sa estado ng system:

• Nagbibigay ang mga log ng impormasyon tungkol sa mga kaganapan sa system, na nagbibigay-daan para sa mabilis na pagkilala at paglutas ng mga error.
• Ang mga sukatan ay nagpapakita ng husay at dami ng mga tagapagpahiwatig ng pagganap ng system, gaya ng mga oras ng pagtugon o mga rate ng error.
• Ang pagsubaybay ay umaakma sa view na ito sa pamamagitan ng pagpapakita ng landas ng pagpapatupad ng kahilingan sa pamamagitan ng iba't ibang bahagi ng system, na tumutulong na maunawaan ang kanilang mga ugnayan. Ang malinaw na ugnayan sa pagitan ng mga log, bakas, at sukatan ay isang natatanging tampok ng OpenTelemetry. Halimbawa, binibigyang-daan ng Grafana ang mga user na makita ang kaukulang trace at mga sukatan ng kahilingan kapag tinitingnan ang isang log, na lubos na nagpapahusay sa kakayahang magamit at kahusayan ng platform.

Bilang karagdagan sa tatlong pangunahing bahagi, kasama sa OpenTelemetry ang mga konsepto ng Sampling, Baggage, at pamamahala sa konteksto ng operasyon.

Sampling

Sa mga high-load system, ang dami ng mga log at bakas ay nagiging napakalaki, na nangangailangan ng malaking mapagkukunan para sa imprastraktura at imbakan ng data. Upang matugunan ang isyung ito, kasama sa mga pamantayan ng OpenTelemetry ang signal sampling — ang kakayahang mag-export lamang ng isang bahagi ng mga bakas at log. Halimbawa, maaari kang mag-export ng mga detalyadong signal mula sa isang porsyento ng mga kahilingan, matagal nang kahilingan, o mga kahilingan sa error. Ang diskarte na ito ay nagbibigay-daan para sa sapat na sampling upang bumuo ng mga istatistika habang nagse-save ng mga makabuluhang mapagkukunan.

Gayunpaman, kung ang bawat system ay nakapag-iisa na magpasya kung aling mga kahilingan ang susubaybayan nang detalyado, magtatapos kami sa isang pira-pirasong view ng bawat kahilingan. Ang ilang mga system ay maaaring mag-export ng detalyadong data habang ang iba ay maaari lamang bahagyang mag-export o hindi mag-export.

Upang malutas ang problemang ito, ang mga mekanismo ng pagpapalaganap ng konteksto ng OpenTelemetry ay nagpapadala ng sampling na flag kasama ang `trace_id`/`span_id`. Tinitiyak nito na kung ang paunang serbisyo na tumatanggap ng kahilingan ng user ay nagpasya na ang kahilingan ay dapat na subaybayan nang detalyado, ang lahat ng iba pang mga system ay susunod. Kung hindi, ang lahat ng mga system ay dapat na bahagyang o hindi mag-export ng mga signal upang makatipid ng mga mapagkukunan. Ang diskarte na ito ay tinatawag na "Head Sampling" — isang desisyon na ginawa sa simula ng pagpoproseso ng kahilingan, alinman sa random o batay sa ilang input attribute.

Bukod pa rito, sinusuportahan ng OpenTelemetry ang "Tail Sampling," kung saan ang lahat ng application ay palaging nag-e-export ng lahat ng mga signal nang detalyado, ngunit mayroong isang intermediate na buffer. Pagkatapos kolektahin ang lahat ng data, ang buffer na ito ay magpapasya kung pananatilihin ang buong data o panatilihin lamang ang isang bahagyang sample. Ang pamamaraang ito ay nagbibigay-daan para sa isang mas kinatawan na sample ng bawat kategorya ng kahilingan (matagumpay/mahaba/error) ngunit nangangailangan ng karagdagang pag-setup ng imprastraktura.

Bagahe

Ang mekanismo ng Baggage ay nagbibigay-daan sa arbitrary na key-value pairs na maipadala kasama ng trace_id / span_id , na awtomatikong pumasa sa pagitan ng lahat ng microservice sa panahon ng pagpoproseso ng kahilingan. Ito ay kapaki-pakinabang para sa pagpapadala ng karagdagang impormasyong kailangan sa buong landas ng kahilingan—gaya ng impormasyon ng user o mga setting ng kapaligiran ng runtime.

Halimbawa ng header para sa pagpapadala ng mga bagahe ayon sa pamantayan ng W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Narito ang ilang halimbawa ng paggamit ng Baggage:

• Ang Pagpasa ng Impormasyon sa Konteksto ng Negosyo gaya ng userId , productId , o deviceId ay maaaring maipasa sa lahat ng microservice. Maaaring awtomatikong i-log ng mga application ang impormasyong ito, na nagbibigay-daan para sa mga paghahanap ng log ayon sa konteksto ng user para sa orihinal na kahilingan.

• Mga Setting ng Mga Tukoy na Configuration Parameter para sa mga SDK o imprastraktura.

• Mga Flag ng Pagruruta Mga Flag na tumutulong sa mga tagabalanse ng pag-load na gumawa ng mga desisyon sa pagruruta. Sa panahon ng pagsubok, maaaring kailanganing iruta ang ilang kahilingan sa mga kunwaring backend. Dahil ang bagahe ay awtomatikong ipinapadala sa lahat ng mga serbisyo, hindi na kailangang gumawa ng mga karagdagang protocol—mag-set up lang ng panuntunan sa load balancer.

  
  

Pagpapatupad ng Imprastraktura

Ang pagpapatupad ng OpenTelemetry sa antas ng imprastraktura ay nagsasangkot ng pagsasama ng mga backend ng OpenTelemetry sa arkitektura ng application at pag-configure ng imprastraktura para sa pagsasama-sama ng data.

Ang proseso ay binubuo ng apat na yugto:

1. Pagsasama ng Application Sa unang yugto, ang mga OpenTelemetry SDK ay direktang isinama sa mga application upang mangolekta ng mga sukatan, log, at bakas, na tinitiyak ang tuluy-tuloy na daloy ng data tungkol sa pagganap ng bawat bahagi ng system.

   
   

2. Pag-configure ng Mga Exporter Ang nakolektang data ay niruruta mula sa mga application sa pamamagitan ng mga exporter patungo sa mga external na system para sa karagdagang pagproseso, gaya ng pag-log, pagsubaybay, pagsubaybay, o mga analytics system, depende sa iyong mga pangangailangan.

   
   

3. Pagsasama-sama at Pag-iimbak Ang yugtong ito ay maaaring may kasamang pag-normalize ng data, pagpapayaman nito ng karagdagang impormasyon, at pagsasama-sama ng data mula sa iba't ibang mapagkukunan upang lumikha ng pinag-isang view ng estado ng system.

   
   

4. Visualization ng Data Sa wakas, ipinapakita ang naprosesong data bilang mga dashboard sa mga system tulad ng Grafana (para sa mga sukatan at bakas) o Kibana (para sa mga log). Nagbibigay-daan ito sa mga team na mabilis na masuri ang kalusugan ng system, tukuyin ang mga isyu at trend, at mag-set up ng mga alerto batay sa mga nabuong signal.

Pagpapatupad ng Aplikasyon

Upang isama sa isang application, kailangan mong ikonekta ang naaangkop na OpenTelemetry SDK para sa programming language na ginagamit o gumamit ng mga library at framework na direktang sumusuporta sa OpenTelemetry. Ang OpenTelemetry ay madalas na nagpapatupad ng malawakang ginagamit na mga interface mula sa mga kilalang aklatan, na nagpapahintulot sa mga drop-in na kapalit. Halimbawa, ang Micrometer library ay karaniwang ginagamit para sa pagkolekta ng mga sukatan sa Java ecosystem. Ang OpenTelemetry SDK ay nagbibigay ng mga pagpapatupad nito ng mga interface ng Micrometer, na nagpapagana ng metric na pag-export nang hindi binabago ang pangunahing application code. Bukod dito, nag-aalok ang OpenTelemetry ng mga pagpapatupad ng mas lumang OpenTracing at OpenCensus na mga interface, na nagpapadali sa isang maayos na paglipat sa OpenTelemetry.

Konklusyon

Sa mga IT system, ang OpenTelemetry ay maaaring maging susi sa hinaharap ng maaasahan at mahusay na mga backend. Pinapasimple ng tool na ito ang pag-debug at pagsubaybay at nagbubukas din ng mga pagkakataon para sa malalim na pag-unawa sa pagganap ng application at pag-optimize sa isang bagong antas. Sumali sa komunidad ng OpenTelemetry para tumulong sa paghubog ng hinaharap kung saan mas simple at mas epektibo ang pag-develop ng backend!