Бақылануы: логия, метрика, трассировка

Бақылануы: логия, метрика, трассировка

1) Бұл не үшін қажет

• Метриктер - SLI/SLO және симптомдары бойынша алертингке арналған ықшам агрегаттар.
• Трассировка - сұрау салулардың себеп-салдарлық тізбегі (end-to-end).
• Логи - тергеу және аудит үшін егжей-тегжейлі оқиғалар.

Мақсаты: жылдам RCA, алдын алу тәуекелдері және error budget шеңберінде басқарылатын сенімділік.

2) Сәулет қағидаттары

Бірыңғай контекст: барлық жерге 'trace _ id', 'span _ id', 'tenant _ id', 'request _ id', 'user _ agent', 'client _ ip _ hash' тастаймыз.
Стандарттар: SDK/агенттерге арналған OpenTelemetry (OTel), JSON-логтар форматы (канондық, схемасы бар).
Симптомдар> себептер: CPU емес, пайдаланушы симптомдары бойынша аллергим (жасырындылық/қателер).
Сигналдар байланысы: метрикадан спанға (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 Трассировкалар

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) → тораптағы буфер → шина/ингест (TLS/mTLS) → сигналдар қоймасы.
Талаптар: back-pressure, ретрациялар, дедупликация, кардиналдылықты шектеу (labels!), «log storms» -тен қорғау.

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

5) Сақтау және ретенция (tiered)

Өлшемдер: ыстық TSDB 7-30 күн (downsample), агрегаттар ұзақ мерзімге (90-365 күн).
Трассировка: 1-7 күн толығымен, содан кейін агрегаттар/« маңызды »сервистер; 'service', 'status', 'error' бойынша индекстерді сақтау.
Логи: ыстық индекс 7-14 күн, жылы 3-6 ай, мұрағат 1-7 жасқа дейін (комплаенс). Аудит - WORM.

Шығындарды оңтайландыру: downsampling, өнімдегі DEBUG сүзгісі, лейбл квоталары, трассалар үшін sampling.

6) SLI/SLO, алертинг және кезекшілік

SLI: қол жетімділік (табысты сұраныстардың%), жасырындылық (p95/p99), 5xx үлесі, деректердің жаңаруы, табысты джоб үлесі.
SLO: SLI нысанасы (мысалы, 99. 9% табысты ≤ 400 мс).
Error budget: 0. 1% «қате құқығы» → фичфриз/эксперимент ережелері.

• `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`.
• Силос-алерты (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'); тіркеу кезіндегі квоталар/валидация.
Трассировкалар: head-sample (кіре берісте) және tail-sample (коллекторда) «барлығы 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/құпиялар: жөнелтілгенге дейінгі санитайзерлер, токенизация, бүркемелеу.
Қолжетімділік: 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

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), «сапа» (валидаторлар/дупликаттар).
Алерталар: терезені өткізіп жіберу, консюмердің артта қалуы, DLQ биіктігі.
Корреляция: 'run _ id', 'dataset _ urn', lineage оқиғалары; пайплайндарға арналған трассировкалар (батч/partition үшін span).
Kafka/NATS: метрика продюсер/консюмер, лаг/бас тарту; headers бойынша трассалау (оның ішінде 'traceparent').

12) Профильдеу және eBPF (қосымша сигнал)

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

13) Байқауды тестілеу

Сигналдар келісімшарты: метриктердің/лейблдердің/гистограммалардың CI-ға экспортын тексеру.
Synthetic probes: RUM сценарийлері/сыртқы SLI үшін симуляцияланған клиенттер.
Chaos/Fire drills: тәуелділікті өшіру, деградация - алерттер мен кезекшілердің қалай әрекет ететінін қараймыз.
Өнімдегі Smoke: жаңа эндпоинттердің метрикасы мен трассировкасы бар екенін пост-деплой тексеру.

14) Құн және көлемдерді бақылау

Сигнал/команда бойынша бюджеттер; «cost per signal» дэшборды.
Бюджеттің түбегейлігі (cardinality бойынша SLO), жаңа лейблдерге лимиттер.
Downsampling, деректер класы бойынша ретенциялар, «суық» мұрағаттар және аудит үшін 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%.
• Симптомдар бойынша аллергия + рунибуки; тыныш сағат/anti-flap.
• PII санитайзерлері; at rest/in transit шифрлау; Аудит үшін WORM.
• Көлемдерге/түбегейлі ретенциялар мен бюджеттер.

• Ай сайынғы алертті шолу (шу/дәлдік), табалдырықтардың тюнингі.
• Error budget бойынша есеп және қабылданған шаралар (фичфриз, hardening).
• Критикалық жолдар үшін дашбордтардың/логтардың/трассалардың жабындарын тексеру.
• Оқу оқиғалары және runbook's жаңарту.

17) Runbook’и

RCA: p99/pay

1. 'checkout' үшін RED дашбордын ашу.
2. exemplar → баяу трассамен өту → «тар спан» (мысалы, 'gateway. call`).

3. 'trace _ id' → бойынша тіркемелерді ашу

4. RPS шегініс/шегініс жалаушасын қосу, тәуелділік иелеріне хабарлау.
5. Тұрақтандырудан кейін - RCA, оңтайландыру үшін тикеттер, ойнату тесті.

1. SLI «жаңалық» қызыл → джоба трассасы → failing қадам.

2. Брокердің/DLQ лагын, коннектордың қателерін тексеру.

3. reprocess бағдарламасын іске қосу, тұтынушыларға (BI/өнім) мәртебе арнасы арқылы хабарлау.

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

Сұлбасы жоқ және 'trace _ id' жоқ логтар. Тергеу бірнеше есеге созылады.
Симптомдардың орнына инфрақұрылым бойынша аллергиялар. Paging «сүтке» кетеді.
Метриканың шексіз түбегейлігі. Шығындардың жарылысы және тұрақсыздық.
Барлық трассалар 100%. Қымбат және қажет емес; ақылды тұқымдастыруды қосыңыз.
Логтардағы PII/құпиялар. Санитайзерлер мен «қызыл тізімдерді» қосыңыз.
«Үнсіз» фичтер. Метрикасыз/трассасыз/логсыз жаңа код.

19) FAQ

С: Логтардың шикі мәтінін сақтау керек пе?
О: Иә, бірақ ретенциямен және мұрағаттармен; алгоритмдер мен SLO үшін жеткілікті агрегаттар бар. Аудит - WORM-де.

В: Трасса үшін не таңдау керек - head немесе tail sampling?
О: Біріктіру: негізгі жабын үшін head-probabilistic + қателер мен ауытқулар үшін tail-rules.

С: Пайдаланушы өлшемдері мен техникалық өлшемдерін қалай байланыстыру керек?
О: Жалпы 'trace _ id' және бизнес-лейблдер ('route', 'tenant', 'plan') арқылы, сондай-ақ трассаларға корреляцияланған өнім оқиғалары (конверсиялар) арқылы.

С: Қалай қорқынышқа батпауға болады?
О: Симптомдар бойынша бейттеңіз, тыныш сағаттарды, дедупликацияны, топтастыруды, SLO бойынша басымдықты және әрбір алерт үшін әдепкі иесін енгізіңіз.

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