მოვლენების ლოგიკა და კვალდაკვალ

მოვლენების ლოგიკა და კვალდაკვალ

1) მიზანი და ჩარჩო

ლოგოები და ტრეისერები დაკვირვების საფუძველია.
ლოგიკები პასუხობენ „რა მოხდა“ და „რა კონტექსტში“.
ტრეისები პასუხობენ „სად და რატომ ნელა/შეცდომით“ მოთხოვნის განაწილებულ გზაზე.

• Structured by default (JSON); Trace-first: ცხელი ბილიკის თითოეული ჟურნალი უკავშირდება 'trace _ id '/' spank _ id'.
• მინიმალური ხმაური, მაქსიმალური სიგნალი: დონე, ნიმუში, ანტი-კარდინალობა.
• უსაფრთხოება და კონფიდენციალურობა: შენიღბვა, რედაქტირება, დაშვების დელიმიტაცია.
• ვერსირებული ლოგებისა და მოვლენების სქემები.

2) მოვლენების ტაქსონომია

1. ტექნიკური ლოგოები (runtime, შეცდომები, ქსელის ტაიმაუტები, retrai).

2. ბიზნეს მოვლენები (რეგისტრაცია, ანაბარი, განაკვეთი, დასკვნა, KYC ეტაპი) შესაფერისია სასურსათო ანალიტიკისა და „ფულადი“ მარშრუტების ინციდენტებისთვის.

3. აუდიტი (ვინ/როდის შეცვალა: ჩამორთმევა, წვდომა, დროშები, ლიმიტები) - უცვლელი ჟურნალი.

4. უსაფრთხოება (ავთენტიფიკაცია, პრივილეგიების ესკალაცია, სანქციები/RER დროშები).

5. ინფრასტრუქტურა (K8s events, autoscaling, HPA/VPA, კვანძები/დისკი/ქსელი).

თითოეული ნაკადისთვის - ჭრის, ინდექსაციისა და წვდომის ცალკეული წესები.

3) სტრუქტურული ლოგი (სტანდარტი JSON)

json
{
"ts": "2025-11-03T14:28:15.123Z",
"level": "ERROR",
"service": "payments-api",
"env": "prod",
"region": "eu-central-1",
"trace_id": "8a4f0c2e9b1f42d7",
"span_id": "c7d1f3a4b8b6e912",
"parent_span_id": "a1b2c3d4e5f60789",
"logger": "withdraw.handler",
"event": "psp_decline",
"msg": "PSP declined transaction",
"http": { "method": "POST", "route": "/withdraw", "status": 502, "latency_ms": 842 },
"user": { "tenant_id": "t_9f2", "user_key": "hash_0a7c", "vip_tier": 3 },
"payment": { "psp": "acme", "amount": 120.50, "currency": "EUR", "idempotency_key": "u123:wd:7845" },
"safe": true,         // пройдена проверка на секреты
"version": "1.14.2",     // версия сервиса (SemVer)
"build": "sha-1f2a3b4",
"kubernetes": { "pod": "payments-7cbdf", "node": "ip-10-0-2-41" }
}

მოთხოვნები: ბრტყელი სქემა + ინვესტიციები დომენებზე, სავალდებულო ველები ('ts, level, მომსახურება, env, trace _ id, msg'), რიცხვითი მნიშვნელობები - რიცხვები, არა სტრიქონები.

4) დონე, კარდინალი და მოცულობა

დონეები: 'DEBUG' (არა გაყიდვაში), 'INFO' (ბიზნეს ფაქტები), 'WARN' (ანომალიები), 'ERROR' (შეცდომები), 'FATAL' (ფერები).
კარდინალობა: თავიდან აიცილეთ თვითნებური გასაღებები/დინამიური ლაბელი. არა „id“.
Logs Sampling: განმეორებითი შეტყობინებები; ჩართეთ 'DEBUG' მხოლოდ დროულად (feature flag).
Idempotence: გააფართოვეთ 'idempotence _ key "მომხმარებლების მიერ მოვლენების დუბლიკატების ჩახშობის მიზნით.

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

შენიღბეთ PII/საიდუმლოებები აგენტებზე (Fluent Bit/Vector): ნიღბის ბარათები კლავიშებზე ('email', 'card', 'token', 'authorization').
Hash 'user _ key', შეინარჩუნეთ მხოლოდ საჭირო კონტექსტი (ქვეყანა, KYC დონე, VIP-tier).
გამოყავით საცავები: თბილი (ოპერაციული ძებნა) და ცივი (არქივი PII/ს გარეშე შემცირებული კონტექსტით).
აუდიტი - append-only, WORM საცავი, წვდომა მხოლოდ მსუბუქი პირადი პრინციპით.

6) კვალი: სტანდარტები და კონტექსტი

W3C Trace Context: სათაურები 'traceparent '/' tracestate', პლუს უსაფრთხო გასაღებები (მაგალითად, 'tenant _ id', 'region').
მეტრიკისა და ტრეისების კავშირი: Exemplars - გადაიტანეთ 'trace _ id "ჰისტოგრამების სიმულაციურ წერტილებში (აჩქარებს RCA).
Sampling: ძირითადი ნაკრები 1-5% + დინამიური „შეცდომებზე/ნელი p95“ პრობლემური მოთხოვნების 100% -მდე.
ბმულები: ასინქრონული რიგებისთვის/საგებისთვის დააკავშირეთ სპილოები 'ლინკებით' და არა მხოლოდ 'პარენტის' საშუალებით.

7) შეგროვება და მარშრუტიზაცია

აგენტები: Fluent Bit/Vector doles; OTLP ექსპორტი OpenTelemetry Collector- ში.
კოლექტორი: ცენტრალური კარიბჭე (batch/transform/filter/routing).

App → (OTLP logs/traces/metrics) → OTel Collector
→ logs: redact → route(security    audit    tech    biz) → hot index / cold archive
→ traces: tail_sampling(errors    p95>threshold) → APM backend
→ metrics: Prometheus exporter (for SLO/alerts)

yaml processors:
batch: {}
attributes:
actions:
- key: env value: prod action: insert filter/logs:
logs:
include:
match_type: strict resource_attributes:
- key: service.name value: payments-api exporters:
otlp/traces: { endpoint: "apm:4317", tls: { insecure: true } }
loki: { endpoint: "http://loki:3100/loki/api/v1/push" }
prometheus: {}
service:
pipelines:
logs: { receivers: [otlp], processors: [attributes,batch], exporters: [loki] }
traces: { receivers: [otlp], processors: [batch], exporters: [otlp/traces] }
metrics: { receivers: [otlp], processors: [batch], exporters: [prometheus] }

8) ბრიფინგი: SDK მაგალითები

8. 1 Node. js (Pino + OTel)

js import pino from "pino";
import { context, trace } from "@opentelemetry/api";

const logger = pino({ level: process.env.LOG_LEVEL          "info" });

function log(info) {
const span = trace.getSpan(context.active());
const base = span? { trace_id: span.spanContext().traceId, span_id: span.spanContext().spanId }: {};
logger.info({...base,...info });
}

// пример log({ event: "deposit.created", amount: 50, currency: "EUR", user: { user_key: "hash_0a7c" } });

8. 2 Java (SLF4J + OTel)

java
MDC.put("trace_id", Span.current().getSpanContext().getTraceId());
MDC.put("span_id", Span.current().getSpanContext().getSpanId());
log.info("psp_response status={} latency_ms={}", status, latency);

8. 3 Python (structlog + OTel)

python import structlog from opentelemetry import trace log = structlog.get_logger()

def log_json(event, kwargs):
span = trace.get_current_span()
ctx = {}
if span and span.get_span_context().is_valid:
ctx = {"trace_id": span.get_span_context().trace_id, "span_id": span.get_span_context().span_id}
log.msg(event=event, ctx, kwargs)

8. 4 NGINX - სათაურების კვალი

nginx proxy_set_header traceparent $http_traceparent;
proxy_set_header tracestate $http_tracestate;

9) Logs, როგორც სიგნალი ალერტებისა და ავტო მოქმედებებისთვის

არასწორი ნიმუშები ('psp _ decline', 'fraud _ flag') აერთიანებს და აკავშირებს SLO- ს.
ალერტები pattern-rate- ზე: "5xx/withdraw> 0. 5% 10 მ-ზე" ", fraud _ flag spike> ბაზის + 200%".
ავტო მოქმედებები: 'withdrawals _ manual _ mode = true' ჩართეთ kill-switch დროშის პლატფორმის საშუალებით.

rate(count_over_time({service="payments-api", level="ERROR", event="psp_decline"}[5m])) > 5

10) Retenschn, ინდექსაცია, შენახვა

გორიაჩე: 7-14 დღე (ოპერატიული გამოძიება).
თბილი: 30-90 დღე (ტენდენციები, RCA).
ცივი: 180-365 + (არქივი, აუდიტი) - შეკუმშვა, იაფი კლასები, შესაძლოა, სრულფასოვანი ძიების გარეშე.
ინდექსაცია: ფიქსირებული კლავიშები ('მომსახურება, env, evel, ღონისძიება, trace _ id, მომხმარებელი). tenant _ id '), „ზედიზედ“ ინდექსის აკრძალვა.
ღონისძიების ზომების ლიმიტები (მაგალითად, 32KB), ტრიმი/ქვემოდან: „MTTR მტერი ზედმეტი სცენაზე“.

11) აუდიტი და უცვლელი

აუდიტის ღონისძიებები დაწერეთ ცალკეული ნაკადით ხელმოწერებით/ჰეშებით, სერვერის დროით, 'who/what/when/why', თიკეტის მითითებით.
„ვინ მოიცავდა პრემიების დროშას 100% DE- ში?“ - პასუხი უნდა იყოს 1-2 მოთხოვნა.

json
{
"ts": "2025-11-03T14:00:00.000Z",
"actor": "alice@company",
"action": "feature_flag.update",
"target": "bonus.enable_vip",
"old": {"rollout": 10},
"new": {"rollout": 100},
"reason": "campaign_2311",
"ticket": "OPS-3481",
"trace_id": "cf12ab.."
}

12) ბიზნეს მოვლენები და მონაცემთა მოდელი

• `event_type`, `event_id`, `occurred_at`, `actor`, `subject`, `amount`, `currency`, `status`, `idempotency_key`.
• გამოიყენეთ Outbox და „ast-least-once“ imempotent მომხმარებლებთან.

13) Kubernetes და pipeline doline

Sidecar/DaemonSet აგენტები ბუფერით დისკზე (ქსელის შეფერხებებით).
მარშრუტიზაციის ქვედანაყოფების სურათები ('log. type`, `retention. tier`).
K8s კონტროლერების ლოგოები ცალკე შეაგროვეთ (კასეტური ინდექსი).

ini
[FILTER]
Name     modify
Match
Remove    authorization, password, card_number

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

სტრიქონის ლოგოები „როგორც უნდა“, „ტრეკის _ id“ არარსებობა.
PII/საიდუმლოებები ლოგებში, მთლიანად payload damps.
მილიონობით უნიკალური გასაღები არის „აფეთქებული“ ინდექსაცია.
DEBUG გაყიდვაში 24/7.
აუდიტის, უსაფრთხოების და ტექნოლოგიის შერევა ერთ ინდექსში.
არ არსებობს ეტლის პოლიტიკა და არქივიდან აღდგენის ტესტი.

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

0-10 დღე

W3C Trace Context- ის ჩართვა gateway/კლიენტებში, სათაურების გარღვევა.
პროგრამირების ლოგოების თარგმნა JSON- ზე, დაამატეთ 'trace _ id '/' spank _ id'.
აკრძალეთ PII/საიდუმლოებები (შენიღბვა აგენტზე), დაამტკიცეთ ველების სია.

11-25 დღე

განაწილება ნაკადები: tech/biz/audit/უსაფრთხოების/infra, მიუთითეთ retenchne და ACL.
ჩართეთ OTel Collector, გააკეთეთ tail-sampling შეცდომები/ნელი მოთხოვნები.
დაშბორდები „Log Rate/Error by Route“ + Jump-to-trace (Exemplars).

26-45 დღე

ალერტები მოვლენების შაბლონების მიხედვით და კორელაცია SLO- სთან.
არქივი/აღდგენა (DR ტესტი) ცივი ლოგებისთვის.
Linter ლოგიკური სქემები CI- ში, ხელშეკრულება ბიზნეს მოვლენებისთვის.

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

'Trace _ id' მოთხოვნის დაფარვა 95% -ს შეადგენს.
JSON ლოგოების წილი 99% -ს შეადგენს.
„jump-to-trace“ - ის მიერ ნაპოვნი ინციდენტები მოგვარებულია <15 წთ (p50).
0 PII შემთხვევა ლოგებში (გაჟონვის სკანერი).
Retenshn დაცულია ყველა ნაკადისთვის (ჩვენ ავტომატურად ვადასტურებთ აუდიტს).

17) პროგრამები: მინი snippets

W3C traceparent თაობა (ფსევდო)

txt traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

PromQL - ლოგოების და SLO თაიგული (მაგალითი)

high_error_logs = rate(log_events_total{service="payments-api",level="ERROR"}[5m])
5xx_rate = sum(rate(http_requests_total{service="payments-api",status=~"5.."}[5m])) / sum(rate(http_requests_total{service="payments-api"}[5m]))
alert if high_error_logs > 10 and 5xx_rate > 0.005

OpenAPI - კორელაციის სათაურები

yaml components:
parameters:
Traceparent:
name: traceparent in: header required: false schema: { type: string }

18) დასკვნა

ლანდშაფტისა და კვალიფიკაციის ძლიერი წრე არის + დისციპლინის ხელშეკრულებები: სტრუქტურული JSON-logs, ერთიანი 'trace _ id ", უსაფრთხო PII დამუშავება, ნაკადების მარშრუტიზაცია და რეტენსირება, აგრეთვე მჭიდრო კავშირი SLO- სთან, ალერტინგთან და გამოტოვებასთან. გააკეთეთ გადასვლა „ტექსტების ნაგავსაყრელიდან“ მოვლენებისა და მარშრუტების კონტრაქტებზე, ხოლო პროდუქტების დიაგნოზი გახდება სწრაფი, პროგნოზირებადი და გადამოწმებული.