OpenTelemetry

OpenTelemetry — application va infratuzilmadan trace, metric va log telemetry ma’lumotlarini yaratish, yig‘ish, qayta ishlash va eksport qilish uchun ochiq standartlar hamda vositalar to‘plami.

OpenTelemetry observability backend’ining o‘zi emas. U telemetry hosil qilish va turli backend’larga uzatish uchun vendor-neutral qatlam beradi.

Telemetry signallari

Asosiy signallar:

trace — request va operationlar zanjiri;
metric — vaqt bo‘yicha raqamli o‘lchov;
log — vaqtli hodisa yozuvi.

Ular umumiy resource va context metadata orqali bog‘lanishi mumkin.

API va SDK

OpenTelemetry API application code instrumentatsiya qiladigan interfeyslarni beradi.

SDK esa:

sampler;
processor;
exporter;
resource;
batching;
limit

kabi amaliy xatti-harakatni bajaradi.

Library APIga tayanib span yoki metric yaratishi mumkin, application esa qaysi SDK va exporter ishlatilishini tanlaydi.

Instrumentation

Instrumentation application operationlari haqida telemetry yaratadi.

Manual instrumentation

Developer business operationni aniq belgilaydi.

Masalan:

order yaratish;
payment tekshirish;
report tayyorlash.

Manual span domain kontekstini yaxshi ifodalaydi.

Automatic instrumentation

Agent yoki library:

chaqiriqlarini avtomatik kuzatadi.

Automatic instrumentation code o‘zgartirishni kamaytiradi, ammo barcha business ma’noni bilmaydi.

Span

Trace ichidagi bitta operation span hisoblanadi.

Span:

trace ID;
span ID;
parent;
nom;
start va end;
attribute;
event;
status;
link

saqlaydi.

Span nomi yuqori cardinality qiymat emas, barqaror operation nomi bo‘lishi kerak.

Context propagation

Trace context process va service chegaralaridan o‘tishi kerak.

Propagation:

HTTP header;
message metadata;
RPC metadata;
process ichidagi context object

orqali bajariladi.

Incoming contextdan child span yaratiladi va outgoing requestga yangilangan context qo‘shiladi.

Baggage

Baggage request zanjiri bo‘ylab tarqaladigan key-value ma’lumot.

U span attribute’dan farqli: baggage keyingi service’larga ham uzatiladi.

Katta, maxfiy yoki ishonchsiz ma’lumot baggage’da saqlanmaydi.

Resource

Resource telemetry qaysi service yoki muhitdan kelganini bildiradi.

Misollar:

service name;
service version;
instance ID;
environment;
cloud region;
host;
container;
Kubernetes pod.

Bir xil naming convention backend’da metric, log va trace’ni bog‘lashga yordam beradi.

Semantic conventions

Semantic convention keng tarqalgan operationlar uchun standart attribute nomlarini belgilaydi.

Masalan:

HTTP;
database;
messaging;
RPC;
network;
service.

Bu turli library va tillardan kelgan telemetry’ni bir xil query bilan tahlil qilish imkonini beradi.

Collector

OpenTelemetry Collector telemetry pipeline uchun alohida service.

U uch asosiy bosqichga ega:

receiver → processor → exporter

Collector applicationdan signal qabul qilib, o‘zgartirib, bir yoki bir nechta backend’ga yuboradi.

Receiver

Receiver ma’lumotni ma’lum protocol yoki manbadan qabul qiladi.

Misollar:

OTLP;
Prometheus scrape;
log file;
boshqa telemetry protocol.

Har receiver endpoint, authentication va limitga ega.

Processor

Processor telemetry’ni eksportdan oldin qayta ishlaydi.

Vazifalar:

batch;
memory limit;
attribute qo‘shish yoki o‘chirish;
filtering;
sampling;
redaction;
resource detection.

Processorlar tartibi natijaga ta’sir qiladi.

Exporter

Exporter telemetry’ni backend yoki boshqa collectorga yuboradi.

Bir pipeline bir nechta exporterga ega bo‘lishi mumkin.

Masalan:

trace backend;
metric storage;
log system;
debug output.

Exporter retry va queue bilan network uzilishini boshqaradi.

OTLP

OpenTelemetry Protocol telemetry uzatish uchun standard protocol.

U binary yoki boshqa transport variantlarida ishlashi mumkin.

OTLP application SDK, collector va backend o‘rtasidagi vendor-neutral interfeysni beradi.

Collector deployment

Collector bir necha usulda ishlatiladi:

Agent modeli

Har host yoki node yonida collector.

Afzalligi — local endpoint va host telemetry.

Gateway modeli

Markaziy collector clusteri.

Afzalligi — umumiy processing, tail sampling va backend credentialni markazlashtirish.

Ko‘p tizim ikkala modelni birga ishlatadi.

Sampling

Trace hajmini kamaytirish uchun sampling ishlatiladi.

Head sampling SDKda trace boshida qaror qiladi.

Tail sampling collectorda to‘liq yoki qisman trace kelgach qaror qiladi.

Sampling error va sekin trace’larni saqlash siyosatiga mos bo‘lishi kerak.

Metric temporality

Metric exporter qiymatni:

cumulative;
delta

ko‘rinishida yuborishi mumkin.

Backend qaysi temporality’ni kutishi muhim.

Counter reset va aggregation semantikasi to‘g‘ri moslashtiriladi.

Log correlation

Log record ichida trace ID va span ID bo‘lsa log tegishli trace bilan bog‘lanadi.

Logging framework contextdan bu identifikatorlarni avtomatik qo‘shishi mumkin.

Barcha logni span eventga aylantirish shart emas.

Cardinality va limit

Metric attribute kombinatsiyasi juda ko‘p time series yaratishi mumkin.

SDK va collector:

attribute length;
event soni;
span soni;
queue;
memory

limitlariga ega.

User ID yoki request ID metric label sifatida ishlatilmaydi.

Maxfiy ma’lumot

Telemetry ichida:

token;
parol;
query parameter;
personal data;
database statement;
message body

chiqib qolishi mumkin.

Instrumentation va collector redaction policy qo‘llaydi.

Telemetry backend ham maxfiy data tizimi sifatida himoyalanadi.

Export failure

Telemetry backend ishlamasa SDK yoki collector cheklangan queue’da retry qiladi. Queue to‘lsa applicationni cheksiz bloklash o‘rniga telemetry drop qilinishi mumkin. Drop soni internal metriclarda kuzatiladi.

Collector health

Collectorning o‘zi receiver error, queue size, export failure, memory va dropped data metriclarini chiqaradi. Telemetry pipeline observability tizimining ham kuzatiladigan qismidir.

Bog‘liq tushunchalar

Observability, Telemetry, Trace, Metric, Log, Instrumentation, OpenTelemetry Collector, OTLP, Semantic conventions, Context propagation