Байкоо: Логи, метрика, Tracking

Байкоо: Логи, метрика, Tracking

1) Эмне үчүн керек

• Метриктер - SLI/SLO жана симптомдору боюнча алертинг үчүн компакттуу агрегаттар.
• Tracking - себептик суроо чынжыр (end-to-end).
• Логи - тергөө жана аудит үчүн деталдуу окуялар.

Максаты: тез RCA, алдын алуучу жана error budget ичинде башкарылуучу ишенимдүүлүк.

2) Архитектура принциптери

Бирдиктүү контекст: бардык жерде ыргытып 'trace _ id', 'span _ id', 'tenant _ id', 'request _ id', 'user _ agent', 'client _ ip _ hash'.
Стандарттар: OpenTelemetry (OTel) үчүн SDK/агенттер, JSON форматы (канондук, схема менен).
Симптомдору> себептери: CPU эмес, колдонуучунун симптомдору (жашыруун/ката) боюнча алертим.
Байланыш сигналдар: метрика → span (exemplars) → белгилүү Логи 'trace _ id'.
Коопсуздук жана купуялуулук: блогдордо PII жашыруу, in transit/at rest шифрлөө, аудит үчүн өзгөрүлбөс журналдар.
Көп ижара: аттарды/ачкычтарды/саясатты бөлүү.

3) Сигналдардын таксономиясы жана схемалар

3. 1 Метрика

RED (Rate, Errors, Duration) кызматтары жана инфраструктурасы үчүн USE (Utilization, Saturation, Errors).
Типы: counter, gauge, histogram/summary. жашыруун үчүн - белгиленген bucket's менен histogram.
Exemplars: 'trace _ id' шилтемеси "ысык" гистограммада.

name: http_server_duration_seconds labels: {service, route, method, code, tenant}
type: histogram buckets: [0. 01, 0. 025, 0. 05, 0. 1, 0. 25, 0. 5, 1, 2, 5]
exemplar: trace_id

3. 2 Tracking

Span = 'name', 'start/end', 'attributes', 'events', 'status' менен операция.
көтөрүү үчүн W3C Trace Context.
Жоболоштуруу: негизги (head) + динамикалык (tail) + "маанилүүлүк" эрежелери (каталар, жогорку p95).

3. 3 Логи

Гана структураланган JSON; деңгээл: DEBUG/INFO/WARN/ERROR.
Милдеттүү талаалар: 'ts _ utc', 'level', 'message', 'trace _ id', 'span _ id', 'tenant _ id', 'env', 'service', 'region', 'host', 'labels {}'.
Тыюу салынган: сырлар, токендер, PAN, сырсөздөр. PII - гана токенизацияланган/жашырылган.

json
{"ts":"2025-10-31T12:05:42. 123Z","level":"ERROR","service":"checkout","env":"prod",
"trace_id":"c03c...","span_id":"9ab1...","tenant_id":"t-42","route":"/pay",
"code":502,"msg":"payment gateway timeout","retry":true}

4) чогултуу жана транспорт

Агенттер/экспорттоочулар (daemonset/sidecar) → түйүн боюнча буфер → шина/ingest (TLS/mTLS) → сигналдарды сактоо.
Талаптар: back-pressure, retry, deduplication, кардиналдуулугун чектөө (labels!), "log storms" коргоо.

Метрика: pull (Prometheus-шайкеш) же OTLP аркылуу push.
Tracking: OTLP/HTTP (gRPC), коллектордо tail-samplers.
Логи: жергиликтүү чогултуу (journald/docker/stdout) → парсер → нормалдаштыргыч.

5) Сактоо жана сактоо (tiered)

Metrics: Hot TSDB 7-30 күн (downsample менен), узак мөөнөткө агрегаттар (90-365 күн).
Tracking: 1-7 күн толук, андан кийин агрегаттар/span "маанилүү" кызмат; индекстерди 'service', 'status', 'error' боюнча сактоо.
Logi: ысык индекси 7-14 күн, жылуу 3-6 ай, 1-7 жылга чейин архив (комплаенс). Аудит - WORM.

Чыгымдарды оптималдаштыруу: downsampling, DEBUG чыпкалоо, лейбл квоталары, жолдор үчүн sampling.

6) SLI/SLO, Алертинг жана милдети

SLI: жеткиликтүүлүк (% ийгиликтүү суроо), жашыруун (p95/p99), 5xx үлүшү, маалыматтардын сергектиги, ийгиликтүү джоб үлүшү.
SLO: SLI боюнча максат (мисалы, 99. 9% ийгиликтүү ≤ 400 ms).
Error budget: 0. 1% "ката укугу" → fichfries/эксперименттер эрежелери.

• `ALERT HighLatency` если `p99(http_server_duration_seconds{route="/pay"}) > 1s` 5мин.
• `ALERT ErrorRate` если `rate(http_requests_total{code=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0. 02`.
• Silos Alert (CPU/Disk) - гана көмөкчү катары, эч кандай paging.

7) Сигнал корреляциясы

Метрика "кызыл" → exemplar чыкылдатуу → конкреттүү 'trace _ id' → карап "жай" span → ошол эле 'trace _ id' боюнча логин ачуу.
Релиздер менен байланыш: 'version', 'image _ sha', 'feature _ flag' атрибуттары.
Маалымат/ETL үчүн: 'dataset _ urn', 'run _ id', lineage менен байланыш (тиешелүү макаланы караңыз).

8) Семплирлөө жана кардиналдуулук

Метрика: этикеткаларды чектөө ('user _ id', 'session _ id' жок); каттоо учурундагы квоталар/валидация.
Tracking: баш-үлгү (кире) жана tail-үлгү (жыйноочу) эрежелери менен айкалыштыруу: "бардык 5xx, p99, каталар - 100%".
Логи: деңгээл жана дросселдөө; көп кайталануучу каталар үчүн - бириктирүүчү окуялар (dedupe ачкыч).

yaml processors:
tailsampling:
decision_wait: 2s policies:
- type: status_code status_code: ERROR rate_allocation: 1. 0
- type: latency threshold_ms: 900 rate_allocation: 1. 0
- type: probabilistic hash_seed: 42 sampling_percentage: 10

9) Коопсуздук жана купуялык

In Transit/At Rest: шифрлөө (TLS 1. 3, AEAD, KMS/HSM).
PII/Secrets: жөнөтүүгө чейин санитайзерлер, токенизациялоо, жашыруу.
Access: ABAC/RBAC окуу; producers/readers/admins ролдорду бөлүштүрүү.
Аудит: логдорго/жолдорго кирүү үчүн өзгөрүлбөс журнал; экспорт - шифрленген түрдө.
Көп ижара: саясатчылар менен namespaces/tenant-labels; шифрлөө ачкычтарын изоляциялоо.

10) Конфигурация профилдери (фрагменттер)

yaml global: { scrape_interval: 15s, evaluation_interval: 30s }
scrape_configs:
- job_name: 'app'
static_configs: [{ targets: ['app-1:8080','app-2:8080'] }]
rule_files: ['slo. rules. yaml']

yaml groups:
- name: http_slo rules:
- record: job:http_request_duration_seconds:p99 expr: histogram_quantile(0. 99, sum(rate(http_server_duration_seconds_bucket[5m])) by (le,route))
- alert: HighLatencyP99 expr: job:http_request_duration_seconds:p99{route="/pay"} > 1 for: 5m

OpenTelemetry SDK

python provider = TracerProvider(resource=Resource. create({"service. name":"checkout","service. version":"1. 8. 3"}))
provider. add_span_processor(BatchSpanProcessor(OTLPExporter(endpoint="otel-collector:4317")))
set_tracer_provider(provider)
with tracer. start_as_current_span("pay", attributes={"route":"/pay","tenant":"t-42"}):
business logic pass

python log. info("gw_timeout", extra={"route":"/pay","code":502,"trace_id":get_trace_id()})

11) Маалыматтар/ETL жана агымы

Маалыматтар үчүн SLI: сергектик (max lag), толуктук (rows vs expectation), "сапат" (валидаторлор/дупликаттар).
Alerty: өткөөл терезе, артта Консумер, DLQ өсүшү.
Корреляция: 'run _ id', 'dataset _ urn', lineage окуялары; payplayns үчүн tracking (батч/partition боюнча span).
Kafka/NATS: метрика продюсер/консьемер, артта/баш тартуу; headers (анын ичинде 'traceparent').

12) Profiling жана eBPF (кошумча сигнал)

Төмөн деңгээл ысык жолдор CPU/alloc/IO; окуя боюнча профилдер.
eBPF-телеметрия (тармактык кечигүү, DNS, системалык чалуулар) менен байланышкан 'trace _ id '/PID.

13) Байкоо сыноо

Signal келишими: CI метр/белги/histogram экспортун текшерүү.
Synthetic probes: RUM сценарийлери/тышкы SLI үчүн симуляцияланган кардарлар.
Chaos/Fire drills: көз карандылыкты өчүрүү, деградация - биз алерттердин жана нөөмөтчүлөрдүн реакциясын карап жатабыз.
Пробада Smoke: пост-деплой текшерүү жаңы EndPoints метрика жана трасса бар.

14) Наркы жана көлөмүн контролдоо

Сигнал/команда боюнча бюджеттер; dashboard "cost per signal".
Бюджет боюнча кардиналдуулук (SLO cardinality), жаңы лейблдер боюнча лимиттер.
Downsampling, маалымат класстары, "муздак" Archives жана аудит үчүн WORM.

15) Иштетүү жана SLO байкоо платформа

SLO аянтчалар: 99. 9% ийгиликтүү Ингест; Метрикалык индекске чейин кечигүү ≤ 30 с, логдор ≤ 2 мин, трасса ≤ 1 мин.
Платформанын алерттери: инжесттин артта калышы, тамчылардын өсүшү, кол коюу/шифрлөө катасы, буферлердин толушу.
DR/HA: көп зоналуу, репликация, конфигурациялардын/эрежелердин резервдик көчүрмөлөрү.

16) Чек-баракчалар

• Бардык жерде 'trace _ id '/' span _ id' ыргытылат; схема менен JSON-логи.
• Гистограммалар менен RED/USE метрика; exemplar → жолдор.
• Tail-sampling киргизилген; эрежелер 5xx/p99 = 100%.
• симптомдору + Рунибуки боюнча Алерта; тынч саат/анти-flap.
• PII санитайзерлер; at rest/in transit шифрлөө; аудит үчүн WORM.
• Көлөмү/кардиналдуулугу боюнча Retens жана бюджеттер.

• Ай сайын карап чыгуу (ызы-чуу/тактык), тюнинг босоголор.
• error budget боюнча отчет жана көрүлгөн чаралар (fichfries, hardening).
• Критикалык жолдор үчүн дашбордддорду/үймөктөрдү/жолдорду текшерүү.
• Окутуу окуялар жана runbook's жаңыртуу.

17) Runbook’и

RCA: өсүш p99/төлөө

1. 'checkout' үчүн RED dashboard ачуу.
2. Өтүү exemplar → жай трек → аныктоо "тар span" (мисалы,, 'gateway. call`).
3. Ачуу 'trace _ id' → көрүү тайм/ретрайлер.
4. Ficha-желегин/RPS чегин киргизүү, көз карандылык ээлерине кабарлоо.
5. турукташтыруу кийин - RCA, оптималдаштыруу үчүн билеттер, ойнотуу сыноо.

1. SLI "сергектик" кызыл → Джоба жолдор → failing кадам.

2. Текшерүү брокер/DLQ, ката коннектор.

3. reprocess ишке киргизүү, керектөөчүлөргө кабарлоо (BI/продукт) статусу канал аркылуу.

18) Көп каталар

схемасы жок Логи жана 'trace _ id' жок. Тергөө иштери бир топ убакытка созулат.
Алерта ордуна белгилер. Paging "сүт" барат.
Метриктердин чексиз кардиналдуулугу. Чыгымдардын жарылуусу жана туруксуздук.
Бардык жолдор 100%. Кымбат жана кереги жок; акылдуу семплирлөө кирет.
PII/сайттарда сырлар. Санитайзерлерди жана "кызыл тизмелерди" киргизиңиз.
"Үнсүз" Чичтер. Метриктер/жолдор/логдор жок жаңы код.

19) FAQ

S: Мен чийки жазуу текстти сактоо керекпи?
О: Ооба, бирок ретенция жана архивдер менен; Алерттер жана SLO үчүн жетиштүү агрегаттар бар. Аудит - WORM.

S: Жолдор үчүн эмнени тандоо керек - head же tail sampling?
A: айкалыштыруу: негизги каптоо үчүн head-probabilistic + каталар жана аномалиялар үчүн tail-rules.

S: Кантип колдонуучу метрика жана техникалык байланышуу керек?
О: Жалпы 'trace _ id' жана бизнес-лейблдер ('route', 'tenant', 'plan') аркылуу, ошондой эле продукттун окуялары (конверсиялар) аркылуу жолдорго байланыштуу.

S: Кантип алертада чөгүп жок?
A: симптомдору боюнча уруп, тынч саат киргизүү, дедупликация, топтоо, SLO артыкчылыктуу жана ар бир алерт боюнча демейки ээси.

• "Аудит жана өзгөрүлбөгөн журналдар"
• "In Transit/At Rest шифрлөө"
• "Сыр менеджменти"
• "Маалыматтардын келип чыгышы (Lineage)"
• «Privacy by Design (GDPR)»
• "Webhook жеткирүү кепилдиктери"