რა არის განაწილებული ტრეისინგი და როგორ მუშაობს კორელაციის ID-ები?

Question

Accepted Answer

**განაწილებული ტრეისინგი** მიჰყვება ერთეულ მოთხოვნას, რომელიც მრავალი სერვისის მეშვეობით გადის, რათა დაინახოთ დასრულებული-დასრულებული ბილიკი და იპოვოთ, სად ხდება დაბალი ტემპი ან შეცდომები. **კორელაციის/ტრეისის ID** აერთიანებს ერთი მოთხოვნის ყველა span-ს.

## როგორ მუშაობს

პირველი სერვის ქმნის **ტრეისის ID**-ს; ყველა დაღმავალი ზარი ვრცელდება მას (და parent **span ID**) headers-ში.

```http
GET /checkout HTTP/1.1
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
# trace-id ───────────────────────────^   ^── span-id
```

```text
Trace abc123:
  Gateway      ├──────────────────────────────┤ 220ms
   Orders        ├────────────┤ 90ms
    Payments        ├──────┤ 60ms   ← slow span found here
    Inventory       ├──┤ 15ms
```

## რას იძლევა იგი

- **Latency breakdown** — რომელი სერვის/span არის ნელი.
- **Error localization** — რომელი hop-იმ წარუმატებელი.
- **Dependency map** — რა რეალურად ფუნქციონირებს რა.

საშუალებები: OpenTelemetry (instrumentation), Jaeger / Zipkin (storage + UI).

## Pitfalls

```text
⚠️ If one service drops the trace header, the trace breaks
⚠️ 100% sampling is expensive — sample, but keep errors
⚠️ Logs are useless across services without the correlation ID attached
```

## რატომ მნიშვნელოვანია

ტრეისინგის გარეშე, ნელი ან წარუმატებელი მოთხოვნის debug-ი ათობით სერვისზე უბრალოდ ვარაუდია; მის საშუალებით, თქვენ ზუსტად ხედავთ, რომელი hop არის დამნაშთე.

კორელაციის ID-ის ვრცელდება ყველა log line-სა და ზარში - ეს ერთი უმაღლესი leverage observability ინვესტიცია მიკროსერვისების სისტემაში.