Бөлінген трассировкалар

Бөлінген трассировкалар

1) Бұл не үшін және не

Таратылған трассировка - бұл барлық сұрау жолы бойынша операцияларды байланыстыру тәсілі: фронт → API-шлюз → микросервистер → БД/кэштер → брокерлер → джобалар/пайплайндар.
Нәтижесі - әр спан атрибуттары, оқиғалары және мәртебесі бар компоненттің жұмысын тіркейтін спан (span) трасс (trace). Бұл RCA жылдамдатады, SLO ұстауға көмектеседі және MTTR төмендетеді.

• Қиын жолдың және «тар жерлердің» көрінуі.
• Симптомдардың (метриканың) себептермен (спаналармен) және бөлшектермен (логалармен) корреляциясы.
• Ретраяларды, кезектерді, DLQ, жанкүйерлерді, жасырын «араларды» талдау.

2) Трассировка деректерінің моделі

Trace - 'trace _ id' шақыру бағаны.
Span — операция: `name`, `kind` (SERVER/CLIENT/PRODUCER/CONSUMER/INTERNAL), `start/end`, `status`, `attributes`, `events`, `links[]`.
Attributes - кілт мән (route, db. system, messaging. system, cloud. region және т.б.).
Events - спан ішіндегі жылдам белгілер (мысалы, 'retry', 'cache _ miss').
Span Links - «ата-ана-бала» (батчи, ретраи, fan-in/out) тыс байланыстар.
Resource - процестің/сервистің метадеректері ('service. 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) - бастапқы контекст PRODUCER-де сақталады және CONSUMER-де тасымалданады.
Деректер қоры: контексті «жоқ» - төлсипаттарды span (query, rows, db. system), бірақ мән емес.

4) Тұқымдастыру: қалай бұзылмау керек

Head sampling (кіре берісте): ықтималдық/ережелер бойынша (route, tenant, 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-сыз. Мысал: 'order. segment`, `plan. tier`.

6) Асинхронды сценарийлер, кезектер мен батчилер

PRODUCER → CONSUMER: мәтінмен SPAN PRODUCER жасаймыз; хабарламада - headers (traceparent, baggage). CONSUMER SERVER/CONSUMER-спан PRODUCER linkінен басталады (егер қатаң иерархия болмаса).
Fan-out: бір кіріс - көптеген аутпуттар → еншілес спанктар немесе links.
Batch: CONSUMER хабарламалардың N бумасын оқиды → әрбір messageId бойынша 'events' -тен бір span немесе жеке мәтінмәндердің N 'links'.
DLQ: жеке span 'messaging. dlq. publish` с reason и count.
Ретра: 'event: retry' + 'retry. count 'төлсипаты; мүмкіндігінше әрекетке жаңа CHILD-спан.

7) Логтармен және метрикалармен интеграциялау

JSON-ды 'trace _ id '/' span _ id' → деп жазамыз.
RED/USE өлшемдерінде exemplars → p99 шыңдарынан «нашар» ұйқыға барамыз.
Трассалар оқиғалар арқылы техсигналдар (тәуелділік қателері) және бизнес-сигналдар (конверсия) шығарады.

8) Өнімділік және құн

Оқиғаларды семплеу және троттлинг.
Атрибуттардың түбегейлілігін қысқарту ('user _ id '/' session _ id' label!).
Экспорттаушының сығуы/батчасы; экспорт уақыт шектері.
Сақтау: ыстық 1-7 күн, одан әрі - агрегаттар/тек «проблемалы» трестер.
Шығын санаттары: коллекторлар, индекстер, сақтау орны, egress.

9) Қауіпсіздік және құпиялылық

In Transit: TLS 1. коллектор агенттер; At 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 Kafka - контексті көшіру (тұжырымдама)

PRODUCER: headers 'traceparent', 'baggage' қосыңыз.
CONSUMER: егер хабар жаңа ағынды бастаса - жаңа SERVER/CONSUMER-span c link- тен headers контексіне.

11) Data/ETL и ML

Батч-пайплайндар үшін: батч/partition с 'dataset. urn`, `run. id`, `rows. in/out`, `freshness. lag`.
ML үшін: жаттығулар/инференстер, модель нұсқасы, latency, feature store.
Lineage: 'run. id` и `dataset. urn 'трестен деректердің шығу бағанына өтуге мүмкіндік береді.

12) SLO трассалау платформасы

ingestion қол жетімділігі: ≥ 99. 9%

Индекстеуге дейін кідіру: ≤ 60 с p95

Head-sample қамту: негізгі бағыттардың 5-10% ≥

ERROR мәртебесі бар және latency> «сындарлы жолдар» каталогы бойынша шекті трейстерді 100% сақтау

Тұғырнаманың алерттары: дроптардың өсуі, экспорт таймауттары, индекстеуші лаг, кардинальдықтың қызып кетуі.

13) Тестілеу және верификация

CI трассалау келісімшарты: негізгі эндпоинттарда спандардың болуы, міндетті атрибуттар, дұрыс 'traceparent' шлюз/прокси арқылы ұшып өтеді.
Synthetic/rum-сынамалар: сыртқы жағынан трестерді жинайды.
Chaos/оқиғалар: тәуелділікті өшіру, tail-семплердің қателерді «таңдағанын» тексеру.
Өнімде Smoke: шығарылғаннан кейін - «ұйқылар бар ма» және exemplar → трейс.

14) Чек парақтары

Азық-түлік алдында

• Барлық жерде W3C Trace Context; хаттар үшін - headers.
• Негізгі head-семплирлеу қосылған; 5xx/p99 үшін tail ережелері теңшелген.
• Міндетті төлсипаттар: route, method, status, service. version, tenant. id.
• JSON логтары с 'trace _ id '/' span _ id', exemplars.
• PII санитайзерлері; жолда/тыныштықта шифрлау; кіру саясаты.
• Дашбордтар: «сыни жол», «тәуелділік қателері», «ретраи/таймауттар».

Пайдалану

• Атрибуттардың түбегейлі болуына ай сайынғы шолу; квоталар.
• SLO бойынша tail-семплинг тюнингі (аз шу, барлығы «ыстық» - іріктемеде).
• Оқу RCA метрика → exemplar → трейс → логи.
• Кезектер, DLQ, ETL-джобтар үшін жабындарды тексеру.

15) Runbook’и

RCA: p99/pay

1. RED-дашборд ашу; ғимараттан p99 exemplar арқылы трейске өту.
2. «Тар» CLIENT-span (мысалы, 'gateway. call '), тексеру' retry. count ', таймауттар.
3. Қызмет/тәуелділік, аймақ/аймақ нұсқаларын салыстыру.
4. Құлдырауды қосу (кэштейтін жауап/RPS лимиті), тәуелділік иелеріне хабарлау.
5. Фикстен кейін - RCA және оңтайландыру үшін тикеттер.

DLQ өрісі

1. 'messaging. dlq. publish`.
2. Себептерін тексеру (events), релизмен корреляциялау.
3. reprocess бағдарламасын іске қосу, CONSUMER-дегі таймаутты уақытша ұлғайту, downstream иелеріне хабарлау.

16) Жиі қателер

Шлюздер/брокерлер арқылы мәтін ұясы жоқ. Шешімі: middleware/интерсепторлар, бірыңғай кітапханалар.
Барлық трейдерлер 100%. Қымбат және мағынасыз - tail-семплингті пайдаланыңыз.
'trace _ id' жоқ логтар. Корреляция жоғалуда → MTTR ↑.
төлсипаттардағы PII. Жасыру/токенизациялау; тек техникалық контексті сақтаңыз.
«Үнсіз» фондық джобтар. Батч/partition және 'run. id`.
Әртүрлі атаулар. Спан аттары мен төлсипаттар кілттерінің сөздігін енгізіңіз.

17) FAQ

С: Head немесе tail семплинг жақсы ма?
О: Комбинация. Head негізгі қабатты береді, tail ауытқулардың/қателердің сақталуына кепілдік береді.

С: Қатаң иерархиясыз Kafka арқылы қалай трассалауға болады?
О: PRODUCER және CONSUMER арасында span links пайдаланыңыз; контексті - headers.

Q: сезімтал SQL-мен не істеу керек?
'db. statement 'қысқартылған/қалыпқа келтірілген (мәнсіз) немесе' db. operation '+ өлшемдері/уақыты.

С: Бизнес-өлшемдермен қалай байланыстыру керек?
О: PII (plan/segment) домен төлсипаттарын қосыңыз, span ішіндегі «бизнес-кезеңдер» оқиғаларын пайдаланыңыз және exemplar бойынша конверсиялық метриктерден көшіңіз.

• «Бақылау: логи, метрика, трассировка»
• «Аудит және өзгермейтін журналдар»
• «In Transit/At Rest шифрлау»
• «Деректердің шығу тегі (Lineage)»
• «Privacy by Design (GDPR)»
• «Құпия менеджменті»