განაწილებული ტრეკები

განაწილებული ტრეკები

1) რატომ და რა არის ეს

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

• კრიტიკული ბილიკის ხილვადობა და „ვიწრო ადგილები“.
• სიმპტომების (მეტრიკის) კორელაცია მიზეზებთან (სპანებთან) და დეტალებთან (ლოგებთან).
• ჭიდაობის, რიგების, DLQ, გულშემატკივართა გადაღებების, ლატენტობის „ხერხების“ ანალიტიკა.

2) ამ ტრეკის მოდელი

Trace არის ზარის გრაფიკი 'trace _ id'.
Span — операция: `name`, `kind` (SERVER/CLIENT/PRODUCER/CONSUMER/INTERNAL), `start/end`, `status`, `attributes`, `events`, `links[]`.
Attributes - გასაღები მნიშვნელობა (მარშრუტი, db. system, messaging. system, cloud. რეგიონი და ა.შ.).
Events არის მყისიერი ეტიკეტები სპანის შიგნით (მაგალითად, 'retry', 'cache _ miss').
Span Links - კავშირი „ბავშვის მშობლის“ გარეთ (batch, retrai, fan-in/out).
Resource - პროცესის/მომსახურების მეტამონაცემები ('მომსახურება. Name ', ვერსია, გარემო).

3) კონტექსტი და ტოლერანტობა

3. 1 W3C Trace Context

• 'traceparent': 'version-traceid-spanid-flags' (დროშები მოიცავს sampling).
• 'tracestate': მოვაჭრე სპეციფიკური მდგომარეობა (მინიმუმამდე).
• Baggage - გასაღებები ბიზნეს კონტექსტისთვის (შეზღუდულია, PII/საიდუმლოებების გარეშე).

3. 2 კონტექსტის გადალახვა

HTTP: `traceparent`/`tracestate`; GRPC: მეტამონაცემები; WebSocket: განახლება და შეტყობინებებში;

შეტყობინებები: headers (Kafka/NATS/RabbitMQ) - ჩვენ ვიცავთ თავდაპირველ კონტექსტს PRODUDER- ში და გადავცემთ CONSUMER- ს.
ბაზები: არ „ატარებენ“ კონტექსტს - ჩვენ ვაწარმოებთ ატრიბუტებს სპანში (query, rows, db. სისტემა), მაგრამ არა მნიშვნელობა.

4) სემპლაცია: როგორ არ გაანადგუროთ

Head sampling (შესასვლელში): სავარაუდო/წესების შესაბამისად (მარშრუტი, ტენანტი, endpoint).
Tail sampling (კოლექტორზე): ჩვენ შევინარჩუნებთ „საინტერესო“ ტრასებს - შეცდომები, გრძელი p95/p99, იშვიათი გზები.
Exemplars: ჰისტოგრამის მეტრიკა ინახავს ბმულებს სპეციფიკურ 'trace _ id'.
რეკომენდაცია: გაერთიანება - head 5-20% + tail წესები 100% 5xx/timeout/p99.

5) ატრიბუტები და ტაქსონომია (მინიმალური სავალდებულო)

• `service. name`, `service. version`, `deployment. environment`, `cloud. region`, `http. route`, `http. method`, `http. status_code`, `db. system`, `db. statement '(შემცირებული/მონაცემების გარეშე),' messaging. system`, `messaging. operation`, `peer. service`, `net. peer. name`, `tenant. id`, `request. id`.

ბიზნეს ეტიკეტები: სისუფთავე, PII- ის გარეშე. მაგალითი: 'წესრიგი. segment`, `plan. tier`.

6) ასინქრონული სცენარები, ხაზები და ბრძოლები

PRODODUDER - CONSUMER: ჩვენ ვქმნით სპან PRODODUD შეტყობინებაში - headers (traceparent, baggage). CONSUMER იწყებს SERVER/CONSUMER სპანს ლინკით PRODUDER (თუ არ არსებობს მკაცრი იერარქია).
Fan-out: ერთი შესასვლელი - ბევრი აუტპუტი, შვილობილი ან ფირფიტა.
Batch: CONSUMER კითხულობს N შეტყობინებების პაკეტს - ერთი სპანი 'events' თითოეული formula Id ან 'links' N ცალკეულ კონტექსტებზე.
DLQ: ცალკე span 'messaging. dlq. publish` с reason и count.
Retrai: 'event: retry' + 'retry. ატრიბუტი; სასურველია ახალი CHILD სპანი მცდელობისთვის.

7) ინტეგრაცია ლოგოებთან და მეტრიკებთან

ჩვენ ვწერთ Logs JSON- ს 'trace _ id '/' spank _ id' - ით სპანისგან, ჩვენ ვტოვებთ ლოგებს.
მეტრიკა RED/USE შეიცავს სპეციფიკას - P99 მწვერვალებიდან ჩვენ მივდივართ „ცუდ“ სპანებში.
მარშრუტები წარმოქმნიან ტექნიკურ სიგნალებს (დამოკიდებულების შეცდომებს) და ბიზნეს სიგნალებს (კონვერტაციას) მოვლენების საშუალებით.

8) პროდუქტიულობა და ღირებულება

მოვლენების სემპლაცია და trottling.
ატრიბუტების კარდინალობის შემცირება (არა 'user _ id '/' session _ id', როგორც label!).
ექსპორტიორი შეკუმშვა/ბატჩინგი; ტაიმაუტის ექსპორტის საზღვრები.
შენახვა: ცხელი 1-7 დღე, შემდეგ - დანაყოფები/მხოლოდ „პრობლემური“ ტრეისი.
ხარჯვის კატეგორიები: კოლექციონერები, ინდექსები, საცავი, egress.

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

In Transit: TLS 1. 3/mTLS კოლექციონერი - აგენტები; Rest: დაშიფვრა, საკუთარი გასაღებები (იხ. „დაშიფვრა In Transit/At Rest“).
PII და საიდუმლოებები: ჩვენ არ ვწერთ ატრიბუტებს/მოვლენებს; ტოქსიკაცია/შენიღბვა მწარმოებელზე.
მრავალფეროვნება: 'tenant. id 'როგორც რესურსის ეტიკეტი და სივრცეების იზოლაცია, კითხვის პოლიტიკა; კვალდაკვალ წვდომის აუდიტი (იხ. „აუდიტი და უცვლელი ჟურნალები“).

10) განხორციელების სქემები (რეფერენდუმი)

10. 1 OpenTelemetry SDK (ფსევდო კოდი)

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

provider = TracerProvider(resource=Resource. create({
"service. name":"checkout","service. version":"1. 12. 0","deployment. environment":"prod"
}))
provider. add_span_processor(BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317", insecure=True)))
trace. set_tracer_provider(provider)
tr = trace. get_tracer("checkout")

with tr. start_as_current_span("POST /pay", attributes={
"http. route":"/pay","http. method":"POST","tenant. id":"t-42"
}):
business logic, external API call and pass DB

10. 2 OTel Collector - tail sampling (ფრაგმენტი)

yaml processors:
tailsampling:
decision_wait: 2s policies:
- type: status_code status_codes: [ERROR]
- type: latency threshold_ms: 900
- type: probabilistic sampling_percentage: 10 exporters:
otlphttp: { endpoint: http://trace-backend:4318 }
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch, tailsampling]
exporters: [otlphttp]

10. 3 კაფკა - კონტექსტის გადაცემა (კონცეფცია)

PRODODER: დაამატეთ headers 'traceparent', 'baggage'.
CONSUMER: თუ გზავნილი იწყებს ახალ ნაკადს - ახალი SERVER/CONSUMER სპანი ლინკიდან ინკების კონტექსტზე.

11) Data/ETL и ML

Batch piplines- ისთვის: span batch/partition 'dataset. urn`, `run. id`, `rows. in/out`, `freshness. lag`.
ML- სთვის: სპილენძის ვარჯიში/ინვესტიცია, მოდელის ვერსია, ლატენტობა, მომაბეზრებელი მაღაზია.
ბმული Lineage: 'run. id` и `dataset. urn 'საშუალებას გაძლევთ გადავიდეთ ტრეისიდან მონაცემთა წარმოშობის გრაფიკზე.

12) SLO ტრეკერის პლატფორმა

ინვესტიციის ხელმისაწვდომობა: 99 ევრო. 9%

შეფერხება ინდექსაციამდე: 60 ევრო p95

Head-sample დაფარვა: საკვანძო მარშრუტების 5-10% -ზე მეტი

100% ტრეისების შენარჩუნება ERROR სტატუსით და ლატენტობით> ბარიერი „კრიტიკული გზების“ კატალოგის მიხედვით

პლატფორმის ალერტები: ფრენების ზრდა, ექსპორტის ტაიმაუტები, ინდექსატორის ფეხები, გადახურებით კარდინალობა.

13) ტესტირება და გადამოწმება

ტრეკერის კონტრაქტი CI- ში: სპანების არსებობა მთავარ ენდოინტებზე, სავალდებულო ატრიბუტებზე, სწორი 'traceparent' დაფრინავს კარიბჭის/მარიონეტული საშუალებით.
სინთეტიკური/რუმის ტესტები: ისინი აგროვებენ ტრეისებს გარედან.
Chaos/ინციდენტები: დამოკიდებულების გათიშვა, შემოწმება, რომ tail-sempler „ირჩევს“ შეცდომებს.
Smoke გაყიდვაში: გამოშვების შემდეგ - „არის თუ არა სპილოები“ და exemplar ტრეისი.

14) ჩეკის ფურცლები

გაყიდვამდე

W3C Trace Context ყველგან; შეტყობინებებისთვის - headers.

• ძირითადი head სინპლაცია ჩართულია; 5xx/p99 tail წესები მორგებულია.
• სავალდებულო ატრიბუტები: მარშრუტი, მეტჰოდი, status, მომსახურება. version, tenant. id.
• Logs JSON 'trace _ id '/' span _ id ", მეტრიკა ექსპლარებიდან.
• მედდა PII; ბილიკის დაშიფვრა/დასვენება; დაშვების პოლიტიკოსები.
• დაშბორდი: „კრიტიკული გზა“, „დამოკიდებულების შეცდომები“, „რეტარი/ტაიმაუტი“.

ოპერაცია

• ყოველთვიური მიმოხილვა ატრიბუტების რადიკალურობაზე; კვოტები.
• tuning tail-sempling თითო SLO (ნაკლები ხმაური, ყველა „ცხელი“ - ნიმუშში).
• ტრენინგი RCA მეტრიკის გადასვლასთან ერთად - exemplar - trace - logs.
• რიგების საფარის შემოწმება, DLQ, ETL ჯობი.

15) Runbook’и

RCA: ზრდა p99 n/გადახდა

1. გახსნა RED დაშბორდი; bin p99- დან გადადით ექსპლარზე.
2. იპოვნეთ „ვიწრო“ CLIENT სპანი (მაგალითად, 'gateway. call '), შეამოწმეთ' retry. count ', taimauts.
3. შეადარეთ მომსახურების/დამოკიდებულების ვერსიები, რეგიონი/ზონა.
4. ჩართეთ დეგრადაცია (ქეშირების პასუხი/RPS ლიმიტი), აცნობეთ დამოკიდებულების მფლობელებს.
5. ფიქრის შემდეგ - RCA და ოპტიმიზაციის თიკეტები.

DLQ ადიდებული

1. მარშრუტების ფილტრი. dlq. publish`.
2. შეამოწმეთ მიზეზები (events), კორელაცია გამოშვებასთან.
3. Reprocess- ის დაწყება, დროებით გაზარდოს ტაიმუტი CONSUMER- დან, აცნობოს downstream- ის მფლობელებს.

16) ხშირი შეცდომები

არ არსებობს კონტექსტის გადაყრა კარიბჭეების/ბროკერების საშუალებით. გამოსავალი: middleware/ინტერსეპტორები, ერთიანი ბიბლიოთეკები.
ყველა ტრეისი 100%. ძვირი და უაზროა - გამოიყენეთ tail-sempling.
Logs 'trace _ id'. დაკარგულია კორელაცია MTTR.
PII ატრიბუტებში. ნიღაბი/ტოკნიზირება; შეინახეთ მხოლოდ ტექნიკური კონტექსტი.
„მუნჯი“ ფონის ჯობი. დაამატეთ სპილოები batch/partition და 'run. id`.
სახელების არარსებობა. შეიყვანეთ სპანებისა და ატრიბუტების სახელების ლექსიკონი.

17) FAQ

გ: Head ან tail sempling უკეთესია?
ო: კომბინაცია. Head იძლევა საბაზო ფენას, tail უზრუნველყოფს ანომალიების/შეცდომების შენარჩუნებას.

გ: როგორ გადაკვეთა კაფკას მკაცრი იერარქიის გარეშე?
O: გამოიყენეთ splanks PRODCER და CONSUMER შორის; კონტექსტი - headers.

გ: რა უნდა გავაკეთოთ მგრძნობიარე SQL?
O: 'db. statement 'შემცირებული/ნორმალიზებული (მნიშვნელობების გარეშე) ან' db. ოპერაცია '+ ზომა/დრო.

გ: როგორ დავუკავშირდეთ ბიზნეს მეტრებს?
O: დაამატეთ დომენის ატრიბუტები PII (plan/segment) გარეშე, გამოიყენეთ „ბიზნეს ეტაპის“ მოვლენები სპანის შიგნით და გადადით კონვერსიული მეტრიდან ექსპლარში.

• „დაკვირვება: ლოგოები, მეტრიკები, ტრეკები“
• „აუდიტი და უცვლელი ჟურნალები“
• „დაშიფვრა In Transit/At Rest“
• „მონაცემთა წარმოშობა (Lineage)“
• «Privacy by Design (GDPR)»
• საიდუმლო მენეჯმენტი