Distributed Tracing: OpenTelemetry

Distributed Tracing: OpenTelemetry

1) რატომ არის OTel და რას აძლევს მას

• მოთხოვნის გზების ხილვადობა (gateway სერვისები - BD/ქეში/რიგები).
• სწრაფი RCA/დეგრადაციისა და გამოშვებების გამართვა (კანარეები/ცისფერი-მწვანე).
• კავშირი SLO- სთან და მანქანების გამოტოვებასთან (ოპერაციული გადაწყვეტილებები მონაცემებზე).
• ვენდორ-აგნოსტიკა: ექსპორტი ნებისმიერ ზურგჩანთაში, ერთ APM- სთან მითითების გარეშე.

დამხმარე პრინციპები: standardize, sample smart, secure by default, correlate everything.

2) საფუძვლები: კონტექსტი, სპილოები, ატრიბუტები

Trace - ხე/ზარის რაოდენობა; Span - ოპერაცია (RPC, SQL, რიგის გამოწვევა).
Span Kind: `SERVER`, `CLIENT`, `PRODUCER`, `CONSUMER`, `INTERNAL`.
W3C Trace Context: სათაურები 'traceparent', 'tracestate'; კონტექსტი გადადის offservice.
Attributes - გასაღები მნიშვნელობა (დაბალი კარდინალობა!), Events - ეტიკეტები დროში, Status - შეცდომის კოდი/აღწერა.
ბმულები არის სპანების კავშირი მკაცრი იერარქიის მიღმა (მნიშვნელოვანია ასინკის/გულშემატკივართა/გულშემატკივრებისთვის).

• HTTP: 'HTTP {METHOD}' ('GET/withdraw' როგორც ატრიბუტი)
• DB: `DB SELECT` / `DB INSERT`
• Queue: `QUEUE publish topic=X` / `QUEUE consume topic=X`

3) სემანტიკური კონვენციები (სემკონოვი)

• HTTP/GRPC: `http. method`, `http. route`, `http. status_code`, `url. full`.
• DB: `db. system=postgresql`, `db. statement '(მხოლოდ უსაფრთხო დაჭერა!),' db. name`.
• Messaging: `messaging. system=kafka`, `messaging. operation=receive`, `messaging. destination`.
• Cloud/K8s/Host: `cloud. region`, `k8s. pod. name`, `container. id`.
• Resource attributes (აუცილებლად): 'service. name`, `service. version`, `deployment. environment`.

სქემის სტაბილურობა მიუთითეთ 'schemaUll' საშუალებით SDK/Collector რესურსებში.

4) Sampling: head, tail, adaptive

Head-based (SDK- ში): წინასწარ გადაწყვეტს, იაფია; კარგია მაღალი QPS- ისთვის, მაგრამ შეუძლია გამოტოვოს „საინტერესო“ ბილიკები.
Tail-based (კოლექტორში): გადაწყვეტს მარშრუტის დასრულების შემდეგ; საშუალებას გაძლევთ წესებს სტატუსის, ლატენტობის, ატრიბუტების შესახებ.
Adaptive/Dynamonic: ზრდის სეპლის წილს p95 შეცდომების/ზრდის დროს.

Prod დონის რეცეპტი: Head 1-5% გლობალურად + Tail შერჩევა „მნიშვნელოვანი“: 'status = ERROR', 'latency> p95', „ფულადი მარშრუტები“, შეცდომები PSP/KYC.

5) კორელაცია: მეტრიკა, ლოგოები, ტრეისი

Exemplars: ეტიკეტები 'trace _ id' მეტრის ჰისტოგრამებში (სწრაფი ნახტომი ტრასაზე).
Logs: დაამატეთ 'trace _ id '/' spank _ id' და გადადით ლოგოებიდან ტრასაზე.
Metrics (პროფესორი): SLO/ალერტებისთვის RED მეტრიკის ('requests, errors, duration') მარშრუტებიდან აერთიანებს.

6) განლაგების არქიტექტურა

Agent (DaemonSet) თითოეულ კვანძზე აგროვებს პროგრამებს (OTLP) და თავდამსხმელს.
Gateway (Cluster/Region) არის ცენტრალური კოლექტორი (მრავალი რეპლიკა) მარშრუტიზაციის/ერთჯერადი/გამდიდრების პლაკატებით.
OTLP: gRPC `4317`, HTTP `4318`; ჩართეთ TLS/mTLS.

უპირატესობები „agent + gateway“: იზოლაცია, ბუფერიზაცია, ადგილობრივი ზურგჩანთა, გამარტივებული ქსელი.

7) OpenTelemetry Collector - ძირითადი შაბლონი

yaml receivers:
otlp:
protocols:
grpc: { endpoint: 0. 0. 0. 0:4317 }
http: { endpoint: 0. 0. 0. 0:4318 }

processors:
memory_limiter: { check_interval: 5s, limit_percentage: 75 }
batch: { timeout: 2s, send_batch_size: 8192 }
attributes:
actions:
- key: deployment. environment action: upsert value: prod resource:
attributes:
- key: service. namespace action: upsert value: core tail_sampling:
decision_wait: 5s policies:
- name: errors type: status_code status_code: { status_codes: [ERROR] }
- name: slow_traces type: latency latency: { threshold_ms: 800 }
- name: important_routes type: string_attribute string_attribute:
key: http. route values: ["/withdraw", "/deposit"]
- name: baseline_prob type: probabilistic probabilistic: { sampling_percentage: 5 }

exporters:
otlp/apm:
endpoint: apm-backend:4317 tls: { insecure: true }
prometheus:
endpoint: 0. 0. 0. 0:9464

extensions:
health_check: {}
pprof: { endpoint: 0. 0. 0. 0:1777 }
zpages: { endpoint: 0. 0. 0. 0:55679 }

service:
extensions: [health_check, pprof, zpages]
pipelines:
traces:  { receivers: [otlp], processors: [memory_limiter,attributes,resource,batch,tail_sampling], exporters: [otlp/apm] }
metrics: { receivers: [otlp], processors: [batch], exporters: [prometheus] }
logs:   { receivers: [otlp], processors: [batch], exporters: [] }

8) Metrics და RED SLO- სთვის

yaml processors:
spanmetrics:
metrics_exporter: prometheus histogram:
explicit:
buckets: [50ms,100ms,200ms,400ms,800ms,1600ms,3200ms]
service:
pipelines:
traces: { receivers: [otlp], processors: [spanmetrics,batch,tail_sampling], exporters: [otlp/apm] }
metrics: { receivers: [otlp], processors: [batch], exporters: [prometheus] }

ახლა არის 'traces _ spanmetrics _ calls {სერვისი, მარშრუტი, კოდი}' და 'duration _ bucket' SLO/alerts- ისთვის.

9) K8s: კოლექტორის განლაგება (DaemonSet + Deployment)

yaml apiVersion: apps/v1 kind: DaemonSet metadata: { name: otel-agent, namespace: observability }
spec:
template:
spec:
containers:
- name: otelcol image: otel/opentelemetry-collector:latest args: ["--config=/conf/agent. yaml"]
ports:
- { containerPort: 4317, name: otlp-grpc }
- { containerPort: 4318, name: otlp-http }

Gateway (Deployment) - რამდენიმე შენიშვნა, ClusterIP/Ingress Service, HPA CPU/QPS.

10) უსაფრთხოება და კონფიდენციალურობა

TLS/mTLS между SDK → Agent → Gateway → Backend.
ავთენტიფიკაცია (Basic/OAuth/Headers) Gateway- ის შესასვლელში; შეზღუდეთ წყაროები.
PII რედაქტორები: ფილტრაცია/ნიღაბი ატრიბუტები ('user. email ',' card. ') კოლექტორის პროცესორში.
ლიმიტები: SDK- ში შეზღუდეთ ღონისძიების ზომა/ატრიბუტების რაოდენობა (დაცვა კარდინალობისგან).
RBAC უკანა პლანზე + პროექტების/ტენანტების ცალკეული ნეიმსპასი.

yaml processors:
attributes/redact:
actions:
- key: user. email action: delete
- key: payment. card action: delete

11) ბრიფინგი: სწრაფი დაწყება

Node. js

js import { NodeSDK } from "@opentelemetry/sdk-node";
import { getNodeAutoInstrumentations } from "@opentelemetry/auto-instrumentations-node";
import { OTLPTraceExporter } from "@opentelemetry/exporter-trace-otlp-grpc";
import { Resource } from "@opentelemetry/resources";
import { SemanticResourceAttributes as R } from "@opentelemetry/semantic-conventions";

const sdk = new NodeSDK({
traceExporter: new OTLPTraceExporter({ url: "http://otel-agent. observability:4317" }),
resource: new Resource({
[R.SERVICE_NAME]: "payments-api",
[R.SERVICE_VERSION]: "1. 14. 2",
[R.DEPLOYMENT_ENVIRONMENT]: "prod"
}),
instrumentations: [getNodeAutoInstrumentations()],
});
sdk. start();

Java (Spring)

java
// Gradle: io. opentelemetry. instrumentation:opentelemetry-spring-boot-starter
// application. yml otel:
service:
name: orders-api exporter:
otlp:
endpoint: http://otel-agent. observability:4317 traces:
sampler: parentbased_traceidratio sampler-arg: 0. 05

Python (FastAPI)

python from opentelemetry import trace from opentelemetry. sdk. resources import Resource from opentelemetry. exporter. otlp. proto. grpc. trace_exporter import OTLPSpanExporter from opentelemetry. sdk. trace import TracerProvider from opentelemetry. sdk. trace. export import BatchSpanProcessor

provider = TracerProvider(resource=Resource. create({"service. name":"fraud-scoring","deployment. environment":"prod"}))
provider. add_span_processor(BatchSpanProcessor(OTLPSpanExporter(endpoint="http://otel-agent. observability:4317", insecure=True)))
trace. set_tracer_provider(provider)

Go

go exp, _:= otlptracegrpc. New(ctx, otlptracegrpc. WithEndpoint("otel-agent. observability:4317"), otlptracegrpc. WithInsecure())
res:= resource. NewWithAttributes(semconv. SchemaURL, semconv. ServiceNameKey. String("gateway"), semconv. DeploymentEnvironmentKey. String("prod"))
tp:= sdktrace. NewTracerProvider(sdktrace. WithBatcher(exp), sdktrace. WithResource(res), sdktrace. WithSampler(sdktrace. ParentBased(sdktrace. TraceIDRatioBased(0. 05))))
otel. SetTracerProvider(tp)

12) ასინქრონშჩინა: რიგები, საბურავები, cron

PRODODUDER/CONSUMER კომუნიკაციით 'ლინკებით' (შეტყობინებებს აქვთ საკუთარი სასიცოცხლო ციკლი).
კონტექსტის დაკარგვა შეტყობინებების სათაურებში ('traceparent '/' baggage').
Batch-consume- ით, შექმენით სპილენძი შეტყობინებისთვის ან agright 'messaging ატრიბუტით. batch. size`.
Cron/Jobs- ისთვის: ახალი Trace გაშვებისთვის + ბმულები პირველადი მოვლენებისთვის (თუ არსებობს).

13) Baggage და მიზნობრივი

შეინახეთ მინიმალური სტაბილური გასაღებები ('tenant _ id', 'region', 'vip _ tier') baggage; აკრძალეთ PII.
გაიარეთ gateway/gateway-logger სეგმენტების მეტრიკის შემდგომი აგრეგაციისთვის.

14) ინტეგრაცია გამოშვებებთან და SLO კარიბჭესთან

კანარის ნაბიჯები - შეამოწმეთ 'traces _ spanmetrics _' მარშრუტებზე/UZ სეგმენტებზე.
დეგრადაციის დროს (5xx/p95) - ავტო გაჩერება და დაბრუნება (Argo Rollouts AnalysisTemplate + PromQL).
მეტრიკის ასლები პირდაპირ იწვევს გამოშვების ინტერვალის „ცუდ“ მარშრუტებს.

15) ლიმიტები და პროდუქტიულობა

Ограничивайте: `OTEL_SPAN_ATTRIBUTE_COUNT_LIMIT`, `OTEL_SPAN_EVENT_COUNT_LIMIT`, `OTEL_ATTRIBUTE_VALUE_LENGTH_LIMIT`.
გამონაკლისების/გაფიცვის ალბათობა/სიხშირე.
Batch პროცესორი SDK და Collector; შეინარჩუნეთ ხაზები ისე, რომ არ დაკარგოთ ბილიკები.

16) თავსებადობა და მიგრაცია

პროპაგანდა: გამოიყენეთ W3C; მხარი დაუჭირეთ B3/X-Ray- ს კითხვას მიგრაციის დროს.
ექსპორტი: OTLP-APM (Jaeger/Tempo/Elastic/X-Ray და ა.შ.).
Semconv- ის სტაბილური ვერსიები - დააფიქსირეთ 'schemaUll' და დაგეგმეთ განახლება.

17) ანტი შაბლონები

ატრიბუტების მაღალი კარდინალობა (label 'user _ id', დინამიური გასაღებები).
Logs 'trace _ id' არ არის კორელაცია.
ექსპორტი პირდაპირ პროგრამებიდან ინტერნეტ APM- ში (gateway- ის გარეშე, TLS/mTLS- ის გარეშე).
გაყიდვაში „მხოლოდ“ 100% შეგროვება ძვირი და უაზროა.
SQL მოთხოვნის ნაგავსაყრელები მომხმარებლის მონაცემებით 'db. statement`.
მომსახურების/ვერსიის არაკოორდინირებული სახელი - მეტრიკა „იშლება“.

18) განხორციელების სიის სია (0-45 დღე)

0-10 დღე

ჩართეთ SDK/ავტომატური ინჟინერია 2-3 კრიტიკულ მომსახურებაზე.
კონფიგურაცია Agent (DaemonSet) + Gateway (Deployment), OTLP 4317/4318 TLS- ით.
სერვისის დამატება. name`, `service. version`, `deployment. environment 'ყველგან.

11-25 დღე

Tail-sampling შეცდომები/ლატენტობა/“ ფულადი“ მარშრუტები.
Metrics - Prometheus, ჩართეთ Exemplars და RED/SLO დაშბორდები.
W3C- ს გასწორება API კარიბჭის/NGINX/mesh- ის საშუალებით; ლოგების კორელაცია.

26-45 დღე

დაფარეთ რიგები/BD/ქეში; ბმულები ასინკისთვის.
PII გამოცემის პოლიტიკოსები კოლექტორში; ატრიბუტების შეზღუდვები SDK- ში.
ინტეგრირებული SLO გეიტინგის გამოშვებები და ავტო-გამოტოვება.

19) სიმწიფის მეტრიკა

შემომავალი მოთხოვნების დაფარვა ტრეკით 95% -ს შეადგენს (sampling head/tail ჩათვლით).
Exemplars- ის მეტრიკის წილი 80% -ს შეადგენს.
RCA- ს დრო „მეტრიკიდან ტრასამდე“ არის 2 წუთი (p50).
0 PII გაჟონვა ატრიბუტებში/მოვლენებში (სკანერი).
ყველა სერვისს აქვს 'მომსახურება. name/version/environment 'და შეთანხმებული სემანტიკა.

20) პროგრამები: სასარგებლო ფრაგმენტები

nginx proxy_set_header traceparent $http_traceparent;
proxy_set_header tracestate $http_tracestate;
proxy_set_header baggage   $http_baggage;

histogram_quantile(0. 95, sum(rate(traces_spanmetrics_duration_bucket{route="/withdraw"}[5m])) by (le))

პოლიტიკა: PII ატრიბუტების აკრძალვა (ფსევდო-ლინტერი)

yaml forbid_attributes:
- user. email
- payment. card
- personal.

21) დასკვნა

OpenTelemetry აქცევს დაკვირვებას სტანდარტიზებულ, კონტროლირებად წრეზე: ერთიანი სემანტიკა, უსაფრთხო პროპაგანდა, ჭკვიანი ნაკრები და ძლიერი კორელაცია მეტრიკებთან და ლოგებთან. ააშენეთ agent + gateway, დაამატეთ tail-sampling, spanmetrics და Exemplars, დააკვირდით PII და კარდინალობას - და ტრეკი გახდება არა მხოლოდ გამართვის ინსტრუმენტი, არამედ ავტომატური SRE/Release გადაწყვეტილებებისთვის, შეამცირეთ MTTTR- ის და რისკები თითოეული გამოშვებისთვის.